rmrucker

10-20-00, 08:20 AM

How did SpeedGuide come up with the number 372300? This number seems illogical to me as a default RWIN setting.

First off, very few people have a pipeline big enough to utilize this size RWIN. If RWIN is too high, your speed will be slower.

Second, at least in Win98, this size RWIN is not possible until you have updated vtcp.38 to v.4.10.2223.

Third, unlike the other recommended "really big" numbers (i.e., 186880, 93440), this number cannot be defined as a 16-bit binary number multiplied by a factor of 2 ("10" binary) -- as implied in RFC 1323.

If a really, really big RWIN was desired as a choice, why wasn't 373760 chosen?? It makes more sense.

This number follows in sequence with 93440 and 186880 (i.e., 186880 * 2 = 373760). It therefore meets the criteria of being a multiple of 1460 [although the utility of this criteria has been questioned]. And it is it is nicely 1460 * 2^8 (256)-- whatever that's worth! http://www.speedguide.net/ubb/smile.gif

NOTE: If you hate binary numbers -- stop reading here!!

Most importantly, unike 372,300 this number (373760) *can* be represented as a 16-bit binary number multipled by a power of 2 (10 binary). This *appears* to be a requirement for true Window Scaling to occur.

For example, in binary:

373760 = 101 10110100 00000000 = 10110110 10000000 * 1000

BUT...

372,300 = 101 10101110 01001100 cannot be represented as a "whole" 16-bit number multiplied by 1000.

For a brief history: Prior to RFC 1323, setting RWIN size was limited to a 16-bit number. Therefore, the size theoretically ranged from 0 to 65,535 (or 2^16 - 1).

When RFC 1323 was drafted, they wanted to increase the size of RWIN. They did NOT do this by simply adding more bits. Instead, they added a "scale factor" that had to be multiplied by the *16-bit number*. The "scale factor" is defined as a power of 2.

To get an RWIN >65,535, you must use Window *Scaling*. This takes a 16-bit binary number and multiplies it by a "scale factor". To have a valid RWIN >65535, you should be able to break down the binary number into a 16-bit base number times a power of 2.

As above:

373760 = 10110110 10000000 * 1000

or... 10110110 10000000 with a "scale factor" of 3. (2^3 = 1000 binary).

So, my vote is for SpeedGuide to change it's "really, really big" RWIN value to 373760. But -- way, way back to my original statement http://www.speedguide.net/ubb/wink.gif -- I do NOT feel this should be the *default* setting for every computer. I think a lot of people will find that this slows them down -- it's too damn big. This is only useful for really, really big pipelines or really, really high latencies.

You constructive comments are greatly appreciated. Please send flames to my email address. Thanks.

First off, very few people have a pipeline big enough to utilize this size RWIN. If RWIN is too high, your speed will be slower.

Second, at least in Win98, this size RWIN is not possible until you have updated vtcp.38 to v.4.10.2223.

Third, unlike the other recommended "really big" numbers (i.e., 186880, 93440), this number cannot be defined as a 16-bit binary number multiplied by a factor of 2 ("10" binary) -- as implied in RFC 1323.

If a really, really big RWIN was desired as a choice, why wasn't 373760 chosen?? It makes more sense.

This number follows in sequence with 93440 and 186880 (i.e., 186880 * 2 = 373760). It therefore meets the criteria of being a multiple of 1460 [although the utility of this criteria has been questioned]. And it is it is nicely 1460 * 2^8 (256)-- whatever that's worth! http://www.speedguide.net/ubb/smile.gif

NOTE: If you hate binary numbers -- stop reading here!!

Most importantly, unike 372,300 this number (373760) *can* be represented as a 16-bit binary number multipled by a power of 2 (10 binary). This *appears* to be a requirement for true Window Scaling to occur.

For example, in binary:

373760 = 101 10110100 00000000 = 10110110 10000000 * 1000

BUT...

372,300 = 101 10101110 01001100 cannot be represented as a "whole" 16-bit number multiplied by 1000.

For a brief history: Prior to RFC 1323, setting RWIN size was limited to a 16-bit number. Therefore, the size theoretically ranged from 0 to 65,535 (or 2^16 - 1).

When RFC 1323 was drafted, they wanted to increase the size of RWIN. They did NOT do this by simply adding more bits. Instead, they added a "scale factor" that had to be multiplied by the *16-bit number*. The "scale factor" is defined as a power of 2.

To get an RWIN >65,535, you must use Window *Scaling*. This takes a 16-bit binary number and multiplies it by a "scale factor". To have a valid RWIN >65535, you should be able to break down the binary number into a 16-bit base number times a power of 2.

As above:

373760 = 10110110 10000000 * 1000

or... 10110110 10000000 with a "scale factor" of 3. (2^3 = 1000 binary).

So, my vote is for SpeedGuide to change it's "really, really big" RWIN value to 373760. But -- way, way back to my original statement http://www.speedguide.net/ubb/wink.gif -- I do NOT feel this should be the *default* setting for every computer. I think a lot of people will find that this slows them down -- it's too damn big. This is only useful for really, really big pipelines or really, really high latencies.

You constructive comments are greatly appreciated. Please send flames to my email address. Thanks.