Lunix Network tuning between SuSE versions

We have a SLES 11.2 box and another box running SLES 11.1 here in Akron.

We have a box in Luxembourg running SLES 11.1 and another running 11.2 (was a SLES 10.2 machine but has been temporarily replaced with the 11.2 one).

I can transfer files from Lux to Akron from either of the Lux machines to either of the Akron machines and I get nearly the full capability of the pipe (100 Mbps).

But I can’t transfer the same files from Akron to Lux at that same speed.


Akron 11.2 to Lux 11.2 = 74 Mpbs
Akron 11.2 to Lux 11.1 = 50 Mpbs

Akron 11.1 to Lux 11.2 = 27 Mpbs
Akron 11.1 to Lux 11.1 = 37 Mpbs

All Lux to Akron combinations get > 85 Mbps consistently. We really need all these combinations to work properly both directions.

I have looked at all parameters the internet says matters to transfer performance, but to no avail.

I don’t know if this is a sending limitation or a receiving problem. Our network guys say the pipe itself is fine.

So anyone have ideas of what to set on which machine to bring the rate from Akron to Lux up?

Thanks for any info.


PS: Akron 11.2 = 3.0.13-0.27-default kernal
11.1 =

   Lux 11.1  =
           11.2 = 3.0.34-0.7-default

Hash: SHA1

Transfer them how? Have you tried other sources/destinations at the
same sites? At different sites?

Good luck.
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


we have this fast connection only to these 4 boxes.
so i can’t go to any other boxes…

reread your note.

I was using scp. this does work fast from Lux to here. but then started using
rsync --compress --rsh=rsh …

this is faster, but still faster from Lux than to Lux.

Are all the network interfaces using the exact same device driver? On
each system post the output from (Please use code tags for the output);

ethtool ethX
hwinfo --netcard

Are they all going through the same switches on the routes to/from the

Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.34-0.7-default
up 10 days 16:44, 2 users, load average: 0.45, 0.36, 0.36
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

Hi Tom,

to rule out session initiation problems: are those transfers of sufficiently large files, taking more than a few seconds? (I’m thinking of delays when i.e. the Lux receiver host waits while unsuccessfully trying to resolve the DNS name of the remote host.)

Another probable cause might be differences in TCP window sizes or in max IP packet sizes - those would be things that the networkers might be able to check.

If the transfer takes long enough (minutes?) it might be interesting to monitor the bandwidth use across the whole copy process - i.e. do you ever get the same max load as in the other direction? Do you get a constant load or is something “stepping on the link” during the transfer? One more thing to check is the actual load on the link - is it fully loaded, despite the slow netto speed seen with the transfer?

A last thing that comes to mind is actual asymmetric bandwidth at the link level: If (for whatever reason) the available bandwidth towards Lux is lower than when sending from Lux, then you’d see this type of behaviour, too.


Toss wireshark on ( any of these boxes ) and do your transfer. You can deduce which is slow, how big the window size is, fragmentation, … and “all parameters the internet says matters to transfer performance.” You may find retransmissions, or whatever. Some times the issue will be in the poor selection of MTU’s, which can be an issue with ICMP is filtered. But thats the first step… observe what is actually happening on the wire.

– Bob