Hi, On Mon, 26 Jun 2000 noesis@inaxx.net wrote:
I tried different NICs and different drivers to no avail. Since NT was not experiencing the slowdown I began to suspect the TCP implementation on S.u.S.E. After much research I came across the following resource: Pittsburgh Supercomputing Center (PSC), Carnegie Mellon University http://www.psc.edu/networking/perf_tune.html and the kernel docs on www.linuxhq.com. Lo, and behold, the information I found indicated that newer Linux kernels since have implemented different defaults for TCP/IP per RFC1323. One of these was setting tcp_timestamps TRUE. According to the performance pages from CM, one thing to do was to set these back to false. i.e.:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
Wow! What a difference in speed!!!
Question: why isn't this info "front and center" at the S.u.S.E. web site?? Am I the only one who had this problem or am I the only one who took so long to figure it out.
Replies to my email address are welcome if you want to contact me. I'm dropping out of the mail list due to time constraints.
I have forwarded your question to our developers, because I too was curious about this. Here are some quotes from the resulting thread: [SNIP] When this helps it means very likely that his Internet connection runs via a line with broken Van Jacobsen Header compression that cannot handle TCP options properly (e.g. older PortMasters and Ascends have this problem) [SNIP] [SNIP]
There are many options to tune the TCP/IP stack, I think. You can also disable the so called "Nagle Algorithm" with the socket option TCP_NODELAY, e.g.
The question is: What kind of side effects does it have?
Turning off nagle algorithm will cause a bit less latency at the cost of a lot more packets being sent over the line. Overall it will probably be slower (TCP_NODELAY is mostly for very delay sensitive connections like a remote X11 display where you want a snappy mouse pointer). Most protocols are not so delay sensitive. [SNIP] [SNIP]
Will all services work together in all situations with this kind of modifications?
Turning off time stamps should not harm, but it is better when they are enabled, especially on lines with high bandwidth to let PAWS (protection against wrapped sequence numbers) still work. If you really want to tune the stack for high speed it makes more sense to increase the default TCP window (via /proc/sys/net/core/[rw]mem_{default,max}). This requires that window scaling (/proc/sys/net/ipv4/tcp_windowscaling) is turned on. It makes sense for very fast links (Fast Ethernet and above) with longer latency or very long latency links (like satellite connections)
I am sure, the networking gurus who implemented these defaults know what they are doing.
The problems with the broken VanJ compression are known, but it was decided to still keep it on. [SNIP] I hope, this gives you some background! It seems like these optimizations can do more harm than help under certain circumstances. Bye, LenZ -- ------------------------------------------------------------------ Lenz Grimmer SuSE GmbH mailto:grimmer@suse.de Schanzaeckerstr. 10 http://www.suse.de/~grimmer/ 90443 Nuernberg, Germany There are two sides to a question, politicians take both. -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/