100M : Small Download Speed Upgrade

[Chrysalis]

Originally Posted by Ignitionnet

Why would window size affect a TCP ping?



Yep.

not sure, it was just a theory.

When I used to run windows XP which had no tcp auto tuning, smaller tcp packets were noticebly slower to process with large tcp buffers configured as tcp can be tuned for one type of use but it then become suboptimal for another type of use hence the use of auto tuning in modern operating systems.

Delayed acks will slow down single small tcp packets, the most public example been WoW where gamers were disabling delayed acks in windows to halve their tcp latency in the game, large tcp windows I assumed can have an affect as well but its only a theory I havent done any testing on it.

To test my theory on windows vista or 7 one could disable auto tuning which will force a tcp buffer of 64k, this isnt huge but is bigger than what auto tuning should use for small single packets, on wireless interfaces the default buffer is much smaller than 64k. On XP one could set a high buffer size manually eg. 256k, check the ping on speedtest.net then try again with a 4k buffer size and see if it noticebly drops. If it doesnt I am wrong

[qasdfdsaq]

Originally Posted by Ignitionnet

Why would window size affect a TCP ping?

Don't think speedtest.net even uses an actual TCP ping of any kind. After all, doing so would stop it working from behind most NATs.

[Andrewcrawford23]

Originally Posted by qasdfdsaq

Don't think speedtest.net even uses an actual TCP ping of any kind. After all, doing so would stop it working from behind most NATs.

not in the way that command prompt ping command does no, but it does use tcp/udp packets

---------- Post added at 10:29 ---------- Previous post was at 10:25 ----------

Originally Posted by Ignitionnet

Why would window size affect a TCP ping?

.

generally it wouldnt unless the user has mucked about witht he window size badly and no used something liek tcpip optimiser , basically you set the window size let says to 1024000000 instead of say 2048 (no i cant remmeber the windows size off the top of my head jsut a plain example being obviously different) then sendinga a packet not jsut tcp ping packet would be affected in time

[Ignitionnet]

The answer is it doesn't. TCP pings either use a SYN and measure time until they receive a SYN/ACK or if a session is in progress they send an invalid ACK and wait for a RST.

Window size, scaling, selective ackowledgement, etc have no impact on these.

[Ignitionnet]

Originally Posted by Chrysalis

not sure, it was just a theory.

When I used to run windows XP which had no tcp auto tuning, smaller tcp packets were noticebly slower to process with large tcp buffers configured as tcp can be tuned for one type of use but it then become suboptimal for another type of use hence the use of auto tuning in modern operating systems.

Delayed acks will slow down single small tcp packets, the most public example been WoW where gamers were disabling delayed acks in windows to halve their tcp latency in the game, large tcp windows I assumed can have an affect as well but its only a theory I havent done any testing on it.

To test my theory on windows vista or 7 one could disable auto tuning which will force a tcp buffer of 64k, this isnt huge but is bigger than what auto tuning should use for small single packets, on wireless interfaces the default buffer is much smaller than 64k. On XP one could set a high buffer size manually eg. 256k, check the ping on speedtest.net then try again with a 4k buffer size and see if it noticebly drops. If it doesnt I am wrong

TCP window sizes don't work like that. Window sizes are a maximum and are sent to inform the remote side how much data it may have outstanding and awaiting acknowledgement. When devices send their acknowledgements is decided by their local TCP stack in conjunction with information in the initial 3 way handshake, specifically whether the bit is set in the headers indicating that SACK is acceptable and is nothing to do with window size.

You're thinking of Nagle's algorithm I suspect.

[Andrewcrawford23]

Originally Posted by Ignitionnet

The answer is it doesn't. TCP pings either use a SYN and measure time until they receive a SYN/ACK or if a session is in progress they send an invalid ACK and wait for a RST.

Window size, scaling, selective ackowledgement, etc have no impact on these.

ive done some tests to check apart from it a pain in the back side to really change the windows size in linux and windows as they use automatic calculatiosn to adjsut window size to what ti sees as best.... but i did see a difference in ping acklodegements by about 10-20ms but its intial test i will really need to benchmark it witha a clena system and remove all other variables until then ill agree with you it probally doesnt affect

[Ignitionnet]

Originally Posted by Andrewcrawford23

