Slow single file transfer, fast multiple transfer
 

I have a debain box (with gnome), and the network seems to work as it should except for one bizarre issue... When transferring files from another device over the network the transfer speed is only around 1MB/s... If I start another file transfer the rate of the first immediately jumps to around 5MB/s, and the second transfer runs at roughly the same for a combined speed of around 10MB/s... which is what I would expect to see on single transfers as well.

So I can speed up a file transfer by a factor 5 by simply starting another (pointless) transfer... and though I could live with a transfer rate of 5MB, I don't feel like it is a very permanent solution.

Does anyone have any logical explanation for this very strange behaviour? -Or just ideas on how to troubleshoot?

I considered posting output from tcpdump, netstat, ifconfig and all the other commands I've tried over the past couple of weeks to figure this out... but decided it would be a bit overwhelming for my first post ever...

So what information would be most relevant here?

Thats freaky. First a few questions:

1) are you using ssh, scp, vpn? (or something that'll encrypt while transfer)
2) are the two computer close to each other? (switch with cat5, 14.4 modem dialup, etc)
3) have you cleared iptables just to see if that has any effect?

No, not that I know of, the transfer is done from an autofs CIFS mount to a local folder using gnome... I have just tried rsync (still through the "local" CIFS mount), and the result is the same.

Yes, only a router (TP-LINK TL-WDR4300 N750 Wireless Dual Band Gigabit Router, updated to latest firmware today) is between them. The debian machine is connected with a cat5 cable, while the NAS is on an older cable that was in the house when I moved in, and therefore I can't exactly vouch for its classification ;) -Works flawlessly to any other machine on the network though.

I only have SSH access to the machine at the time of writing, but will try moving the NAS next to the router with a short cat5 cable when I can physically get to them, although I very much doubt it will change anything as the cable is clearly capable of transferring at higher speeds.

I have now. No change. It didn't really have anything in it anyway, it's a fairly fresh debian squeeze install with some default fail2ban chains - so not really containing any rules so far.

Meanwhile I have done some additional testing:
The problem only affects transfers through ethernet, not wifi. If I enable wifi on the debian machine, and disable cabled network completely (leaving everything else unchanged), then I get transfer rates around 4MB/s for a single transfer and it drops rather than rises if I run several transfers simultaneously.

This strongly suggests to me that the problem is something related to the cabled connection between debian and the router.

However, I can transfer files from other machines to the debian machine at full speed, which I guess clears the debian-router connection as a suspect.

But then again, I can also fetch the same files (well, it probably affects all files, but is only noticable on large files) from the NAS on any other machine without issues, 10-11MB/s on a single transfer and roughly half if I have two transfers.

I really don't understand the logic in this issue at all. Basically everything works, only the transfer rate is behaving in a very unexpected way.

Perhaps I should look into the CIFS mount or autofs...? Would that make sense, and how would I go about it (easiest way to eliminate)? Is it possible that one of those could behave so differently depending on whether they "go through" a ethernet or wifi?

On both boxes, can you run: ethtool eth0
(or "mii-tool eth0" which ever works, and use the right adapter, eth1, eth2, whatever.)

We are looking for the speed and duplex. It'd be something like:

Speed: 1000Mb/s
Duplex: Full

(or you just paste the entire thing.)

On my laptop, when it boots, it doesnt detect the link right, so in the init script I:

ifdown eth0
ifup eth0
ethtool --negotiate eth0
dhcp eth0

(that's from memory, so its not correct)


Instead of file copy, you could try a netcat or iperf benchmark. (google: netcat benchmark)

It might shed some more light.

Also, in ethtool, you can play with the offloads. (--show-offload and --offload options)
I've heard of some of the offloads being enabled, but causing problems. All off would be slowest but most compatible.

On the debian box:
The NAS is a bit more tricky... I had to hack the firmware to get SSH-access to it, and I've since lost the private key used to access it... It took me a week or so to figure out how to get access, and I'd have to re-research a lot of it to regain access, so I'll need some time on my hands before I can get that info...

"ethtool --show-offload eth0" gives:

rx, tx and tso gives me "Cannot set device rx csum settings: Operation not supported" when I try to disable, so new show-offload gives me:
...and no change in behaviour.

netcat and iperf both require access to the NAS as far as I can tell (right?) -So again, I can't do that at present (and the NAS is sort of limited in what it can do even when I do have access to it, it's not a "full" unix install though it is some sort of unix flavour... so it might not be possible at all)

Yes, yes it would.

The ethtool looks good.

I agree that since wifi works fine, that the cifs mount is probably not the problem.

We have eliminated everything... except... Aliens! :-)

Sorry, I don't think I can help you out on this one.

Alright then, everything is eliminated... thanks for the effort anyways...

I'll blame it on the aliens and switch to wifi... bizarre problems call for bizarre solutions I suppose.