Ah, but does artificially increasing RWIN cause errors?

[gonzalez]

I've been trying out the SG TCP Optimiser, having previously manually checked my MTU at both the Ethernet level and the PPP level by pinging from a command prompt. Given that my OS is Win2K and I'm on a PPPoA ADSL connection, the ping value of 1472, and therefore the total MTU of 1500, is correct on my setup.

Having run the TCP Analyser, it determined my TCP Window to be 17520, with TTL at 124. It recommended using a Window size of 128480 instead, so I've subsequently used the Optimiser to do that. I applied Windows scaling.

The results have been highly variable, to say the least. Using Firefox, the acquisition of webpages can sometimes be fast but mostly is slower than before and often gives rise to webpages downloading in a very bitty fashion. Sometimes, I've even got timeouts. With Internet Explorer (IE6), the situation is altogether different, with pretty much all webpages downloading fast and certainly a noticeable increase in downloading speed from before. Mind you, a lot of this has involved webpages already stored in cache, so perhaps this is not that relevant.

Now, what I don't quite understand is this. My nominal ISP connection speed is 2M bits/sec DL, with 256K bits/sec UL, and after using the Optimiser, an independent speed check on my connection still returned real-world speeds of 1883 kbits/sec and 239 kbits/sec (allowing for packet overheads, etc). However, TCP Analyser is telling me that my speed (BDP) is 5139 kbits/sec at a latency of 200msec and 2055K bits/sec at 500msec. These values are far larger than my official connection speed, so how can those two figures be correct?

Surely, if you try to operate the connection at a speed higher than it's supposed to take, errors will be generated, and perhaps by forcing an RWIN value those errors might never get corrected? Error-free downloading is crucial for software updating, as I'm sure you'll agree.

To check this out a bit further, I've tried downloading a popular, large file from a couple of websites and I've done this with both Firefox and IE. According to the DL dialogs, a 10.5MB file downloaded in just 31 secs, for example. If you work that one out, it equates to an average DL speed of around 2.7M bits/sec. That's bigger than the capacity of my connection, so how can that be so?!

What I'm concerned about is whether we're all tweaking the TCP Window at the expense of errors. Can someone comment on this? My router-modem's statistics hasn't hitherto ever sensed any errors at all, in either direction, and still doesn't seem to have found any.

Incidentally, I've just checked that my 1472 ping value is still correctly set (total MTU of 1500 = 1472 + overhead of 28), by going to a command prompt and manually pinging a few different servers on the Internet of my own choosing. With my current TCP Window setting of 128480, I've returned round-trip delays of between 60msec and 150msec, with TTL values that range from 30 to 245. At the very least, it looks as though the Optimiser-assigned TTL value is well below the correct one. Right?

Lastly, I would comment that, as far as I've been able to gather from the Win2K White Paper published on this website, Win2K does have a default TCP Window of 17520 but the OS automatically adjusts this value, up to 64240, during connection sessions. So, why the need to use the TCP Optimiser?

Here's a summary of my current setup:

Win2KSP4
PPPoA
Total MTU 1500
nominal ISP ADSL connection 2M bits/sec; 256K bits/sec
RWIN 128480
MSS 1460
TTL 60

[trogers]

What exactly do you mean by the word "errors"? Do you mean excessive packet losses?

[mccoffee]

It's an urban myth that higher rwins cause packet losses show me anything other then stuff from dsl reprots i'll read it ,and consider it. HOwever though an ridcouslly rwin has been know to crash systems i'm talking 999999999.

NO the values remmocended here at sg will not cause any packet loss.

[trogers]

If my latency do not exceed 100 ms, I will use a RWIN setting of 64240 for MTU of 1500 and window scaling off. Also, my GlobalMaxTcpWindowSize and TcpWindowSize will also be set at 64240.

This setting will allow a throughput limit in excess of 2 Mbps. There is no need to use RWIN at 128480 unless your subscribed speed is in the 3-6 Mbps range.

[gonzalez]

First, apologies for the delay in replying; I was suddenly ill yesterday. Second, let me just say that I'm no expert in this area of networking at all and that I'm merely summising on what little knowledge I do have of it.

By 'errors', I meant either complete packet losses. end-to-end, or corrupted data.