ive done some tests to check apart from it a pain in the back side to really change the windows size in linux and windows as they use automatic calculatiosn to adjsut window size to what ti sees as best.... but i did see a difference in ping acklodegements by about 10-20ms but its intial test i will really need to benchmark it witha a clena system and remove all other variables until then ill agree with you it probally doesnt affect

I had 10 minutes.

Here's how the latency test used by Speedtest.net works - the app requests a file called latency.txt from the server with a parameter specific to that test:

GET /speedtest/latency.txt?x=1325619351882 HTTP/1.1
Host: www.speedtest.bbmax.co.uk
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
Accept: */*
Referer: http://c.speedtest.net/flash/speedtest.swf?v=297277
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

The server responds:

HTTP/1.1 200 OK
Date: Tue, 03 Jan 2012 19:36:07 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Fri, 29 Sep 2006 15:09:15 GMT
ETag: "cc01f2-a-a17bcc0"
Accept-Ranges: bytes
Content-Length: 10
Connection: close
Content-Type: text/plain; charset=UTF-8
test=test

It does this a few times.

The app does some kind of timing between the two. Window size is a complete non-issue as the window is at no point approached and more relevantly as I said window sizes don't work like that. Nagle might be more of a factor as the app will send its request which will then sit on the TCP stack of the host machine waiting for a full MSS of data to be sent.

334 6.001751 192.168.10.12 85.233.160.167 HTTP GET /speedtest/latency.txt?x=1325619351882 HTTP/1.1
Frame 334: 489 bytes on wire (3912 bits), 489 bytes captured (3912 bits)
Arrival Time: Jan 3, 2012 19:35:51.980248000 GMT Standard Time

337 6.021832 85.233.160.167 192.168.10.12 HTTP HTTP/1.1 200 OK (text/plain)
Frame 337: 325 bytes on wire (2600 bits), 325 bytes captured (2600 bits)
Arrival Time: Jan 3, 2012 19:35:52.000329000 GMT Standard Time

[Chrysalis]

I agree nagle will be the most likely factor, the tcp window sizing on the pings was only a untested theory although on web browsing it does have an effect if too big.

[Ignitionnet]

Originally Posted by Chrysalis

I agree nagle will be the most likely factor, the tcp window sizing on the pings was only a untested theory although on web browsing it does have an effect if too big.

Nope that's probably Nagle and TCP delayed acks misbehaving.

Basic TCP. Window size indicates data that can be sent unacked, it doesn't indicate anything about amount of data that must be sent. In addition it gives the maximum TCP window size, this is a value that changes and starts of far smaller than the maximum due to TCP slow start.

The only loss of efficiency that an overly large window size can cause is where it's an odd multiple that doesn't fit too well with the server's transmit window and even this will cap transfer speeds at marginally below maximum, web browsing doesn't push bandwidth very hard.

EDIT:

Here's the start of a TCP transaction, note the window sizes - these are due to TCP slow start while TCP works out the link speed.

2269 77.606093 192.168.10.12 88.221.88.80 TCP 49402 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1
2301 77.640534 88.221.88.80 192.168.10.12 TCP http > 49402 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=5
2302 77.640569 192.168.10.12 88.221.88.80 TCP 49402 > http [ACK] Seq=1 Ack=1 Win=17520 Len=0
2303 77.641481 192.168.10.12 88.221.88.80 HTTP GET /0/RTMS/Image/SPRO-Seller_C2C-ZIF_AugustHeader_Active_Q311-325x100.gi.gif HTTP/1.1
2380 77.676750 88.221.88.80 192.168.10.12 TCP http > 49402 [ACK] Seq=1 Ack=372 Win=6912 Len=0

[Andrewcrawford23]

Originally Posted by Ignitionnet

Nope that's probably Nagle and TCP delayed acks misbehaving.

Basic TCP. Window size indicates data that can be sent unacked, it doesn't indicate anything about amount of data that must be sent. In addition it gives the maximum TCP window size, this is a value that changes and starts of far smaller than the maximum due to TCP slow start.

The only loss of efficiency that an overly large window size can cause is where it's an odd multiple that doesn't fit too well with the server's transmit window and even this will cap transfer speeds at marginally below maximum, web browsing doesn't push bandwidth very hard.

web browsing generally doesnt push bandwiwdth very hard unless oyu have idiot webmaster who design there pages very large makign them have more data than require ie code thought bbc article on web page growing from i think 50kb to 70kb in year one was quite interesting :0 not sure the exact figure jsut know bbc reported them growing quite a bit in a year i think it had a headline like people aint the only one utting on weight

[Ignitionnet]

Originally Posted by Andrewcrawford23

web browsing generally doesnt push bandwiwdth very hard unless oyu have idiot webmaster who design there pages very large makign them have more data than require ie code thought bbc article on web page growing from i think 50kb to 70kb in year one was quite interesting :0 not sure the exact figure jsut know bbc reported them growing quite a bit in a year i think it had a headline like people aint the only one utting on weight

Inefficiently coded web pages have interdependencies that stop them being loaded quickly as many segments have to be loaded consecutively rather than in parallel, it's not about the amount of data on the page.

[Chrysalis]

Originally Posted by Ignitionnet

Nope that's probably Nagle and TCP delayed acks misbehaving.

Basic TCP. Window size indicates data that can be sent unacked, it doesn't indicate anything about amount of data that must be sent. In addition it gives the maximum TCP window size, this is a value that changes and starts of far smaller than the maximum due to TCP slow start.

The only loss of efficiency that an overly large window size can cause is where it's an odd multiple that doesn't fit too well with the server's transmit window and even this will cap transfer speeds at marginally below maximum, web browsing doesn't push bandwidth very hard.

EDIT:

Here's the start of a TCP transaction, note the window sizes - these are due to TCP slow start while TCP works out the link speed.

2269 77.606093 192.168.10.12 88.221.88.80 TCP 49402 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1
2301 77.640534 88.221.88.80 192.168.10.12 TCP http > 49402 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=5
2302 77.640569 192.168.10.12 88.221.88.80 TCP 49402 > http [ACK] Seq=1 Ack=1 Win=17520 Len=0
2303 77.641481 192.168.10.12 88.221.88.80 HTTP GET /0/RTMS/Image/SPRO-Seller_C2C-ZIF_AugustHeader_Active_Q311-325x100.gi.gif HTTP/1.1
2380 77.676750 88.221.88.80 192.168.10.12 TCP http > 49402 [ACK] Seq=1 Ack=372 Win=6912 Len=0

This I have experimented, both on servers and my desktop.

On servers if I eg. set the tcp window to 2meg, assuming there be no downsides other than faster resource saturation, I soon discovered it absolutely murdered throughput in specific scenarios, not 100% of the time but a significant amount of the time.

On a XP desktop if I set the tcp window to 256k then downloading files was faster it even helped slower adsl never mind a faster VM connection, however web browsing was most defenitly slower, loading little smilies on sites like this and text pages was slower.

Whether this is down to bad/buggy implementation on the OS's in question or by design I dont know but I tested the results numerous times.

Interesting as well is delayed acks works superior on linux over bsd and windows, but linux are not adhering to RFC guidelines, they disable nagle when the data been transferred is small so it doesnt hinder stuff it likely wont benefit.

One downside with large windows is if there is congestion/loss, a retransmit is more expensive.

With auto tuning however its ok to set max window sizes very large (multiple meg) as it always scales up from a small size.

[Ignitionnet]

You'll forgive me if I don't take too authoritatively this experimentation given you may not be aware of the various parameters that could affect his tests. Case in point:

One downside with large windows is if there is congestion/loss, a retransmit is more expensive.

Wrong on multiple levels. Firstly windows start small and increase if transmission is smooth and quick - the whole point of TCP windows is that they are congestion control and respond to congestion / loss conditions. They must increase to higher levels in order to allow maximum throughput on high BDP links (Google it). This is a common feature of all TCP stacks, the only differences as far as windows go being how aggressively they increase window size post-loss and how they manage retransmission / duplicate acknowledgement.

Secondly a retransmit is not more expensive due to window sizes, it's more expensive due to cumulative or selective acknowledgements. When a retransmit happens window sizes will be reduced in case that retransmit was forced by congestion. Windows govern how much data can be sent before an acknowledgement must be received not how frequently data must be acknowledged and therefore how much data can be lost in one shot.

For your tests to be taken in any way seriously you need to be taking packet captures and analysing them so that you can see the sliding windows, retransmits, acknowledgement pattern, etc.

EDIT: The only negative impact of TCP windows being excessively large is in terms of buffers within kernels and routers being eaten as TCP pushes out big bursts of data to try and fill windows, although I'm sure given all the servers you run professionally you knew that. I've more than once had to have customers adjust buffer sizes on routers when devices behind them are running HSTCP to fill a long, wide pipe.