Who decided on 372300??

[rmrucker]

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.

[Kip Patterson]

Excellent!

[TRS]

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

[Zporttech]

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

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

[Prey521]

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.

[therealcableguy]

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

[rmrucker]

Geeezz! therealcableguy, I told you to stop reading *before* it got too mathematical! http://www.speedguide.net/ubb/wink.gif

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

[Philip]

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

[HalfLifer]

Mines set at 38600000 and my pages have never loaded faster

[Michfan]

u sure u didnt put 2 extra 0's?

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

[dannjr]

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 (http://microsyspro.com)

THE WORLDS THINNEST BOOK: THINGS I CAN'T BUY By Bill Gates

[Philip]

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.

[spaceman]

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

[rmrucker]

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.

[dannjr]

Just one last thing to add

Thank You

[downhill]

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 http://www.speedguide.net/ubb/biggrin.gif http://www.speedguide.net/ubb/biggrin.gif

[Philip]

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

[Alpha]

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!

[rmrucker]

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?

[rmrucker]

Philip,

Shoot -- I forgot a question that I meant to ask earlier -- but now you brought it up!

RWIN should be an "EVEN multiple" of MSS for better speed and not simply a "multiple" of MSS -- correct????
~~~~
And don't worry, I'm already doing a great job of boring people to death -- any one want some more binary number calculations? http://www.speedguide.net/ubb/smile.gif

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

[Philip]

Well, a RWIN of 2^30 is ~1Gigabyte, there would be no benefit of reserving a 1GB RAM buffer for such a thing...

It's true, RWIN should be an "even multiple" of MSS. You can also look at it as an even number, that's also multiple of MSS. The only case where you'd have to consider it is if you are using odd value for MSS and multiplying it by an odd number to get RWIN. As long as MSS is even, you can make RWIN any multiple of it.

372300 is a valid number as well, since it is an even multiple of MSS.

[rmrucker]

Besides, Microsoft doesn't make up the rules for the Internet anyway -- I beleive it is the Internet Engineering Task Force (the guys who publish the RFC's). Microsoft should NOT be your only source of information, please! http://www.speedguide.net/ubb/smile.gif

I agree 372300 is a valid "even multiple of MSS", but I don't think it meets the RFC 1323 Window Scaling criteria (as above).

I have also been taught the "multiple of MSS" is a 'myth', however, I remain skeptical...

I think people can make a pretty good argument that RWIN should be an "EVEN multiple" of MSS, and not just an "even number, that's also multiple of MSS".

[therealcableguy, et al -- on the outside chance that you are a) still reading this, and b) not already completely bored stiff, stop reading NOW!!] http://www.speedguide.net/ubb/smile.gif

Here is an UN-authorized excerpt from EHS Company's Reading Rooms (www.ehsco.com):

"It's important to note the bits-in-flight value alone is not the optimal window size. You must also consider the maximum segment size (MSS) in use on the connection, and multiply that value by even numbers until you exceed the value derived for the maximum bits-in-flight. This is due to the way in which TCP's Delayed Acknowledgment algorithm refrains from sending acknowledgments until two fully sized TCP segments have been received. If the sender does not transmit enough data in even multiples, the recipient will not return acknowledgments quickly, and the exchange will be jerky.

For example, if the segment size is 1,460 bytes (common for Ethernet and PPP connections), the window must be an even multiple of 1,460 bytes. If the TCP window is an odd multiple of the MSS, eventually the recipient will not receive two full-sized segments, thereby holding off the acknowledgment until the delayed acknowledgment timer expires.

Actually, the default window value should be at least four times the MSS because a smaller receive window would not foster a steady data flow. If the receive window were only twice the MSS, the sender would transmit two segments and then stop to wait for an acknowledgment while the segments worked their way through the network. Once received, the recipient's acknowledgment would also have to return to the sender before more data could be sent, causing further delay. Having a default window size four times the size of the MSS would at least allow the sender to transmit four segments, with the last segment being sent just as the acknowledgment for the first two segments was being returned."

[Philip]

You're right, according to RFC1323 the scale factor should be a power of 2, so it might be implemented by binary shift operations, that's why I agreed 373760 makes much more sense and chenged it in the patches, I'm not sure how I've managed to omit that earlier.

There are a couple of things that bother me in this excerpt you posted: "If the TCP window is an odd multiple of the MSS, eventually the recipient will not receive two full-sized segments, thereby holding off the acknowledgment until the delayed acknowledgment timer expires."

That is not entirely true for the maximum receive window, since the current receive window is a smaller buffer that "slides" within the max receive window and it can't reach such condition IMHO.

[rmrucker]

Master, maybe one day you could even make me a Senior Member? http://www.speedguide.net/ubb/wink.gif

Actually, I suspect you just cringe whenever you see that I made a post... it just translates out to more work!!!

Enjoy your Saturday night.

[TRS]

I ran a packet sniffer the other night to look at exactly what happens during the handshaking.

The behavior described below is for a TCPWindowSize of 65535 or less. I didn't look to see what happens when scaling is turned on.

