# Thread: Who decided on 372300??

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

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 &gt;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 &gt;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. Excellent!

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.

Tim

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

------------------
Steve
www.zport.com

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

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

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. 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. Mines set at 38600000 and my pages have never loaded faster

10. u sure u didnt put 2 extra 0's?

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

------------------
dannjr@microsyspro.com
Microsystems
THE WORLDS THINNEST BOOK: THINGS I CAN'T BUY By Bill Gates

13. 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. 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. 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 &gt;65,535 -- and definitely not an RWIN of &gt;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.

16. Just one last thing to add

Thank You

17. Oh man.....

I've been playing with multiples of 16 for this, and trying different combinations, on and off since I got cable.

Thanks for the heads up,rmrucker. And quite informative posts for sure.

This number for Rwin works faster on my system anyway.

Once again, thanks.D

18. Originally posted by rmrucker:
“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'.
Looking on a larger scale, Windows does have "Congestion Avoidance" and "Slow Start" algorithms that deal with the number of segments being sent before acknowledgement is received to avoid router congestion and packet loss.

However, looking at the RcvWindow in general, the sever negotiates with the client at the beginning of a transfer the amount of data it can send before receiving acknowledgement, basically negotiating the advertised RcvWindow with the client. Then, the server starts opening the SendWindow, initially 2xMSS, once ACK is received increases it to 4xMSS and so on exponentially. All that simply illustrates that the send window and the rate at which you receive data is controlled by the advertised receive window.

If a packet is lost, generally the assumption is that it results from a congested router, and the (questionable)remedy is lowering the transfer rate by cutting the advertised RWIN in half (at least that's how Windows 2000 handles it), then slowly opening up the send window again.

RWIN by itself is just the advertised buffer your PC can receive before transfer stops, while the server is waiting for acknowledgement. The only disadvantage of every client on a large scale network having a large RWIN value would be that routers can possibly get more congested, simply because higher bursts of data can be sent at any given time, overloading the router and causing higher packet loss.

From the client's viewpoint, you are still better of with a large RWIN value since your theoretical throughput can be higher. Packet loss is something caused by network congestion and other factors, not directly related to RWIN.

On the other hand, if we are considering large scale network implementation, lower RWIN values in all client PCs might lower packet loss by reducing congestion in the routers and somewhat the throughput of the clients. (I'm just speculating here)

I hope I didn't bore anyone to death.

"Of course all that's just my opinion, I could be wrong"

I'm by no means "the expert" and it is an interesting subject.

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

19. Holy Smokes!! I just d/l'ed a 15mb test file from AT&T broadband {formerly mediaone/RR} in 28 seconds, thats a new record for me. That's using the updated Sguide Win98 patch and dannjr's 1500 patch from his website along with the vtcp fix. Heh, you guys rule, all else drool! Thanks for the great stuff!

20. Thanks Philip. I think I understand (OK, some of it) -- but one last question I would like you to tackle:

Why not an RWIN of 2^30 if we have nothing to lose???

I think I am already seeing posts complaining about the "new" tweak settings... I fear this is due to the "too big ta eat" RWIN. Is this possible?

#### Posting Permissions

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