Followup on slow file transfer on my LAN
The background is I want to transfer files between machines on my LAN. Basically taking advantage of free space and access to a burner as resources come available. The network is a wired 10/100 network running off a home router. Just about any machine I connect to the LAN works fine. My main machine doesn't (FC 2). Upload speed to a server is fine. Download is quite a bit slower. I've been ftping from an OS X Mac to my Linux box for the last week. I've been peaking at 5Kb/sec per connection. Sustained rates are around 2.0 - 2.3 Kb/sec. I *thought* HTTP was faster. I tried using HTTP from both the Mac and a Linux server and got similar speeds. Certain LARGE files take 2 hours to transfer from the Linux box to my machine. From the Mac it takes over night (it's a LAN - I don't mind leaving it on for hours if the job gets done). I can open multiple connections resulting in more files coming down in the same amount of time. Friends occasionally bring their machines over and get really good transfer rates. Five minutes or so for one of the LARGE files I mentioned. I tried an experiment. I booted into the M$ side of my machine. Went to the DOS prompt. I ftp'd a large file (120 MB) after about 5 - 7 minutes I stopped the transfer and checked the size. It was almost done. Back to Linux and it's slow again. So far with this experiment I've eliminated some possible problems. The cables should be fine. The port on the router is fine. The NIC is fine. Since it works with M$, the router is fine (although I have to check if it is limiting based on the DHCP address of the Linux box - I set up a static IP for the M$ side and won't let it have net access). I've also followed up with a suggestion to look at mii-tools. It generates an error as if the card were too old to be used this way. The Mac is refusing active connections so I'm in passive mode. Any suggestions? Later Mike -- +----------------------------------------------------------------------+ |Call-A.P.P.L.E. and the Digital Civilization http://www.callapple.org | | http://members.shaw.ca/pfaiffer = Mike Pfaiffer (B.A., B.Sc.) | +----------------------------------------------------------------------+ ----- BEGIN GEEK CODE BLOCK ----- Version: 3.12 GCS/G/IT/PA/SS d s+:- a? C++ UL L++ W++ N++ o+ K- w(---) O+@ M++@ V PS+ PE !PGP t+ 5+ X R tv b+ DI+++ D++ G e++* h! r-- !y-- UF++ ------ END GEEK CODE BLOCK ------
Mike Pfaiffer wrote:
So far with this experiment I've eliminated some possible problems. The cables should be fine. The port on the router is fine. The NIC is fine. Since it works with M$, the router is fine (although I have to check if it is limiting based on the DHCP address of the Linux box - I set up a static IP for the M$ side and won't let it have net access).
On Linux do an ifconfig and see if it reports errors or collisions. -- Bill
On January 29, 2006 10:58 pm, Bill Reid wrote this amazing epistle:
Mike Pfaiffer wrote:
So far with this experiment I've eliminated some possible problems. The cables should be fine. The port on the router is fine. The NIC is fine. Since it works with M$, the router is fine (although I have to check if it is limiting based on the DHCP address of the Linux box - I set up a static IP for the M$ side and won't let it have net access).
On Linux do an ifconfig and see if it reports errors or collisions.
-- Bill
Leaving out the first couple of lines which just give the IP addresses, here is what I get for eth0. UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2382801 errors:0 dropped:0 overruns:0 frame:392797 TX packets:2108884 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3298556584 (3145.7 Mb) TX bytes:144681015 (137.9 Mb) Interrupt:10 Base address:0xec00 I don't know if I should be running multicast. The MTU looks OK for dialup. I don't know if it's OK for a LAN. No idea what the metric is. Everything else looks as though it should be OK (although I may need to power down the router soon). Later Mike -- +----------------------------------------------------------------------+ |Call-A.P.P.L.E. and the Digital Civilization http://www.callapple.org | | http://members.shaw.ca/pfaiffer = Mike Pfaiffer (B.A., B.Sc.) | +----------------------------------------------------------------------+ ----- BEGIN GEEK CODE BLOCK ----- Version: 3.12 GCS/G/IT/PA/SS d s+:- a? C++ UL L++ W++ N++ o+ K- w(---) O+@ M++@ V PS+ PE !PGP t+ 5+ X R tv b+ DI+++ D++ G e++* h! r-- !y-- UF++ ------ END GEEK CODE BLOCK ------
I may have the same or a related problem. I have 2 linux boxes and one XP box on a gigabit lan. I get around 20-30MB/s (no jumbo packets) on most traffic. However, uploading from the XP to the file server just crawls at around 3-5MB/s. I thought it was the XP NIC (DLink 530) but I just upgraded (90% new guts) my XP box and the onboard Intel 1000 is exactly as slow as the DLink. I'm running FC3 on both linux boxes. Here's the weirdness I see: To
From linux1 linux2 xp lx1 - fast fast lx2 fast - fast xp fast SLOW! -
I'm testing with NFS between linuxes and CIFS/Samba between linux/XP. I've run a test on the slow link with FTP and got the same result. What I don't understand is how the results can be asynchronous. I see no errors in ifconfig in linux. I tried a different (CAT6) cable. I tried a different switch port.
Mike Pfaiffer wrote:
Leaving out the first couple of lines which just give the IP addresses, here is what I get for eth0.
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2382801 errors:0 dropped:0 overruns:0 frame:392797
That is your problem. You are getting frame errors. On windows when you do an ipconfig do you see errors as well? error: means packets with bad CRC and frame: is the catchall for misformed frames. It would interesting to look at the ifconfig on whoever you are talking with. If they are reporting frame errors on receive as well then there is something wrong with your NIC or drivers. Of course the router/switch could also be the problem. -- Bill
On Sun, 2006-01-29 at 20:30 -0600, Mike Pfaiffer wrote:
I've also followed up with a suggestion to look at mii-tools. It generates an error as if the card were too old to be used this way.
What card is it exactly? Most likely the linux drivers for that card are buggy. There are quite a number of older odd-ball cards that were never properly implemented in linux and haven't been updated in years. (I had a lot of these problems with TI chips for example). Run out and pick up a new NIC card. They are dirt cheap these days (less than $20) and I'll bet that will solve your problem. -- John Lange OpenIT ltd. www.Open-IT.ca (204) 885 0872 VoIP, Web services, Linux Consulting, Server Co-Location
John Lange wrote:
On Sun, 2006-01-29 at 20:30 -0600, Mike Pfaiffer wrote:
I've also followed up with a suggestion to look at mii-tools. It generates an error as if the card were too old to be used this way.
What card is it exactly? Most likely the linux drivers for that card are buggy. There are quite a number of older odd-ball cards that were never properly implemented in linux and haven't been updated in years. (I had a lot of these problems with TI chips for example).
Run out and pick up a new NIC card. They are dirt cheap these days (less than $20) and I'll bet that will solve your problem.
Just avoid any cards based on the VIA Rhine chipset. I too had experienced some odd slowness on a network connection on one Linux box, though it was mostly sending from the Linux box that was unusually slow (and got slower when I moved from a 10 Mb/s hub to a 10/100 switch!). I did some reading up on the driver for this chipset and found that the developer had essentially given up on it because it was so bad. It has a very high error rate. Under Windows, its performance seems decent enough, but probably because the Windows driver shrugs off errors and retries more quickly than the Linux driver developer wanted to do. I usually get good performance out of Realtek RTL-8139 chipsets (in a number of different NICs), as well as 3Com 3C905 cards and Intel chipsets. -- Gilles R. Detillieux E-mail: <grdetil@scrc.umanitoba.ca> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
participants (5)
-
Bill Reid -
Gilles Detillieux -
John Lange -
Mike Pfaiffer -
Trevor Cordes