Packet 1 (me -> www.wpi.edu) (http://www.wpi.edu))
Window = 40656
MSS = 1452

Packet 2 (www.wpi.edu -> me)
Window = 33028
MSS = 1322

Packet 3 (me -> www.wpi.edu) (http://www.wpi.edu))
Window = 40982

The final window size is a multiple (odd in this case) of the lower of the two MSS values. It appears a multiple of the lower MSS is used that will create a window size not less than you initial window size. In this case the 1322 * 31 = 40982. I checked this behavior with a number of other sites and it held true.

Tim

[afaiky]

Navas Cable Modem-DSL Tuning Guide says that for latency between 100 ms and 200 ms (normal latency--normal dsl, "good" cable), you should be using a 32k rwin for maximum performance! for latencies above 200 ms, 64k is good (for poor dsl or cable connections with higher latencies). anything above 64k is really only for cable users with ****TY latency readings and BIG pipes. check tha beCk at http://cable-dsl.home.att.net/

[neo86]

a number that is an even multiple of 1460 and also a 16bit number?

64240

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

[rmrucker]

Thanks TRS!! So "odd" multiples of MSS are "OK". But, does that mean they are as fast as even multiples?? Hmmm... if I had the time I could test it myself... But instead I spend my time answering other posts... Oh well, I know someone will address this issue.

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

[neo86]

LOL, rwin doesn't have to be a even multiple of MSS . This is just another load of BS people madeup. No where on the entire planet does microsoft write that it has to be an even mutiple of mss.

[Philip]

If you follow Navas' ideas (sorry, I couldn't resist), then it is an urban myth.

However, if you actually do your research, you'll find that it's best and it makes a lot of sense to use a multiple of MSS.

BTW, if you search the Microsoft Knowledge Base, there are a number of references where it is clearly stated that RWIN should be a multiple of MSS for best results. Besides, if you read some RFCs all calculate RWIN based on MSS and it is common sense to use a number that will accommodate whole segments. Here is a recent example from Microsoft: "the value should be obtained by rounding up the TCPWindowSize to a multiple of the Ethernet Maximum Segment Size (MSS), which is 1460 for Ethernet" <-- http://support.microsoft.com/support/kb/articles/Q263/0/88.ASP

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

[fbelcher]

This is one of the best discussions I have seen in a long time.

[rmrucker]

Philip, not meaning to antagonize, but instead trying to understand... (btw, I am back from my party and I had a great time! Assume I had too much wine and, ignore all typos!!).

You said:
"Well, a RWIN of 2^30 is ~1Gigabyte, there would be no benefit of reserving a 1GB RAM buffer for such a thing..."

OK, that misses my point. IF you believe that there is no such thing as "too high an RWIN", why in the world would you ever recommend any number less than the maximum? If Windows is going to scale down any large number, then you should give the largest number possible, and let it scale down until it fits you system/connection.

For example, why stop at 372,300 or even 373,760?? If bigger is better, why not 747,520? or twice that big: 1,495,040?
OR, if you take it to the ULTIMATE extreme: 1,073,741,824??? If Windows scales down to whatever fits, then your recommended RWIN is too damn low!! Max it out to 1 billion and let it scale itself down to what ever number your need!

If you cannot specify "too high an RWIN", then you are a sucker for NOT specifying a tremendously huge RWIN!!! What's the point? Make it as big as possible -- it doesn't matter!

However, if on the contrary there such a thing as "too big an RWIN", then it behooves everyone to NOT choose an humongous RWIN.

[dannjr]

http://msdn.microsoft.com/library/psdk/wmisdk/clascomp_5s8e.htm

Excerp:
The SetTcpWindowSize WMI class method is used to set the maximum TCP Receive Window size offered by the system. The receive window specifies the number of bytes a sender can transmit without receiving an acknowledgment. In general, larger receive windows improve performance over high delay and high bandwidth networks. For efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS). This topic uses Visual Basic syntax.

Built on Monday, August 14, 2000

Just something to think about

[rmrucker]

Thanks dannjr. This seems to add support for the "EVEN multiple" of MSS theory...
~~~~~~~
I know this is probably a dumb thing to ask at this point, but I am still intrigued at how the number 372300 came about. It seems to be specific design decision to not continue to double the numbers (186,880 is 2*93440). Was there a reason behind this, or was the decision completely random?

(I know, not real important, but more 'human interest' kinda stuff).

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

[TRS]

I did some more sniffing...

Here are some important points:

1) When the scaling option is disabled, the actual receive window will be a multiple of the lower of the two MSS values sent during SYN and SYN/ACK. The actual receive window will be no less than the size of the desired receive window (the value use specified for the receive window the in the registry).

2) If you are not going to use scaling but want to use the largest receive window size possible you should choose a window size such

WindowSize = [integer [65535 / MTU] - 1] * MTU

Ex. MTU = 1452

WindowSize = [integer [65535 / 1452] - 1] * 1452

WindowSize = [integer [45.1343] - 1] * 1452

WindowSize = [45 - 1] * 1452 = 44 * 1452 = 63888

This is important because if one had chosen 45 * 1452 (65340) the actual receive window would not be able able to be atleast as large as your desired recieve window size unless both MTUs during handshaking were 1452.

3) When scaling is turned off the multiple is not guaranteed to be an even multiple of the lower MTU. You will not have any control over this as every host you hanshake with could have a different size MTU.

4) When scaling is turned on the receive window size present during SYN has absolutely no bearing on the actual window size that will be use. Nor will the MTU values as they do when scaling is turned off.

The actual window size is determined with the window size sent with the ACK packet in combination with the scaling factor sent during the SYN packet. The window size sent during the ACK segment is a righr shift of [scaling factor] bits.

Ex. TCPWindowSize = 7FFFF (524287)

SYN packet - window size advertised = FFFF (65535) (meaningless though), scaling factor = 4

SYN/ACK packet - whatever...

ACK packet - window size advertised = 7FFF (32767)

7FFF is 7FFFF shifted right 4 bits.

So your actual window size will be

32767 * 2^4 = 524272 (7FFF0)