I'm in no way trying to be over-critical but simply playing devil's advocate here. The way I view this tweaking is that it's all very fine to increase downloading speeds of webpages but it's a completely different consideration when downloading some software that you intend using. With webpages, it wouldn't matter if there were data errors but, with software, it obviously would and indeed could prove utterly disasterous.

I haven't really studied my file download sequences that carefully before but, since tweaking RWIN way up, I've noticed that my download speed starts at around 650K bytes/sec and, as the download progresses, it slowly decreases to about 200K bytes/sec. Well, 650K is well beyond my official connection speed (2M bits/sec), so doesn't that suggest that something is badly wrong? Or is it normal to see peaks that are far above the subscribed speed? My thought is that if my connection's not configured at the exchange to handle a nominal 650K (5.2M bits/sec), then in all probability the data reaching my machine will be lossy and corrupted.

I'm reminded of the peak speeds when using 56K dialup. There, it was admissible to experience peak rates of up to 115K bits/sec. However, this is ADSL, not dialup. Anyone got sufficient hardware knowledge in this area to state whether this peak rate in ADSL IS indeed normal and admissible?

I've had no comment about my tested-for TTL values, either. Surely, there's no one correct TTL value, because latency will vary, depending on website you're trying to reach, or even time of day (contention, re-routing)? Therefore, shouldn't you set the highest TTL that you expect? Perhaps having a TTL as low as 64 accounts for why I got timeouts the other day.

[mccoffee]

With thte ttl you best bet is use the same value of on the isp's end that vaule and mtu helps withe convergence. NO an higher rwin will not do harm it can cause a blue sreen however there is nothing carved in stone anywhere about right value/wrong value.

[gonzalez]

I've now put TTL back to 64, as I've realised that that's either a timeout period or the max no. of hops. But I've now set RWIN to 64420, as that's within Win2K's normal auto-range for that parameter. Trying out some file downloads with RWIN=64240, the peak download rate is now limited to below 2M bits/sec.

I might or might not have still got this right. I think it needs some input from someone with some in-depth knowledge of this aspect of DSL operation.

[trogers]

This would be my cablenut custom settings for 1-2 Mbps, MTU 1500, latency = 100-250ms.

64240
64240
1
100
240
640
819200
64000
150400
0
12800
32
4096
1
1
0
64240
8000
32768
5000000
1
1
1
1
2
100
80
1460
1460
30
0
64240
20
10
64
0
6
240

[gonzalez]

Two questions, trogers. First, have you any personal experience of using those recommended values with Win2K? Second, can you point me to the parameter names for each of those values, please?

[mccoffee]

http://www.broadbandnuts.com/index.php?page=9 defaniations of value I would highly suggest reading micrsoft's white pages for 2k/xp it's the same for both same with 2003 http://www.cisco.com/warp/public/535/4.html this is cisco's which i've been trained in it not certified yet will be soon hopefully
.
http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx

[gonzalez]

mccoffee,

Thanks for those links.

trogers,

Okay, you've typed that long list of what you believe to be my optimum TCP values and they appear to have been derived from the definitions seen in mccoffee's 'broadbandnuts' link. However, you've listed 38 values and yet there are only 37 definitions, so which is the one in the list that shouldn't be there?

Do those definitions, and the particular values that go with them, apply to both PPPoA and PPPoE? There seems to be no mention of that in the definitions and yet some values do depend on the type of PPP connection? Mine's specifically a PPPoA connection.

[Philip]

.........
I haven't really studied my file download sequences that carefully before but, since tweaking RWIN way up, I've noticed that my download speed starts at around 650K bytes/sec and, as the download progresses, it slowly decreases to about 200K bytes/sec. Well, 650K is well beyond my official connection speed (2M bits/sec), so doesn't that suggest that something is badly wrong? Or is it normal to see peaks that are far above the subscribed speed? My thought is that if my connection's not configured at the exchange to handle a nominal 650K (5.2M bits/sec), then in all probability the data reaching my machine will be lossy and corrupted.

I'm reminded of the peak speeds when using 56K dialup. There, it was admissible to experience peak rates of up to 115K bits/sec. However, this is ADSL, not dialup. Anyone got sufficient hardware knowledge in this area to state whether this peak rate in ADSL IS indeed normal and admissible?

