Jump to content

RWIN Settings from speedguide.net based on MSS


Recommended Posts

Hi all:

I put these in another post but I wanted to put them in their own topic.

Does anyone know why the speedguide.net Tcp/IP analyzer multiplies MSS by 44 to calculate RWIN ?

You have to have scaling enabled for everything but the smallest RWIN value in each list.

These are the suggested RWIN's from the speedguide.net Tcp/IP analyzer

The first one is for PPPoE with 1492=MTU 1452=MSS

511104 (MSS x 44 * scale factor of 8 )

255552 (MSS x 44 * scale factor of 4)

127776 (MSS x 44 * scale factor of 2)

63888 (MSS x 44)

The second one is for other broadband 1500=MTU 1460=MSS

513920 (MSS x 44 * scale factor of 8 )

256960 (MSS x 44 * scale factor of 4)

128480 (MSS x 44 * scale factor of 2)

64240 (MSS x 44)

The third is for PPPoE using XP & without a router. 1480=MTU 1440=MSS

506880 (MSS x 44 * scale factor of 8 )

253440 (MSS x 44 * scale factor of 4

126720 (MSS x 44 * scale factor of 2)

63360 (MSS x 44)

Link to comment
Share on other sites

Hey all; I didn't get any replies to this so I'm double posting it.I think the reason they use 44 X MSS is it comes closest to 65535 on the unscaled RWIN or the lowest one the number is the same.

Anyone have a different or better explanation?

Link to comment
Share on other sites

Just a guess, but could it be a function of the way ethernet works, at the firmware, hardware layer?  Has to be a standard of some sort.  If I remember correctly, setting RWIN and mtu correctly alleviates fragmenting of packets.  Cholla: Please correct me if I'm wrong.  My response is a long shot, but what the hay.... :)

Edit:  Darn:  Spelling AGAIN also replaced mss with RWIN

Link to comment
Share on other sites

cak46; The MSS & MTU set at the correct size transfer without having to be broken down into smaller packets & refragmented.The settings inthe first post are supposed to be correct for that connection.If you multiply 1440,1452 or 1460

by 44 all are less than 65535 which unless I don't rember it correctky is the maximum Windows can receive unscaled.So I thought multiplying by 44 was as close as each one could get without going over 65536.for example 46 X1440=66240.

The multiplier has to be an even number or scaling doesn't work correctly.

Link to comment
Share on other sites

fiddlin around I used an RWIN of  (MSS x 44 * scale factor of 16 ).  Seemed to work ok.  Another question that comes into play for those mathematically inclined is why the scale factor being a multiple of 2 (?) or exponential of 2?  I get huge acks when my rwin is small.......

Link to comment
Share on other sites

I think if your RWIN is too small for the data coming in it temporaily doesn't have anywhere to go.So it returns until it can load.I think thats what causes the acks.

That would explain my problem with not using scaling.  Watched it with ethereal one night.. and got ACKs up the ying yang at 65535

Link to comment
Share on other sites

Ethereal..... It's a packet sniffer.  Prior to starting the test I started ethereal then ran the test then stopped ethereal.  Heres a link to it, but you need another program to go along with it... WinPcap.  This is the link for ethereal:  www.ethereal.com  It can give you some insight on what really occurs with packet transmissions and the information contained therein.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...