Now Microsoft claims the actual size would be 65535 * 2^4 = 1048560. Internally to windows this may be true. The actual bytes allocated may be 1048560 but the RFC (RFC 1323) makes no statements regarding 65535 as the initial window size value to use when the scaling factor is 1 - 14. The sending host would have no way of know this. The sending how would only know the initial value of 32767 as send in each segment header from the receiver.

So what this all boils down to is that when scaling is used the multiple of MSS issues go out the window. You will always lose the least significant [scaling factor] bits of whatever window size you enter into the registry.

[mindgarden]

Ok. I've been silently reading and trying to learn something here, but I've just have to ask. If my MTU is 1492, my MSS is 1452, should my RWIN be a even multiple of my MSS ex. 1452*46=66792 or should I set my RWIN at 65535? My service is ADSL 1000/128. Thanx.

[rmrucker]

Thanks, Tim (TRS) for this information -- and thanks for jumping in at DSLR. Great stuff! Heads are spinning -- especially mine...

There is still more for me to work out.

If you're still here Philip, I remain skeptical of the importance of the all the numbers -- and that is really why I started this post -- to help ME learn what it all means!

Thank you to all who responded. I am going out to learn some more...
~~~~~~
Tim, one last thing: in the equation, did you mean MTU or MSS?

WindowSize = [integer [65535 / MTU] - 1] * MTU

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

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

[TRS]

MSS... sorry http://www.speedguide.net/ubb/smile.gif

[rmrucker]

Tim-
I've been double checking your numbers, and a lot of what you say makes sense. Could you teach me how to "packet-sniff" this information? I know there are packet-sniffing programs out there, but which are you using?

Philip-
I am continuing to investigate this further. I think Tim is on to something.

Tim-
Walk me through this...
If we now re-look at 372300, in Hex this would be 5AE4C. [I gather the appropriate notation of this is 0x5AE4C.]

The SYN packet advertises the window as the lower 16-bits, or 0xAE4C => 44620, and the scale factor in this case would be 3??

Because 372,300/65,535 = 5.6809... This rounds up to 8 (the next power of 2), or 2^3 (scale factor 3).

Now, would DSLR tweak test show the RWIN as 356960??? (44620 with a scale factor of 3?) (I'll check that out later).

Then the ACK packet would show 372300 right shifted three places, or 0xB5C9 = 46,537.

The true window size would then be 372296 (46,537*2^3).

Did I follow you through any of this, or am I just as lost as I ever was?

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

[Philip]

Here's what I think should be done in theory:

1. Up to 65535 RWIN is a multiple of MSS
2. According to RFC1323 large windows are scaled by multiplying the original RWIN by some power of 2

So, then, assuming MSS of 1460, 44 x MSS = 64240 (highest multiple lower than 2^16) It might be a good idea (although not set in stone) to make it an even mulltiple, so slow start and congestion control algorithms can benefit from it (not sure about that but it wouldn't hurt anyway)
When scaling is turned on, we could use for example 64240 x 2^2 = 256960

This number would be the Max RWIN, while the current open RWIN sniffers report for every packet is going to vary. Any thoughts on my math ?

rmucker, here's a sniffer program you could use: http://www.ufasoft.com/sniffer/

[Bouncer]

This is a very interesting, though fairly theoretical discussion. I'd remind everyone that calculating RWIN or any other packet size based on ping time is generally going to render a faulty measurement. This is because pings to and from any different site NOT DIRECTLY CONNECTED will fluctuate continuously.

As such I don't think you'll find a specific value useable in any real way. It's more efficient to calculate a RWIN value that your service can handle, but which is greater than that of the most common server settings, so that you are more likely to get more full packets before you run into a singular fragmented packet.

To that end, I'd propose we move the discussion more towards the best RWIN for 256kbps,
512kbps,
768kbps,
1024kbps,
1280kbps,
and 1544kbps.

Breaking it up into different RWINs for different speeds seems (to) me to have more promise than trying to break it up by site response time.

Just trying to fog the issue up some more. http://www.speedguide.net/ubb/smile.gif

Best Wishes,
-Bouncer-

------------------
"Yeah Baby, YEAH!!!"

[rmrucker]

Bouncer, I used to live in the Fan on Stuart Avenue near the Strawberry Street Cafe...

I think you are right -- and that is one of the complaints I hear about SpeedGuide from other sites -- that SpeedGuide's "one-size-fits-all" *huge* RWIN patch is not necessarily the best for everyone.

That's when I began tearing into this stuff to figure out how your gurus came up with the numbers. I think I opened a can of worms...

Philip, I believe what Tim (TRS) is saying is that above 65,535 RWIN does not have to be a multiple of MSS. This point is argued elsewhere as well. Tim seems to have proof.

*Thanks for the sniffer tip* -- I'll get to that next... when/if I get time!!

Humorously, I went back to test 372300 at the Tweak Test at DSLR -- and the damn thing was "off line for the moment". I wonder if they are looking a little more closely at how the thing works -- thanks to Tim.

Verrrrryy Interesting...

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

[TRS]

rmrucker:

No problem! I will try not to miss anything.

The software I am using is Analyzer. It is free and can be found at http://netgroup-serv.polito.it/analyzer/ . Go to the download page and download the appropriate packet capture driver for your OS and Analyzer. Intructions for installing the packet capture driver are listed on the page also. Follow the instructions appropriate for your OS.

Assuming you have installed the packet capture driver, installed Analyzer, and rebooted you can proceed to the following.

1) go to http://www.dslreports.com/tweaks

2) click on verbose but do not run the utility

3) run Analyzer (you will have to either setup a shortcut in the start menu or go to the directy where you installed (extracted) Analyzer)

4) when Analyzer comes up go to Capture->Choose lan adapter. Select your ethernet adapter.

5) go to Capture->Begin. A window will pop up... select start

