-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 14 July 2004 16:02, Mick Mearns wrote: > Yes - that fixed it. > Although I must admit I have no idea what the heck you are talking > about ;) The TCP part of the TCP/IP header on every packet has a place for negotiating how much data to keep 'in transit', the 'window'. Originally TCP set aside 16 bits in the header to specify window sizes only up to 64K. In the case of high bandwidth links that have high latency due to the sheer distance they travel, 64K isn't enough to allow TCP to saturate the pipe, since it takes longer to send back the ACKs for the packets than it takes to send 64K. RFC1323 from May 1992 (http://www.networksorcery.com/enp/rfc/rfc1323.txt ) is designed to fix this by keeping the 16-bit field for window size, but expanding the logical window size to 32-bits (allowing 4GB to be in transit(!)) by adding a 0-16 bit shifting factor ("Window scaling") for compatability. The older kernels do not make use of this by default, they keep with a 0 window scale factor and so can cope with up to 64K window sizes like pre-RFC1323 TCP. But the newer kernels use the scaling factor to allow >64K windows, which may be able to make better use of your bandwidth. The problem is some routers out there blow chunks when they see a TCP connection wanting >64K window sizes. Eventually, hopefully, the routers will all get upgraded and we can use the better window sizes. But until that happy day, some sites will grind to a halt unless you use the workaround. - -Andy - -- Automatic actions for USB cameras, cardreaders, memory sticks, MP3 players http://warmcat.com/usbautocam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9WKyjKeDCxMJCTIRAjQqAJ9ojVnvjYQDxKDFlTigMkBnjsNPrgCfdCUf jSo1/cDZnsgnQZJyL5lnJXA= =mlSq -----END PGP SIGNATURE-----
