Anil Gangolli
Collected Bits - Home Page and Personal Weblog
Notes on gigabit ethernet, ubuntu, file transfers, samba
Over time, more of the devices on my home network have been becoming gigabit-capable. In practice this doesn't buy us much. Most of the time, we are all on the 54 mbps wireless net and most of the traffic is Internet browsing at much slower rates. So to date, I hadn't really paid much attention to what I'm actually getting from all of the gigabit hardware.
Recently however, with some video files and backup disk images getting stored on the home server, it has really become worthwhile to connect to the wired net for specific activities. The Mac laptops in the household have gigabit ethernet ports, and so does my development desktop box.
On a recent Samba transfer of a relatively short 200MB home video clip from my wired desktop to the server, I noticed that I was still getting rates consistent with only 100mbps ethernet, nothing near gigabit rates.
Here are some notes on my experiences trying to improve this.
The Setting
The client is running Ubuntu 7.04 (Feisty Fawn) on a homemade desktop box with an ASUS P5WDG2 WS PRO motherboard. The motherboard has two gigabit ethernet devices on it, one based on the Marvell Yukon 88E8001 and one based on the 88E8052 chipset. I'm only really using the first one (eth0 on my box). The drivers are the skge drivers. I'm not sure which version is in the kernel (2.6.20-16-generic) in the 7.04 distribution.
The server is running Fedora Core 6 on another homemade box with an ASUS P4P800-E Deluxe motherboard; it has one Marvell 88E8001 device onboard, and another gigabit device from a Linksys card which is the one on the internal home net. Both use the skge drivers as well.
These are both wired using 7-foot CAT 6 cables to a Netgear GS-105 gigabit switch.
First Problem Found: Autonegotiation on the Ubuntu desktop box
After poking around with ethtool, I find, hey, I'm getting 100mbps rates because eth0 on the Ubuntu box thinks it is running at 100mbps. Check the indicator lights on the switch. Yep. Hmm. Now what?
Unplug, replug, ifconfig eth0 down, ifconfig eth0 up. No luck. For some reason, the Ubuntu box is autonegotiating to 100mbps though both sides are 1000mbps.
My google searches provide no answer but suggest some others have similar issues; I've still found nothing that would suggest how to get the autonegotiation to work. The nearly identical situation with Fedora on the server is having no problems reliably autonegotiating up to the gigabit rate. Eventually, I resort to forcing the Ubuntu box to go gigabit by adding a pre-up line to my /etc/network/interfaces< file before the interface is brought up, as shown in the third line of the following fragment from this file:
auto eth0
iface eth0 inet dhcp
pre-up /usr/sbin/ethtool -s eth0 speed 1000 duplex full autoneg off
Activating Jumbo Frames
OK. Now that I get that working reliably, I do some perf tests with iperf running on both sides, using TCP_NODELAY, and otherwise taking iperf defaults, I get about 537mbps.
% iperf -N -c 192.168.1.2
------------------------------------------------------------
Client connecting to 192.168.1.2, TCP port 5001
TCP window size: 27.6 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.102 port 41548 connected with 192.168.1.2 port 5001
[ 3] 0.0-10.0 sec 640 MBytes 537 Mbits/sec
Much better! But I decide to check what I get by activating jumbo frames which my hardware all supports.
With jumbo frame support enabled I get:
% iperf -N -c 192.168.1.2
------------------------------------------------------------
Client connecting to 192.168.1.2, TCP port 5001
TCP window size: 73.6 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.102 port 51573 connected with 192.168.1.2 port 5001
[ 3] 0.0-10.1 sec 923 MBytes 764 Mbits/sec
That's more like it. I think this is about the best I am likely to do, and in any case I decide I like 764 much better than 537
, so I add another pre-up line to set the MTU on eachreboot. My /etc/network/interfaces entry for the interface now looks like this:
auto eth0
iface eth0 inet dhcp
pre-up /usr/sbin/ethtool -s eth0 speed 1000 duplex full autoneg off
pre-up /sbin/ifconfig eth0 mtu 9000
Samba, Nautilus still slow
OK. Now that I've got my network speeds up I should be getting great transfer speeds, right?
Not quite.
Back in Nautilus (the GNOME finder GUI) I try dragging the 200MB video clip across, and I find
it still takes about 20 seconds, or 10MB per sec or roughly 100mbps again.
Could disk speed be the bottleneck? I don't think so; I've got fast SATA drives and they shouldn't
be a problem. To verify I try a little ftp test:
ftp> get Garden.dv
local: Garden.dv remote: Garden.dv
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for Garden.dv (219360000 bytes).
226 File send OK.
219360000 bytes received in 2.23 secs (96182.1 kB/s)
OK! Now that's what I expect, roughly the speed of I'm seeing with iperf. So my desktop transfer problem must be a Samba problem right?
I go check my Samba server config, and consulting various sources on the
net, I find I already have the options set pretty well:
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
So, what about straight Samba transfers? Let's try smbget:
% /usr/bin/time -p smbget -w BUSYBUDDHA -a smb://sycamore-int/public/Garden.dv
Using workgroup BUSYBUDDHA, guest user
smb://sycamore-int/public/Garden.dv
Command exited with non-zero status 1
real 4.35
user 0.20
sys 1.01
The nonzero exit status turns out to be spurious. The file has transferred fine; took twice the time of FTP, but still not bad. Close to 500mbps. A similar test with smbclient yields similar results for me. Both of these are far better than what I'm seeing with Nautilus.
After more searching on the net, I decide to try smbfs for comparison
# mount -t smbfs -o username=notshown,password=notshown,sockopt=TCP_NODELAY //sycamore-int/public /media/public
This mounts it on /media/public and then using straight cp I get a 12 second transfer; slower than smbget.
But then I try a second transfer, and I get:
/usr/bin/time -p cp /media/public/Garden.dv .
real 0.95
user 0.02
sys 0.90
Great! Less than a second. Wait. That shouldn't really be possible. Check the md5sum. The file is all there. What is going on? Oh. Some sort of caching. Force the cache to be blown by remounting and you get the 12 second transfer again. So smbfs might perform really well for situations where you get to use the cache, but based on my limited experimentation, not for initial transfers. [Note: I also tried this with mount -t cifs and got the
same kind of behavior.]
Faster than Nautilus which is amazingly achieving only about 100mpbs still. So I'm still looking for improvement.
Summary
In summary, for my particular situation I found:
- Check that your ethernet device negotiated to 1000mbps. I had to force mine.
- If your hardware supports it, use jumbo frames. This got me to a measured 760 mbps using iperf (TCP) which I feel is probably as good as I'm going to get.
- FTP is able to achieve nearly the transfer rates that I see with iperf, and Disk I/O is included.
- I was able to get Samba doing about 500mbps via smbget or smbclient. I suspect this is about as good as I'll get.
- Using smbfs mounts is slower on initial transfers than smbget or smbclient, but fast on cached stuff.
- Samba transfers via Nautilus are still only getting transfer rates close to about 100mbps. I still don't know why Nautilus is so darn slow.
Tagged: ethernet ftp gigabit linux samba ubuntu
Posted at 01:59PM Jul 22, 2007 in tech | Permalink
Scary Report Card
It‘s nice, but scary, to see a bit of honesty about the current situation in information security in government agencies.
The problems are deep and pervasive, and progress is slow.
While one can understand but not excuse an F overall for the entire Defense department, it sure is hard, as you file all of that information to the IRS, to notice that the Treasury Department gets an F, slipping from a D- last year.
Talk about a honeypot.
Tagged: security technology
Posted at 08:17AM Apr 13, 2007 in tech | Permalink
Standing Room Only
Seagate has released the first 160 GB 2.5 laptop drive (PDF product overview). It runs at 5400rpm. It packs the bits in “upright.”
I suspect this means we‘ll be seeing iPods and other personal AV devices with capacities in the same range in the not-too-distant future, and with even more focus on video.
Technorati tags: Seagate disk drive technology iPod
Posted at 07:57AM Jan 18, 2006 in tech | Permalink
David Lazarus doesn't get it
David Lazarus doesn't get why anyone cares about the move to Intel-based Macs.
“Get over it,” he says.
Well here are my observations.
The processor. Serious users care about the speed of their machines. People continue to appreciate faster processors that can do more in less time, and they continue to do more things with video, photos, and music that rely on fast processors and fast buses to communicate with memory. The Power PC chips have been losing ground in this area for some time; while Mac enthusiasts love the usability and design aspects of the Mac, they‘ve had to put up with slower processing for some time, with the continued risk of falling further and further behind. The move to Intel basically assures at least rough parity with the typical Windows-based Intel machines, which allows the Mac to excel where it does and not fall behind in raw power. This is the main reason to care.
Other more standard components inside. Macs will probably look more and more like your typical PCs inside, while Apple will probably push the envelope in just a few areas to retain a differential lead in the areas it has traditionally excelled in. This is good for a lot of users because it increases the chances that they will be able to find more components and add-ons that work with Macs.
An avenue for alternate OS-es and open-source innovation. Far fewer users will care about this, and MacOS enthusiasts will have trouble understanding this too, but running Linux on a Mac Mini for example, makes a lot of sense to me as a little closet server box. [PowerPC based Linux even on the G4-based powerbooks already exists, but I think that represents a step down in anything but the server-side arena.]
Technorati tags: Intel Apple Mac
Posted at 10:37AM Jan 14, 2006 in tech | Permalink
Macbook Pro
Looks like everyone‘s drooling.
Matt has gone and purchased one already, delivery in February.
Dave is waiting to see how Matt likes his.
It‘s pretty much guaranteed now that I‘ll be buying one at some point, but I‘ll probably wait a rev or two for things to stabilize, and possibly for the 17” version to be available.
UPDATE: Boo! No Firewire 800 on the MacBook. Dave posted a link to this interesting comparison page.
Posted at 08:12AM Jan 11, 2006 in tech | Permalink
CTRL-ALT-L fix w/ Intel Graphics 82845G
I recently noticed that the CTRL-ALT-L key, which is the keyboard shortcut to reformat code in IntelliJ IDEA, wasn‘t working for me on one of my laptops.
I thought some other app might be intercepting it and tried disabling all kinds of things before finding this very obscure solution.
It‘s used as a “hot key” by the Windows driver for the Intel 82845G graphics controller. See the Intel support note on this topic.
The fix:
From the desktop, right click Properties then Settings | Advanced | Intel Graphics Tab | Graphics Properties | Hot Keys | Uncheck the Enable Hot Keys button.
And Viola! (sic.)
Posted at 08:20AM Dec 16, 2005 in tech | Permalink | Comments[3]
Yahoo to host Movable Type blogs
[Sorry, a lame “link only” entry.]
Yahoo to host small-business blogs based on Movable Type
Posted at 07:37AM Dec 13, 2005 in tech | Permalink
Sony's Rootkit
I don‘t know what gets into these companies. Who‘s the genius that came up with this plan and what were they thinking?
How are we going to protect those CDs? Hey, I know! We'll just secretly install some stuff under the cover of AutoRun! It'll intervene in all the cd activity. Yeah! and we'll make it cloak itself! and hey, who would know? And it would be great! Yeah, that's the ticket!
Oh, and so useful for trojans too! Send in the bots. Where are the bots? Don‘t bother, they're here!
And so are the lawyers by the way. Hurrah for class action lawsuits for once.
More:
Mark's Sysinternals Blog
Technorati: sony rootkit
Google: sony rootkit
Posted at 10:46PM Nov 10, 2005 in tech | Permalink | Comments[2]
The Zombie Hunters
Read The Zombie Hunters from the New Yorker. It‘s a great little article about the criminal industry that has developed around directing vast armies of bot-infected pcs to launch distributed denial of service attacks against dot com companies in order to extort protection money, and about a couple of the people who make their livelihoods battling them.
Technorati tags: bot zombie network security
Posted at 07:17AM Oct 12, 2005 in tech | Permalink | Comments[5]
Smart Tag Creator Behind Google's New Autolink Feature
The similarity with Microsoft‘s earlier Smart Tags is not coincidental. -The developer is now at Google, and apparently responsible.-
CORRECTION: NEVER MIND. THE SOURCE OF THIS NOW RETRACTS IT.
Technorati tags: google AutoLink
Posted at 01:56PM Mar 06, 2005 in tech | Permalink
Google and Apple SSDD
The image of Google and Apple as relatively benevolent ethical players in the industry is being tarnished as they exhibit the same hubris and megalomania as everyone else. What is it with these dufuses? They hugely undervalue the grass roots support that sustains their customer base. Huh? Goodwill? Who needs it.
Google‘s recent AutoLink play reminds me of the 2003 Verisign SiteFinder scandal (“Oh hey, we own the damned DNS (don‘t we?). We‘ll just redirect all of those non-resolving domain names to our site. Yeah, that‘s the ticket!”)
Technorati tags: google AutoLink
Posted at 01:33PM Mar 06, 2005 in tech | Permalink
Better Bad News on Google Autolinks
Just check it out
Technorati tags: google blogging
Posted at 12:22PM Mar 06, 2005 in tech | Permalink
Is blogging journalism?
Apple is arguing that blogging should not be afforded the California statutory protections provided to the press with respect to identifying sources of leaks and Superior Court Judge James Kleinberg (Santa Clara County) agrees.
Related:
Discussion on slashdotUPDATE – On second thought skip that one. Too many nitwits; minimal understanding of the issues.EFF page on the case; much better.
Posted at 01:29PM Mar 05, 2005 in tech | Permalink
Gigapxl
A friend showed this to me over the Christmas holidays, and I‘d forgotten to blog it up.
The Gigapxl Project (note the spelling) is worth a visit. Go to the image gallery and view the zoomed in images. What appears to be little more than a speck at normal rendering resolution reveals itself at amazing resolution when you go in.
Technorati tags: digital cameras photography
Posted at 09:45AM Feb 12, 2005 in tech | Permalink
UTF-8 considered harmful
Thane‘s blog calls attention to this internationalized URL attack that‘s practically custom-made for phishing.
Eek! Should have stuck to IA5String!
Related (via Google): homograph attack
Technorati topics: i18n UTF-8 SSL security X.509 PKI
Posted at 07:57PM Feb 09, 2005 in tech | Permalink