6) go back to the browser window and run the tweak utility

7) when tweak utility completes go back to Analyzer and stop the capture

Now at this point it may get a bit confusing if you aren't familiar with TCP headers. But I will try to explain where to look.

brb... gotta reboot

[TRS]

Well unless the host you are talking to supports the same size MSS you won't be guaranteed an even multiple of the MSS size that is chosen during the handshaking.

As for your case...

An RWIN of 26136 is what you want assuming you use an average max ping time of 200 ms in your calculations.

1000*1024 = 1024000

1024000 * .2 (200 ms) = 204800

204800 / 8 = 25600

25600 / 1452 = 17.6

1452 * 18 (17.6 rounded up) = 26136!

If your average max ping times are higher than ~200 ms then you will need to adjust accordingly but I doubt you will have to.

Your bit rate certainly does not warrant anything past 32K for RWIN.

Tim

[TRS]

Ok back...

BTW... you are following along just fine. It will become clearer once you have the real data in front of you.

I'm writing this on my Win2K machine but will ran the #s you suggest on the Win98 machine (with updated vtcp.386 ofcourse).

1) At this point you stopped the capture and Anaylzer should list all the packets it captured. There should be 3 panes on the Analyzer window. A top pane, bottom left pane, and bottom right pane.

2) In the top pane scroll all the way to the right. Look for the first packet that has a description starting "TCP: Port (1042 -> 8083)". I'm assuming your port #s will be the same.

3) Move to the tree in the bottom left pane. Expand the TCP header branch. Under that branch expand the flags branch. You should see "1 = SYN". The other flags should be 0. If you don't you need to move to the first packet that only has "1 = SYN" and the others set to 0.

4) Now that you have found the SYN packet you will see under the Flags branch a line that says "Window = 44620". You were correct when you thought you would see 44620 in the window field.

5) Now you want to verify the scaling factor. Analyzer at this point in time does not automatically decode the TCP options but it is easy to verify the scaling factor. Under the TCP Header branch in the SYN packet go to the Options branch and expand that. Click right on the word Option to highlight it. This will highlight the data on the bottom right pane.

6) The scaling factor will found in the highlighted data where you see the sequence "03 03 xx". In this case you will see "03 03 03". xx is the scaling factor. In this case it is 03 as you correctly calculated. If the scaling factor were 2 you would see "03 03 02". We have verified the scaling factor.

7) Now we want to see what the real advertised window size is. This will be found in the ACK packet. We just got done looking at the SYN packet. The packet right after that will be the SYN/ACK packet. For this purpose we don't need to look at the SYN/ACK packet. The packet after the SYN/ACK packet is the ACK packet.

8) Go to the ACK packet and again expand the TCP Header branch. To verify this is infact the ACK packet expand the Flags branch. You should only see a 1 next to Acknowledgement. All other flags should be 0.

9) Under the TCP header branch you will again see Window = xxxxx. In this case you will see Window = 46537 as you correctly determined.

There... thats all there is to it. 46537 * 2^3 as you said is the real window size.

What does DSLReports give as the RWIN value? 356960 (44620 (from SYN packet) * 2^3). Of course we know this isn't correct.

Toulnay believes that the value in the SYN packet is a bug. That may be an accurate explanation. But on the otherhand RFC1323 states that the Window sizes in SYN and SYN/ACK are not the values to be scaled. The values in ACK and the data packets are the values to be scaled. In light of this I would say DSLReports should comply with RFC1323 and pull the window size from the ACK packet not the SYN packet as it does now.

So there you go... if you have any questions feel free to ask!

Oh btw... in Analyzer you can view MSS under the TCP Branch.. under the options branch. It will always read 1029. This is a bug. To see what MSS is really being advertised click on MSS and look at the data values that are highlighted. If your MSS should be 1452 you can check that in the SYN packet. You should see 05 AC in the data when you click on MSS.

Tim

[TRS]

Just an FYI...

My DSL connection is 1.5Mbps/256Kbps.

On both my Win98 and Win2K machines I have my RWIN set to 40656 and MTU set to 1492. That's it. On both the EC and WC speed tests I consistantly achieve 1220-1250 Kpbs. This is 81%-84% of my maximum theoretical rate. Not bad. The larger RWINs did not increase the rate at all.

Does RWIN have to be an even multiple of MSS when scaling is off? No. But you may as well enter an RWIN that is an even multiple in the chance you connect to a host that uses the same MSS value. According to MS efficiency is maximized when an even multiple is used.

Tim

[mooseboy84]

I DON'T KNOW RWIN FROM DARWIN, BUT, IF YOU TAKE 2 OUNCES OF MOON DUST, MULTIPLY THE DENSITY OF A CHEESBURGER TIMES WARP SPEED, THEN TAKE THE HYPOTENUSE AND INVERT IT ON THE Y AXIS OF JUPITERS ORBIT, SQUARE ROOTED BY THE LENGTH OF A FLYS' PENIS; ADJACENT TO A HORSES RECTUM WHILE DEFACATING, YOU'LL COME COME TOO THE RATIONAL SCIENTIFICLY PROVE CONCLUSION THAT *$H!T* STINKS!

[rmrucker]

Tim-
A huge THANKS...
I verified EXACTLY what you said Re: the DSLR tweak test and the "reported" RWIN. The tester was down part of last night and it APPEARS to have a minor change in the way it reports the data -- I believe these lines are new:
"* Your RWIN is advertised as 356960 (scaling is on)
(Beyond 65k, advertised RWIN is scaled)"

I am quite sure the word "advertised" is new -- which I THINK now implies that they are reporting the data in the SYN packet -- and are acknowledging that! However, they are still reporting the scaled RWIN *exactly* as you figured -- from this same SYN packet.

