Page 1 of 5 12345 LastLast
Results 1 to 15 of 73

Thread: Who decided on 372300??

  1. #1

    Exclamation Who decided on 372300??

    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!

    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


    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 -- 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.

  2. #2
    Kip Patterson



  3. #3


    I totally agree with you! My RWIN is set to 40656. I used a max avg. ping time of 200 ms. My DSL line is 1.5/256

    1500 * 1024 = 1536000

    1536000 * .2s = 307200

    307200 / 8 = 38400

    The MSS my machine is capable of handling is 1452.

    38400 / 1452 = 26.44

    Rounding up to the next even multiple (28) you get a RWIN value of 1452 * 28 or 40656.

    Now of course during 3-way handshaking the other host may SYN/ACK back with a smaller MSS. In that case Win2K will use the next multiple of the smaller MSS that creates an RWIN no less than your desired RWIN. I watched this with a monitor last night.


  4. #4


    Set it to 65535...........


  5. #5


    65535 also seems to give me the best throughput. When I had Win98 and first applied the SG patch, there was a noticeable increase in my download speed, but once I used an RWIN of 65535 the speeds were even greater. I'm gonna give that 373760 a try and see what happens.

  6. #6


    uhhh! uhhh! what? The integral of x + 2xy - 3
    as 3 approaches 0 = ? I hope to know what the h#$$ you guys are talking about one day I'm just a cable dog.Me thinks me has a headache after reading that first post.

    It is the mark of an educated mind to be able to entertain a thought without accepting it."

    [This message has been edited by therealcableguy (edited 10-20-2000).]

  7. #7


    Geeezz! therealcableguy, I told you to stop reading *before* it got too mathematical!

    Kip and TRS, thanks for the input. Steve, you are right -- most people could/should set it to 65,535. But there are some out there with "big pipes" that can use higher. (I wish I was one of them). Prey521, you may not get better speeds at that high an RWIN setting UNLESS you've got a big, fat pipe!

    I'll sit and wait for Philip, et al to comment...

    [This message has been edited by rmrucker (edited 10-20-2000).]

  8. #8
    Administrator Philip's Avatar
    Join Date
    May 1999
    Jacksonville, Florida, United States
    Blog Entries


    First of all, you're right, I have to agree with 373760 making a bit more sence than 372300.

    I have a couple of comments though:

    1. Why would you think a higher RWIN value would slow down your connection (in cases where everything else is equal and Windows scaling is enabled ) ?

    2. Theoretically, RWIN shouldn't be the limiting factor in your connection. For example, I've seen 6Mbit downloads on a simple residential cable modem with RR. If you consider that some sites can have high latency, here's the minimum numbers for RWIN using the bandwidth*delay product :

    50ms - 37,500
    100ms - 75,000
    200ms - 150,000
    300ms - 225,000
    400ms - 300,000
    500ms - 375,000

    So a RWIN value of ~373000 would ensure uninterrupted download at up to 6Mbit with a theoretical delay of up to ~500ms...

    All this just shows the reasoning behind using such high numbers. Although the numbers are somewhat high for most DSL users, the large RWIN value should not affect throghput in a negative way.

    The only catch I can think of is that enabling windows scaling does add a small overhead to every packet, and one could use RWIN of up to 65535 without scaling to avoid it (at the expence of limiting their throughput to ~1Mbit @ 500ms, ~2Mbit @ ~250ms.)

    Thanks for the excellent point rmucker, I will update the patches with a RWIN of 373760.

    [This message has been edited by Philip (edited 10-20-2000).]

  9. #9


    Mines set at 38600000 and my pages have never loaded faster

  10. #10


    u sure u didnt put 2 extra 0's?

  11. #11
    Kip Patterson


    For Phillip:

    A large RWIN can result in more retransmissions when packets are lost. This is supposed to be less of a problem with the new versions of the protocol which support a more sophisticated handling of lost packets, but it still has some cost. It is especially a problem with modem connections and the old version of the protocol, which is why the defaults were so low in the first place.

  12. #12


    I have adjusted to reflect the new setting 373760

    I also have alway's had a Dialup patch
    that reflects 4288

    On my DSL connection from Earthlink/Mindspring I have tried the lower amounts and had quite a loss in speed about 300kbps I also had someone on cable report to me that when they had lowered the Rwin down to your suggested amount that they noticed a better D/L So go figure

    Like I said I did update to the new amount
    at the web site in the patch's


  13. #13
    Administrator Philip's Avatar
    Join Date
    May 1999
    Jacksonville, Florida, United States
    Blog Entries


    Originally posted by Kip Patterson:
    For Phillip:

    A large RWIN can result in more retransmissions when packets are lost. This is supposed to be less of a problem with the new versions of the protocol which support a more sophisticated handling of lost packets, but it still has some cost. It is especially a problem with modem connections and the old version of the protocol, which is why the defaults were so low in the first place.
    True, however with large RWIN you're still gaining throughput, while with small RWIN values you are limiting it. Higher throughput will cause greater amount of data being lost by default.

    In cases with packet loss, higher RWIN values will cause greater amount of data being lost simply because of the higher throughput. It is a fact that you will have more retransmissions, but the RWIN value is not the cause, it simply improves your throughput, causing more packets to be lost for the same amount of time.

    At least that's the way I look at it.

  14. #14


    Good topic !!!

    Well, I tried them both.....I ran the 50 MEG download from Verizon and with the 372300 value I registered 340.8 KBs. With the 373760 value, I got 376.4 KBs. With my usual (364240), I got 412.2 KBs.

    Believe me, I like 'em all !!!!

  15. #15


    Thanks, Philip. You know I like to help -- as long as no one calls me names!!

    In my simple, layperson’s mind I can explain it the way I understand it. This is excerpted from a post I made earlier today:
    “If RWIN is too high for your "pipeline size" (i.e., "speed"), then you will 'loose' data packets ("packet-loss"). TCP will not allow you to actually loose them, but instead it keeps asking the sender to re-send them until all the packets finally arrive.

    If RWIN is too high, your computer is essentially asking the sender to shove a bunch of data down a pipe that is too small to handle it. You end up having your data spilling-out and getting 'lost'.

    You reach a point where the benefits of asking for a lot of data to be sent (i.e., a large RWIN) are negated by the fact that so much of the data has to be re-sent to be received. When this occurs, your transfer rates with DROP. Therefore, *you can have your RWIN set too high.*

    Unless you have a big pipeline (or a very high latency -- such as a satellite connection), it is unlikely that you can use an RWIN of >65,535 -- and definitely not an RWIN of >300,000!”
    I don’t know if this is worded in a way other people understand (I tried), but it makes sense to me…

    I will obviously defer to your expert opinion. But as I was taught, there is a point where the packet-loss problem does greater damage than the large window. Is this wrong??

    If it is wrong, then YES every one should have a humongous RWIN. Why stop at a measly 373,760? Why not push it to the max? Let’s make RWIN = 2^30 (or 1,073,741,824). I believe someone figured out that wasn’t such I good idea…

    I have read many posts on this site about how the “tweaks don’t work” because people are seeing lower rates AFTER tweaking. I think this might be due to the ‘excessive RWIN’ phenomenon.

    I completely disagree with people that say the tweaks don’t work!! I believe the tweaks do work -- when implemented in a logical fashion. Despite my acerbic postings and notifications about relatively minor problems, I remain a big fan of this site!!

    As for your bandwidth*delay numbers, I agree with them, I just wish I could see downloads of that speed -- 6Mbps!! Sadly in my piece of the universe, I am lucky to get close to 0.6Mbps! I think a lot of us out here are forced to live with these small numbers. And these are the people that I believe cannot benefit from a huge RWIN, and may even be harmed by it.

    Philip, your comments and insight are always appreciated. Take care.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts