Hello,
i´m currently doing my diploma thesis at Nortel about TCP/IP over Satellite
in Linux. In the last few weeks we did some performance tests of both Linux
2.2.16 and 2.4.1 (and 2.4.7) over a satellite simulator channel (NiSTNet)
with bandwidth set to 2 MBit and delay set to 600 ms. Stacks had maximum
window-sizes set to over 200 KB and SACK and RFC1323 enabled and
applications set window sizes to the same values with setsockopt. All
worked well in Linux 2.2.16, with throughputs up to 1,95 Mbit for long
transfers and also not so bad throughputs with 10-7 bit error rates
simulated by Nistnet.
But when we tested with 2.4.1 and 2.4.7 with netperf and ftp we came accross
some strange issues: also everything worked well as long as we only had one
transfer at a time and no Bit Error rate set. But when we set a BER and
later set BER back to 0 the transfers wouldn´t run at the same transfer rate
as before without BER but at only the speeds with BER set. But this is no
satellite simulator issue (we also tried FreeBSD with dummynet and same
happened).
We did packet captures with tcpdump and saw that the sender wouldn´t open up
its tcp send window wide enough and every once in a while stall with its
sending.
This effect didn´t occur with 2.2.16 but all the kernel settings in
/proc/sys/net were the same !
Another strange effect with 2.4.x (which also didn´t occur with 2.2.16)
happened, when we started more than one netperf-session at a time by a
script simultaneously: when we started a single netperf-session afterwards
it wouldn´t achieve the throughput, it achieved before the
"multisession"-netperf-transfer, but only a transfer rate comparable to one
of the connections from the multisession-netperf-transfer ! This also didn´t
happen with 2.2.16 !
All of the above effects were reproducible and vanished after a restart of
the network with init 1 and afterwards init 3. Distribution used was SuSE
7.0.
It seems, as strange as this may sound, that the 2.4.x-kernel-series has
some kind of congestion window memory, that still remembers the congestion
window of a former tcp-transfer, at least it acts this way. But this would
in no way be conforming to the current tcp-standards !
I hope you can help me with this problem or at least direct me to someone
else who could help me. I already searched for maybe a sysctl to change in
/proc/sys/net which could change this behaviour, but none of them seems
appopriate.
By the way, what´s this no_cong, lo_cong, mod_cong-stuff in
/proc/sys/net/core ??
And something else: we use a SMC Etherpower II in one of our computers and
the driver for this card seems to be broken in 2.4.7 (it locks the system as
soon as you try a ping or the card is pinged from another machine) (in the
newsgroup for epic100-driver on www.sycld.com some other people already
reported this problem and said that the driver was still ok until 2.4.2, so
i also used the epic100-driver from 2.4.1 together with 2.4.7-kernel and
also tried a driver directly from SMC and both worked)
Thank you very much in advance !
Yours sincerely,
Bernd Sturm
ND Satcom
phone: 0049-7545 / 96-8847
mailto:Bernd.Sturm@xxxxxxxxxxxx
|