For example: back to the RWIN of 372300... DSLR tweak tests shows:
Scaled DefaultRcvWindow (RWIN) is 356960

Where does this number come from? EASY! 372300 => 5AE4C. The "lower 16-bits" (evey hex 'digit' equals 4 bits) are: AE4C => 44620.

The scale factor is determined by:
372300/65535 = 4.99... which must round *up* to the nearest "power of 2" -- or 8. So the "scale factor" is *3* (8 = 2^3).

So DSLR grabs the "advertised" RWIN in the SYN packet (in this case 44620) and multiplies it by "2 to the scale factor" giving you:
44620 * 2^3 = 356960!!!!

But, since this FAILS to take into account the ACK packet -- THIS NUMBER IS A FALSE NUMBER!!!
~~~~
Philip-
I continue to investigate! When I get time, I'll use the sniffers. But what Tim says makes sense. Also, he seems to prove that RWIN does NOT have to be a multiple of MSS even below 65,535, since the negotiated RWIN is based on the lowest MSS of both the host and the server. And you can't know the server's MSS.

RWIN becomes a value that the window size must exceed -- sort of the "floor" value. One question: what happens when window scaling is off and RWIN is at 65,535? This value cannot be exceeded by a multiple of the lowest MSS's... Tim, any ideas?

As for invalid numbers and "trailing 1" bits -- I am not sure this matters anymore... But at least it got me thinking!

I THINK the ACK packet reports the window as the top 16-bits of the set RWIN -- *regardless* of what the trailing bits are...
~~~~~~~~~~~
mooseboy -- thanks for the humor -- it breaks up the monotony!

[upcsucks]

So whats the conslusion of all this? I've experienced majar differences with the value of RWIN. The higher my value the greater the packeloss and ping, but an increase of download speed...
Now my value is 65535 my dowload speeds are not to high ( 1.5Mbit is the max i can , ad average i make about 1 to o.75 Mbit) but i;ve got a low ping in online games and a small packetloss. Just tweak with the values.. If i have a big download i increase the value 4 some extra speed, wen gaming lower it 4 ping. Does this all make sence or hasn;t got it anything to do with ping. Dl, and PL ( the rWin value i mean), and what about the multiplyer, i don't understand it please explain..
thxn
-[DDC]Iferno

[rmrucker]

I hate to admit it, but I don't have final conclusions yet. I can give you an interim summary:

1) The 'tweak test/applet' at DSLR likely has been misleading me regarding the validity of RWIN numbers -- have no fear, I have been posting like crazy to have that sorted out. This should be corrected soon.

2) I am *not* sure the actual numerical value specified for RWIN >65,535 makes ANY difference at ALL -- other than to set the Scale Factor. So any argument about what the exact number is (e.g., a multiple of MSS or not) seems to be *completely irrelevant*!!

3) If the advertised receive window in the ACK is used to determined the final receive window, then the numerial value has SOME, *but NOT a lot of importance*.

To elaborate: if the upper 16-bits of the of the set DefaultRcvWindow is shifted upward by the scale factor to determine the final receive window, then making sure the trailing bits (after bit-16) are "zero" is *only* important in such that the RWIN setting will be "more true". If the trailing bits are not zero, then the final receive window will be *close*, but not exactly to the set DefaultRcvWindow.

AFAIK, this reason -- and perhaps for "internal consistency" -- appears to be the ONLY reason to change RWIN from 372300 to 373760. (There you go, Philip).

4) The argument that RWIN <65K must be a multiple of MSS seems to have been disproven. You can't know the MSS of the server you are connecting to beforehand.

5) Tcp1323Opts works as a String Value -- and it should be easy to tell by packet sniffing if a DWORD works as well.
~~~~~~~~~~
That's all I can tell right now. This large posting has been for discussing the concepts only -- and not meant to come up with the "perfect tweak", If you came here for that reason, you will not find what you are looking for...

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

[Philip]

I moved away from 372300 and 373760... As I said before, here's the way I believe it should be done:



1. Up to 65535 RWIN is a multiple of MSS
2. According to RFC1323 large windows are scaled by multiplying the original RWIN by some power of 2