Remember that RWIN is a buffer. When you start your download, even before you choose the directory, or click OK, your browser will have started the download and filled up to the amount of RWIN with data, that's why initially your download "seems" faster. It will then settle down to the actual transfer rate. Also, regardless of the ADSL "peak rate" - your hardware is very capable of handling such speeds, and even if it peaks it is not going to introduce any errors. Even in the presense of errors, TCP/IP transfers are lossless - meaning if a packet is corrupt, it gets retransmitted. Even in the presense of packet loss, you get every packet on the other end.


I've had no comment about my tested-for TTL values, either. Surely, there's no one correct TTL value, because latency will vary, depending on website you're trying to reach, or even time of day (contention, re-routing)? Therefore, shouldn't you set the highest TTL that you expect? Perhaps having a TTL as low as 64 accounts for why I got timeouts the other day.

TTL gets increased by at least 1 with every hop. but it is also a timer... It is very unlikely you will encounter over 32 hops, or that a packet will take over 32 seconds (32000 ping) to get discarded. TTL needs to be large enough, and once it is it does not affect transfers.


Now, what I don't quite understand is this. My nominal ISP connection speed is 2M bits/sec DL, with 256K bits/sec UL, and after using the Optimiser, an independent speed check on my connection still returned real-world speeds of 1883 kbits/sec and 239 kbits/sec (allowing for packet overheads, etc). However, TCP Analyser is telling me that my speed (BDP) is 5139 kbits/sec at a latency of 200msec and 2055K bits/sec at 500msec. These values are far larger than my official connection speed, so how can those two figures be correct?

What the Analyzer is reporting is that, given your current RWIN value, if there was 200/500 latency, you could theoretically reach these speeds. All it is saying is, if you had the bandwidth, your RWIN value would still limit you to these speeds.


Lastly, I would comment that, as far as I've been able to gather from the Win2K White Paper published on this website, Win2K does have a default TCP Window of 17520 but the OS automatically adjusts this value, up to 64240, during connection sessions. So, why the need to use the TCP Optimiser?

The Windows default value does not work well for broadband internet connections. The large-latency / high-speed combination usually requires a scaled RWIN value much higher than the Windows defaults. There are a number of other parameters that also have some effect, but you're right, the RWIN value is the most important one. The TCP Optimizer uses the bandwidth*delay product to calculate the correct RWIN value, it also makes scaled RWIN values RFC compliant (above 2^16, or 65535 RWIN should be increased by a scale factor that's a power of 2, which actually resides in the TCP optional 1323 headers)... In addition, the Optimizer maximizes the unscaled RWIN value, etc. And I am not even discussing the advanced options.


I hope all this answers some questions :)

[trogers]

The values I have given are settings for the Cablenut Adjuster program in www.cablenut.com but I use TCP Optimizer for my first tweak as it makes some additional adjustments not performed by cablenut. Then I use cablenut for fine tuning as it has an easier presentation and access to those fields.

Yes, I am using the final results similar to what I have suggested to you but adjusted for MTU 1492.

[mccoffee]

Remember that RWIN is a buffer. When you start your download, even before you choose the directory, or click OK, your browser will have started the download and filled up to the amount of RWIN with data, that's why initially your download "seems" faster. It will then settle down to the actual transfer rate. Also, regardless of the ADSL "peak rate" - your hardware is very capable of handling such speeds, and even if it peaks it is not going to introduce any errors. Even in the presense of errors, TCP/IP transfers are lossless - meaning if a packet is corrupt, it gets retransmitted. Even in the presense of packet loss, you get every packet on the other end.



TTL gets increased by at least 1 with every hop. but it is also a timer... It is very unlikely you will encounter over 32 hops, or that a packet will take over 32 seconds (32000 ping) to get discarded. TTL needs to be large enough, and once it is it does not affect transfers.


What the Analyzer is reporting is that, given your current RWIN value, if there was 200/500 latency, you could theoretically reach these speeds. All it is saying is, if you had the bandwidth, your RWIN value would still limit you to these speeds.


The Windows default value does not work well for broadband internet connections. The large-latency / high-speed combination usually requires a scaled RWIN value much higher than the Windows defaults. There are a number of other parameters that also have some effect, but you're right, the RWIN value is the most important one. The TCP Optimizer uses the bandwidth*delay product to calculate the correct RWIN value, it also makes scaled RWIN values RFC compliant (above 2^16, or 65535 RWIN should be increased by a scale factor that's a power of 2, which actually resides in the TCP optional 1323 headers)... In addition, the Optimizer maximizes the unscaled RWIN value, etc. And I am not even discussing the advanced options.


