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 ?
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,
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.
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.
[This message has been edited by rmrucker (edited 10-24-2000).]
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.
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.
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.
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!
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!!!
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!
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..
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).]
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.
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).
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.
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?
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.
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
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:
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.
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.
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
Thank You for listening
[This message has been edited by Mystic (edited 11-06-2000).]