So, then, assuming MSS of 1460, 44 x MSS = 64240 (highest multiple lower than 65535) It might be a good idea (although not set in stone) to make it an even mulltiple, so slow start and congestion control algorithms can benefit from it (not sure about that but it wouldn't hurt anyway)
When scaling is turned on, we could use for example 64240 x 2^2 = 256960


MSS still has a relevance up to 65535 and most servers will accept 1500 packets without fragmentation.

[rmrucker]

As for RWIN and multiples of MSS:

I believe Tim (trs) demonstrates that the connection chooses the lower of the two MSS values as the actual connection MSS. If your MSS is 1460, yet the server you connect to must use an MSS of 1300, the connection is made with 1300 as the MSS. Then, the receive window is is scaled up as an even multiple of 1300 until it *exceeds* the "floor value" set in your DefautRcvWindow (RWIN).

Since you can't know the server's MSS, settng RWIN to a multiple of your MSS might not be that important. Now, if *every* server had an MSS of 1460, then it might make sense.

Also, if RWIN really is only a "floor value" and not a "hard-coded" value, what does it matter?

Check out this statement from MSKB regarding Win2K (whether this applies completely to Win98 is anyone's guess). This is addressing RWIN <65K:
~~~~
"The receive window size is determined in the following manner:

The first connection request sent to a remote host will advertise a receive window size of 16K (16,384 bytes).

When the connection is established, the receive window size is rounded up to an even increment of the MSS.

The window size is adjusted to 4 times the MSS, to a maximum size of 64K, unless the window scaling option (RFC 1323) is used.
~~~~~
This article later discusses RWIN >65K -- also very interesting. Again, I don't know if this all holds for Win98... I realize the inital window request is differnt for Win98 (i.e., 8192).

Reference: http://support.microsoft.com/support/kb/articles/Q224/8/29.asp

[Biggy]

ok i am testing different RWIN values, so in order for me to do this i should test speed at each value right. Well does anyone know which site to test, i know i should download a big file , telus.net and speed/mybc have download test sites but are only 10meg, is that big enough, i have heard some of you test on 50meg, should i use that one. If any of you know a good way of testing each RWIN value please share. So just to get everything straight here i should test at 372300, 373760 , 65565 right. what are some other values, because as far as the math, it is way above my head, just throw some values out there and i will test them to see which is best. thanks.
P.S and i thought i was finished tweaking, but i guess , you tweak once, then your hooked, tweaker for life.

[SavageHrt]

Good thread. I'll have to sit and read it again when I get home so I can understand it better. I do have a question. How do you figure out how big your "pipeline" is or do you figure it out by trial and error?

Sav

[rmrucker]

SavageHrt-
You shouldn't have brought this back up from the dead!! I am working on a lot more information, but it will have to wait. You will notice that SpeedGuide has slighly given in and lowered their recommended RWIN a little. I still feel it is too high for us average users.

Your pipe size is generally the bandwidth that you paid for -- you download speed. If you got 512 down, you have a small pipe. If you have 2.4 down, then it is large. Larger pipes can benefit from larger RWIN values.

[Rosco]

Lot to learn here.

Rucker,
I am running of topic here, but I was raised in Ginter Park on Hawthorne ave. And I had a friend named Jon Ryan who grew up on Stuart ave, as well.

Nice to know there are alot of Richmonders here.

[Venom]

rmrucker

Hello and sorry to enter this argument almost to late *lol* but I stand next to you on your argument.

1)As far as some of my test proved that a RWIN to large wil result in packet lose.

2)Here is where I beleive that the MSS and probably the MTU as well basicaly wont have much to do with the RWIN as you say, we have the option of usinf PMTUDiscovery and what does that do it changes your MTU to what ever the MTU of the server where you are conected is or by to much packet lose, well usually it has been said that the perfect MSS should be the MTU-40 and i asume that the computer should know this by setting the PMTUDiscovery to on so there for it will always change.

The only way that the RWIN then will work perfectly on the machine would be to turn it off, but then again if you have to much packet lose and you obligate you computer to use those settings it could also mean lower downloads because the computer will be asking for the packets it lost all the time and it will take twice the time to download.

Well I am at work right now so I can't elaborate any more but hey! we are all here to learn and this is the best argument this forum has had and maybe we will come to a good conclution for the benifit of all of us http://www.speedguide.net/ubb/smile.gif



------------------
\/E(\)()(\/)

[rmrucker]

Jeez, guys! Let this old thread die it's death of time!

Rosco- I was in Richmond for 4 years (1982-86). It was a lot of fun. We used to stroll down Stuart Ave. to Buddy's, sit outside on the deck (no matter how cold it was), and stumble on home afterwards. Stonewall Jackson's Happy Hour, Hot Chili at the Texas-Wisconsin Border Cafe. Good memories... OK, back to reality!!

~WarockZIII- I don't like to give exact numbers, because I still believe the best way to find your optimal RWIN is to test it yourself -- no matter what you read here or elsewhere. If we use Tim's equation above:

*Estimated* Full Window Size = MSS * INT[bandwidth*latency*(conversion factors)/MSS].

If we assume your MSS = 1460 and latency is 200 msec (0.2sec), then:

RWIN = 1460 * INT[1500*.2*(1024/8)/1460]
RWIN = 1460 * INT[26.3]

Now Tim says to round this INT[n] up to the next largest number -- but you might want to err on the next largest EVEN number, so...

RWIN = 1460 * 28 = 40,880.

Now, in my mind, that is a starting point only!! First off, latency can only be estimated and this fluctuates during the connection. Also, many non-capped cable users seem to be able to EXCEED their subscribed rates. So, feel free to try as high of an RWIN as you like. BUT, if you are capped, don't be shocked if raising your RWIN too high does not help you, and may even hurt your throughput.

Venom, got to run. More later.

[Mystic]

I've been listening (reading) all this and I have a few questions and maybe a few points i'd like to ask and make.

Questions:

1. My interpetation of all this is that the RWin (or TcpWindowSize for win2000) value you use varies greatly from network to network, am I right to assume this (i.e...Road Runner vs @Home vs all the other cable companies...) ?

2. While one value may work fine for one person with his particular connection, the same value may not work fine with the guy next door. Is this correct ?

3. In theory, the same value or method of calculation, should apply to every cable user on the same cable companies connections. Is this correct?

4. That it is very difficult to test these values over a short time duration. Is this correct?