I hope all this answers some questions :)


A very well description Kudos :thumb: however though as far as Tcpwindowsize being the main value is kinda of sketchy. I'm not aruging ,or desagreeing either ,but the default recive window seems to the most important one since 2k/xp/2003 even though Tcpwindowsize, Globalmaxtcpwindowsize, Default recive window all go hand to hand, it's kinda odd though that the analyzer is picking the default recive window size as it's rwin. That being said why would use that recivewindow in it's header instead of tcpwindowsize like it did in 9x/me makes ya wonder.

Tcp is a connection oriented protocol which means it has errorchecking/corrections in place unlike udp even though udp is connectionless it does have some messures to fix/detect errors not as througho I can't spell lately more then every arg. No error checking/detection makes it faster: however not as accurate.

[gonzalez]

Thanks everyone, for your explanations, especially Philip.

Philip. as much as what you say seems to make sense in the round, the way you've described TCP suggests that it's a perfect A-B transmission mechanism, in that, end-to-end, it's apparently always lossless and error-free. Surely, that cannot be the case? For instance, when downloading from the Web, errors must occasionally occur (and unfortunately get inputted at the subscriber's computer).

Take, for example, the physical line quality issues involved when a subscriber makes a connection to a website. If the subscriber is running on a long line connection to the exchange, or otherwise has a high-attenuation line, he/she could be operating on the edge of getting corrupted packets every now and then. The question is 'How does TCP handle this? Does TCP attempt to correct packet errors but then, after so many, cause the line to be dropped, or what? And presumably TCP uses error-sensing based on simple parity, rather than on CRC, and both of those, anyway, are not guaranteed of delivering good packets 100% of the time'?

On the matter of the so-called Bandwidth Delay Product (BDP), I feel that that term hasn't been described on this website in the best possible way and indeed the units in which it's quoted don't seem to be correct. Would a better way of describing BDP be that it's "the peak instantaneous download rate, for a given latency"? When it comes to the BDP figures given by the SG Analyser for my own setup, the point that I was hitherto making was that TCP might well be capable of delivering packets to my computer initially at a peak rate of 600K Bytes/sec under low-latency conditions but would probably be dropped on the ground and retransmitted, because my actual line is currently contracted to support only data rates up to 250K Bytes/sec (2M bits/sec). Indeed, by the time that a sizeable download on my line has completed, the Download Manager has, by then, only flattened out at 250K Bytes/sec. Or are you sticking by your contention that the 2M bits/sec line will convey all of those earlier, higher-rate packets properly? I suppose this boils down to the question 'Is the subscribed connection speed with one's ISP an AVERAGE connection speed, or is it specifically the PEAK speed at which one's line with the ISP can operate?'

[Philip]

A very well description Kudos :thumb: however though as far as Tcpwindowsize being the main value is kinda of sketchy. I'm not aruging ,or desagreeing either ,but the default recive window seems to the most important one since 2k/xp/2003 even though Tcpwindowsize, Globalmaxtcpwindowsize, Default recive window all go hand to hand, it's kinda odd though that the analyzer is picking the default recive window size as it's rwin. That being said why would use that recivewindow in it's header instead of tcpwindowsize like it did in 9x/me makes ya wonder.

Tcp is a connection oriented protocol which means it has errorchecking/corrections in place unlike udp even though udp is connectionless it does have some messures to fix/detect errors not as througho I can't spell lately more then every arg. No error checking/detection makes it faster: however not as accurate.

I'm using the TcpWindowSize and RWIN, or TCP Receive Window, or Default Receive Winodow terms interchangeably. They all affect the same ONE value in TCP packet headers, that the Analyzer reports, and that I said is important for tweaking.

There is some confusion, because of the fact that there are 3/4 places in the Windows Registry for this value, one is setting it globally, the other for each adapter, one copy in the AFD branch, etc. Then, in different versions of Windows different Registry values take precedence and go out in the actual TCP packets during the TCP handshake. Even though there might be some difference in how Windows handles the different values internally, ultimately it comes up with one of them and that ONE goes out to the network.

For a proof, try taking out the AFD value and see what the analyzer reports... It's going to be one of the others (under Win XP SP2). Under Win XP SP1, it's the other way around, the values in the TCP branch override the AFD value...

Ultimatey they all affect the same one value that exists in TCP packets.