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/
Who decided on 372300??
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.
Best Wishes,
-Bouncer-
------------------
"Yeah Baby, YEAH!!!"
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.
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).]
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
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
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
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
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!
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
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).]
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:
MSS still has a relevance up to 65535 and most servers will accept 1500 packets without fragmentation.
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
-
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
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.
P.S and i thought i was finished tweaking, but i guess , you tweak once, then your hooked, tweaker for life.
-
SavageHrt
-
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.
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
-
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
------------------
\/E(\)()(\/)
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
------------------
\/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.
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
Thank You for listening
[This message has been edited by Mystic (edited 11-06-2000).]
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
Thank You for listening
[This message has been edited by Mystic (edited 11-06-2000).]
-
~WarockZIII
-
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-
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(\)()(\/)
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
Actually, most servers/routers/switches are compliant to the Ethernet standard and quite capable of transfering 1500 byte packets.the conection that you get has a totaly diferent MSS and MTU and there for RWIN.
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
)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
------------------
Life would be much easier if I had the source code...
[This message has been edited by Philip (edited 11-07-2000).]
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?
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?
No Question is a dumb Question when it comes to Tweaking!
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!!! 
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!
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!
No Question is a dumb Question when it comes to Tweaking!
-
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..
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..
-
x-guest
whooopps .. mah bad.
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.
Hell, maybe I will post a new topic.