5. That while standard so and so (RFC's)may say such and such, that these sayings are in theory. is this correct?

6. Referencing question 5 above. If the theory is correct in its application, were these items not intended to be used on true LAN type connections where conditions are more ridigly controlled?

7. If the answer to any of the above is "Yes", then is it not a moot point to subscribe to one magical number in that every ones connection is different?

8. referencing question 7 above. If it is a moot point then the number should be what works for you. Is this not correct?

Points i'd like to make from what i've read here.

A. If the environment, the internet, we connect to is basically out of our control, i.e...servers - time of day - node load - cable quality - computer differences - path, and a whole slew of other things it makes more sense for each person to adapt their connection to the environment they need to deal with.

B. testing - It's obvious that what works at one time for one person, doesn't always hold true for another. I think it would be better if during your testing that the same server is used by all testing. This would establish at least some sort of standard. Why? Well..because John may only have 20 hops to server X and it stays that way for a period of time. So...he knows, to some extent, what conditions he is dealing with in terms of ping time, packet loss, etc...I think I would try to simulate average net conditions as much as possible. For example choose a server thats say...20 hops away from you.

C. If you do use one server for testing then you find some number that gives you the max speed, then thats the max speed, for that server with your connection,,,period...for that server with its known (?) conditions with your connection. Use this as your starting point for further experimentation. When you get this max speed with the one server try serveral different points on the net.You should do extended testing, say at least 4-5 hours a day for 30 days (I did it for three months, several of us did, working together, taking turns staying up late.) keep careful records, and then at the end of your prescribed testing period you can see what number gives you the best average vs the highest speed vs the lowest ping vs the least amount of packet loss vs etc....what ever factors your looking for, and use this number for your daily figure (RWIN for win 9x - TcpWindowSize (or GlobalMaxTcpWindowSize) if your using windows 2000). this will be the number for your daily browsing as it will give you the best over all performance. Gamers? If you want use the same methods to optimize your connections for what ever gaming server you like to use. Oh yeah, test one parameter at a time, test RWIN first, then add the defaultTTL and test it,,so on and so forth.

Well thats all I have to say and ask. It works for me. I took my connections from 300K average download to 700 - 900 k average downloads. I used the above methods and arrived at the figure of---- 256960 - thus verifying the speedguide value.

Something else I discovered along the way, the RFC's and Microsoft and who ever else - they are all right. Read their documentation carefully, more importantly understand it, you will discover insights you did not see before.

Just a practical view. You may now proceed to pick it apart http://www.speedguide.net/ubb/wink.gif

Thank You for listening



[This message has been edited by Mystic (edited 11-06-2000).]

[~WarockZIII]

I have 1 question though, Im running on 1500/128 Cable. So what do you suggest my Rcwin should be?

[rmrucker]

Wow. A lot more here. First I really *despise* you guys making me have to go to the OLD, LONG post -- it takes longer to get to the bottom of page 2!
~~
Venom-
You have hit my present area of interest and investigation -- Path MTU Discovery. I believe this is exactly the behavior TRS describes above. TRS reports that the initial receive window is decided on by a "bidding" process in the 3-way handshake. SYN offers an RWIN and MSS. SYN,ACK offers back another RWIN and MSS. ACK comes back with the final RWIN and MSS -- reportedly with MSS the lesser of the two offered, and the receive window as a multiple of this MSS that exceeds the proposed RWIN in the SYN packet.
~~~~
Here is a quote from MS's White Paper on TCP/IP:
PMTU discovery... When a connection is established, the two hosts involved exchange their TCP maximum segment size (MSS) values. The smaller of the two MSS values is used for the connection.
TCPWindowSize... TCP adjusts to even increments of the MSS (maximum segment size) negotiated during connection setup.
~~~~
Sounds just like what TRS found -- except, he actually found that the window size was NOT always at even increments...

Now, the implications of this is that RWIN does NOT have to be a multiple of MSS at ALL!! MS TCP/IP *seems* to take care of that itself. One problem. I investigated this myself and I could not demonstrate the described PMTU Discovery behavior!!! I had someone else try as well -- but again, what TRS described and what is printed in the MS White Paper did not seem to occur. INTERESTING... I am still looking into this.

That is why I asked you if you packet-sniffed. It is quite enlightening. I have gone into detail on interpreting the Tcp Option string here: http://www.dslreports.com/forum/remark,170000;root=news,61;mode=flat

[Philip - it you want *final* proof about Tcp1323Opts as a Dword vs. String - check out my posting and packet sniff yourself. If it doesn't show "0103030n" (n=scale factor) in the TcpOptions line of the Tcp Header, then you can be *sure* the Dword doesn't work.]

[Oh, and Venom -- that is EXACTLY how you can prove to yourself that SackOpts doesn't belong in the "Parameters" sub-key.]

You can't trun off PMTU Discovery or your MTU will crash down to pre-RFC1191 levels of 576!! Try it yourself and run a Tweak test at dslreports.

Mystic-
I agree with where you are coming from (so insert "Yes" almost anywhere I don't address) except:

1) The RFC's are the LAWS of the Internet -- they are not just theories.
2) Different users on the same service may have different routing, etc. I don't think you can generalize.
3) There cannot be one magical number. I have argued this incessantly.
4) You are HORRIBLY wrong in one spot:
"Microsoft and who ever else - they are all right." I must strongly disagree with this. Why??? I can show you several spots where the MSKB is simply erroneous.

The best example that comes to mind are the comments for "Tcp1323Opts". In one place it says that for Win98 this a DWORD -- wrong!!! In other place, it correctly states this is a String value, but the lines exactly above that state that Tcp1323Opts are **enabled** by default -- wrong again!!!

So, the RFC's are the laws of the Internet, but don't expect Microsoft to be 100% correct.

[Venom]

Hello rmrucker:

sorry to keep posting here I thought about opening a new thread and posting a link of this thread and continue to the new one but some how I thought people would post on both threads and it might be worse *lol*

Well I guess I.m starting to feel a little more right about the MSS and the PMTUDiscovery, and if this keeps up like this it start to make you wonder why the heck go through the trouble of calculating your correct RWIN when the conection that you get has a totaly diferent MSS and MTU and there for RWIN. I asume that micorosoft is gona have to create another option to auto calculate the correct RWIN and everything else depending on the conection that you establish, BUT THEN AGAIN! the RWIN is nothing more then a buffer and if your gona treat the RWIN buffer like a normal Swap file that changes in size I assume before every conection it will pause to change besides the fact that the way it is now you would have to reboot *lol*, I don't see why it's not a simpler buffer where if you have certain amount of RAM you can afford to make the buffer bigger in order to download more information faster. But in that theory it would obligate people to buy more RAM even though that's the way the mayority of things are in the computer worls so I guess it wouldn't matter.

I don't know but i have a feeling that Microsoft is writing thier own "bible" what I mean by that is something that contradicts it's self and I am sorry to use that example for all those who are faithfull to it, please accept my apologies.

But to continue if things contradict themself like that I assume there will never be a way to cominicate properly or should I say with all the benifits and the Max speed.

I hope Microsoft does something soon cuz this is a little to wiered to have to dig in so deep in to the microsoft manuals and knowledge base to just the it confues people *lol*



------------------
\/E(\)()(\/)

[SavageHrt]

rmrucker-

I didn't realize it was so inconvenient to go to page 2. I will have to remember that in the future. Thanks for the heads up.

Note to self-

If thread is 2 pages DO NOT post.

Sav

[rmrucker]

I came back to this post for that?? Ouch! You got me. Love it, Sav. http://www.speedguide.net/ubb/wink.gif Take care.

[Philip]

the conection that you get has a totaly diferent MSS and MTU and there for RWIN.


Actually, most servers/routers/switches are compliant to the Ethernet standard and quite capable of transfering 1500 byte packets.

RWin is a buffer and it's not imperative to make it a multiple of anything, however it's a good idea and there are reasons behind it, such as:

While transfering large files, if the buffer is filled, chances are you'll get more non-fragmented packets.

When packet loss occurs (or at the beginning of each transfer) the implemented algoritms are based on MSS and the current window is opened in multiples of MSS.

Also there will be less calculations required to advertise the current receive window by your end... (although I haven't proven it mathematically http://www.speedguide.net/ubb/wink.gif )

Oh, btw all RFCs and "RWin" related articles base their calculations on MSS...

You mention RWin's relevance to swap files, since it is a buffer. When you assign virtual memory you do it in Megabytes,or you essentially make it a multiple of bytes/kb/MB since they are your base units. When figuring out RWin, it only makes sense to do the same, by using MSS for a base unit instead...

I hope I make some sense, my argument is that although not necessary, it's better to calculate/implement it that way http://www.speedguide.net/ubb/smile.gif

------------------
Life would be much easier if I had the source code...

[This message has been edited by Philip (edited 11-07-2000).]

[Buggyman]

rmrucker,
I do have one question though.
Why is that I can get faster speeds with my scaling turned off?
All my testings has shown that with a low Rwin and scaling turned off I get the most out of my non DOCSIS certified connection.
If scaling is base on adjustments according to handshakes. Then somebody got robbed in my case.
Any Comment?

[dbnukes]

I have DSL 1.5/256 and I had applied the 98 mtu patch, the vtcp.386 update, the fast web page loading patch. My speeds did increase but not that much. I then downloaded the @home speed patch and Wa-bam, my speed shot up greatly. Go figure, with its 373360 Rwin! By the way, I'm running on Windows 98 with a 350Mhz processor and Internet Explorer 5.5. With all the diffrent factors involved, the moon phase, the rising and falling of the tides, the shift of the tectonic plates, etc. it's amazing how diffrent people's connections are affected diffrently. Get my drift? I've tried several diffrent combos and I keep going back to this one time and time again. I don't know why, but this @home patch really beefed my speeds up for me!!! :cool: :cool:

[Buggyman]

dbnukes,
You've got the right Ideal....That's why tweaking is a must and nobody's is the same.
In my case Cablenut had to make mine for me.
My cable is not DOCSIS ready because it's one of the oldest in town and AT&T is having to upgrade the sytem.
If I use a High Rwin I got speed all right but packet Loss was real high.
So Cablenut lowered the Rwin and turned the scaler off.... as a result my overall performance went up.
This is why I ask rmrucker what I did in the above post. Seems to me the scaling plays a VERY important role in overall performance.
Which by the way......
Yooo-hoooo....
Mr. rmrucker..... I'm waiting on my answere! :D

[dannjr]

I couldnt resist besides it took forever to find again..

I wanted to refrence this and found a couple of links broke due to Microsofts updates.. But no matter how you look at this I think its one fine thread that if you have the time should be read.

I know rmrucker is gonna shoot me :rolleyes:

HAPPY HOLIDAYS

[x-guest]

Welp, I was too lazy to read thru every single drip of text on all these posts but I did skim thru all of them to get a basic idea of what you's are talking about....

One question (and forgive it for its possible ignorance).. But doesn't the automatic PMTU discovery play a role in any of this? Isn't there any way that can be disabled without having you surfing at ghey 576MTU speeds?

What about selective ACK, and Timestamping? And finally has anyone ever heard of the scrump-diddly-umptious sounding "TCP Daytona" that I've been trying so hard to fully understand which would theoretically allow one to SUCK up all available bandwidth of a server (regardless of capping) by effectively fooling or in essence CHEATING at the TCP level by "not playing fair" using its 3 specially defined and outlined methods?

thanks..

[dannjr]

(11-07-00 11:54 PM) Last true date of this thread you might want to start a new topic.
AND yes you can disable PMTUD and surf where you want it.

Read Read Read :D Its good for the soul

[x-guest]

Whoops sorry I didn't realize that a thread so old would automatically invalidate any further posts.. LOL! hehehe..

Hell, maybe I will post a new topic. ;)