SG Broadband Community

The other thread is most interesting. I did NOT test your Analyzer with PathMTUD off -- and I should should have first, sorry.

You may not need the "Note: Under Windows, if MTU Discovery is OFF, packets are limited to 576 bytes" line...

This is important only for the UPloading packets. It has NO effect on DOWNloading. Your Analyzer is measuring the DOWNloading packet / Data Field size (DSLR measures the Uploading). So this may not be an issue for you... I just thought it might be worth mentioning.

YES, I think this issue is limited to MSWindows products -- but I have NOT tried any other OS's -- so I do not know.

I wish there was some way to test the RWIN stuff... I have to wonder if this doesn't involve Big's thread.
_____________________________

I received a suggestion from another user that was pretty sharp -- although I suspect difficult to implement.
It involves a button (or something) at the bottom of your Analyzer results that says "Copy for Posting".

When this button is hit, ONLY the results part is copied -- for example:

TCP options string = 0204059c010303030101080a000000000000000001010402
MTU = 1476
MSS = 1436
Maximum useful data in each packet = 1424
Default Receive Window (RWIN) = 471712
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 58964
MTU Discovery (RFC1191) = true
Time to live left = 240 hops
Timestamps (RFC1323) = true
Selective Acknowledgements (RFC2018) = true
IP type of service field (RFC1349)= 00000000
Priority = 000
Delay = 0
Throughput = 0
Reliability = 0
Cost = 0

That way your threads won't end up with huge posts with results.

Again, just some thoughts. I hope these are helpful.

[ 03-10-2001: Message edited by: rmrucker ]

heres another compare options off and on...
Not on router win2k pro with Enternet 300 thats the max I can get out of the MTU with that program on win2k clean..
Don't mind the Rwin tomarrow it will be 64240 heheheh

TCP options string = 020405a6010303030101080a000000000000000001010402

MTU = 1486
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput.

MSS = 1446
Maximum useful data in each packet = 1434, which is less than MSS because of Timestamps, or other TCP/IP options used.

Default Receive Window (RWIN) = 471712
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 58964
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
508992 (MSS x 44 * scale factor of 8)
254496 (MSS x 44 * scale factor of 4)
127248 (MSS x 44 * scale factor of 2)
63624 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 18868.48 kbps (2358.56 KBytes/s) @ 200ms
Your RcvWindow limits you to: 7547.392 kbps (943.424 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 240 hops
TTL value is ok.
Note: Since TTL is decreased by at least 1 with each hop, the value above is equal to your TTL minus the number of hops to forums.speedguide.net

Timestamps (RFC1323) = ON
Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00xxxx00
Precedence (priority) = 00x (priority)
Delay = x (maybe delayed)
Throughput = x (high throughput)=could be (not)
Reliability = x (Some reliability)
Cost = 0 (normal cost)=free



TCP options string = 020405a60103030301010402

MTU = 1486
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput.

MSS = 1446
Maximum useful data in each packet = 1446, which is equal to MSS.

Default Receive Window (RWIN) = 471712
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 58964
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
508992 (MSS x 44 * scale factor of 8)
254496 (MSS x 44 * scale factor of 4)
127248 (MSS x 44 * scale factor of 2)
63624 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 18868.48 kbps (2358.56 KBytes/s) @ 200ms
Your RcvWindow limits you to: 7547.392 kbps (943.424 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = OFF

Time to live left = 240 hops
TTL value is ok.
Note: Since TTL is decreased by at least 1 with each hop, the value above is equal to your TTL minus the number of hops to forums.speedguide.net

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00xxxx00
Precedence (priority) = 00x (priority)
Delay = x (maybe delayed)
Throughput = x (high throughput)=sometimes(long time ago)
Reliability = x (Some reliability)
Cost = 0 (normal cost)= free

It works good and for ping test well there is always here http://www.pingmeplease.com/ I'm kiddding lighten up in advance..

TCP options string = 020405b4010303030101080a000000000000000001010402

MTU = 1500
MTU is fully optimized for broadband.

MSS = 1460
Maximum useful data in each packet = 1448, which is less than MSS because of Timestamps, or other TCP/IP options used.

Default Receive Window (RWIN) = 371712
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 46464
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/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)

bandwidth * delay product:
Your RcvWindow limits you to: 14868.48 kbps (1858.56 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5947.392 kbps (743.424 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 119 hops
TTL value is ok.
Note: Since TTL is decreased by at least 1 with each hop, the value above is equal to your TTL minus the number of hops to forums.speedguide.net

Timestamps (RFC1323) = ON
Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00000000
Precedence (priority) = 000 (routine)
Delay = 0 (normal delay)
Throughput = 0 (normal throughput)
Reliability = 0 (normal reliability)
Cost = 0 (normal cost)

dialup
I was bored and my connection is down in fact all of the midwest is down for my connection right now so gave dialup a try on the tester... I know the MTU should be allot lower for this but what the heck.. I proxied it too...

Its starting to look like the dannjr hour in these two samples PPPoE one with Timestamps at 1 the other at three
Look how it reads the Rwin in this connection
I havent had this problem till just recently
Have the ISP's gone back to enabling timestamps on there end...

First one with time stamps off
TCP options string = 0204059c01010402

MTU = 1476
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.

MSS = 1436
Maximum useful data in each packet = 1436, which is equal to MSS.
MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

Default Receive Window (RWIN) = 65535
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 65535
Note: Under Windows 9x, if you have RWIN set to any other value, and the Analyzer reports 65535 you might need to install the MS Vtcp386 fix.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
505472 (MSS x 44 * scale factor of 8)
252736 (MSS x 44 * scale factor of 4)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 2621.4 kbps (327.675 KBytes/s) @ 200ms
Your RcvWindow limits you to: 1048.56 kbps (131.07 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 240 hops
TTL value seems to be too large, packets will not be discarded in a reasonable amont of time. Consider decreasing TTL.

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON


Time stamps on

TCP options string = 0204059c010303030101080a000000000000000001010402

MTU = 1476
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.

MSS = 1436
Maximum useful data in each packet = 1424, which is less than MSS because of Timestamps, or other TCP/IP options used.
MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

Default Receive Window (RWIN) = 471712
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 58964
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
505472 (MSS x 44 * scale factor of 8)
252736 (MSS x 44 * scale factor of 4)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 18868.48 kbps (2358.56 KBytes/s) @ 200ms
Your RcvWindow limits you to: 7547.392 kbps (943.424 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 240 hops
TTL value seems to be too large, packets will not be discarded in a reasonable amont of time. Consider decreasing TTL.

Timestamps (RFC1323) = ON
Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.

Selective Acknowledgements (RFC2018) = ON

The reason I mentioned this is there has been a bunch of post rencently on just this above..

Dannjr, in your first post you not only turned off TimeStamps, you also turned off *Scaling*. The TcpOptions string show Scaling is off -- there is no 0103030x field.

Since Scaling is off, your RWIN is limited to 65535 -- as you know.
_________________________________

Philip- I have to disagree with this line:

TTL value seems to be too large, packets will not be discarded in a reasonable amont (sic) of time. Consider decreasing TTL.

Let us first ignore the typo , but conceptionally this makes no sense. First off, define 'reasonable'.

Second, this is completely unimportant. What is the concern?? Is the Internet overflowing with all the packets that aren't expiring fast enough? There are just so many packets clogging the Internet with high TTL fields??

The VAST majority of packets (99.9%?)actually REACH the intended recipient in under 20 hops. In those packets, the TTL value is irrelevant. OK, maybe a few packets get lost -- but NOT dropped. These packets in theory could float around the Internet for what -- a few minutes -- before they self destruct. Is this really worth commenting on?

rmrucker
Thats absolutly right in both statments
My TTL is set high to cure a VPN problem I was having and probably will be fixed later..

Timestamps... this isn't the only place Iv seen this as of late, and we arent telling peole to turn it on weather it be set to 1 or 3.
I have seen at least three on this site alone in the past 2 days..
not just in this particular forum

TCP options string = 020405b00103030301010402

MTU = 1496
MTU is fully optimized for broadband.

MSS = 1456
Maximum useful data in each packet = 1456, which is equal to MSS.

Default Receive Window (RWIN) = 512512
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 64064
RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
256256 (MSS x 44 * scale factor of 4)
128128 (MSS x 44 * scale factor of 2)
64064 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 20500.48 kbps (2562.56 KBytes/s) @ 200ms
Your RcvWindow limits you to: 8200.192 kbps (1025.024 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 50 hops
TTL value is ok.

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00000000

" Let us first ignore the typo , but conceptionally this makes no sense. First off, define 'reasonable'."

OK, typo is fixed. Reasonable, as in how many hops would the furthest possible point on the net be? Over 200 hops ? I'd like to see a traceroute.

"Second, this is completely unimportant. What is the concern?? Is the Internet overflowing with all the packets that aren't expiring fast enough? There are just so many packets clogging the Internet with high TTL fields??"

That's a reasonable assumption, let's say there are 5 (or fewer) broadband websites that every second Cable/DSL Home/SOHO user visits... Let's say 1/3 of all those users set their Registry for broadband... Let's say 1/3 of those users occasionaly experience packet loss... Packets lurking around for over 200 hops are definitely useless, and would only help increase congestion in a global sense...

Now I could be only dreaming, but then again, there might be some amount of truth to what I'm saying. I never said it's imperative to change your TTL value at all, just giving basic guidelines.


" The VAST majority of packets (99.9%?)actually REACH the intended recipient in under 20 hops. In those packets, the TTL value is irrelevant. OK, maybe a few packets get lost -- but NOT dropped. These packets in theory could float around the Internet for what -- a few minutes -- before they self destruct. Is this really worth commenting on? "
What's the point of increasing congestion through an already congested path where usually packet loss creeps in ? 10% packet loss on a broadband connection could mean thousands of packets floating around... with 1000 people on a node each having 1000s of lost packets floating around it could have a major impact...

Again, just a theory.

But think about this:

I've set VERY basic rules... If the TTL left is less than 16 chances are there will be a device on the net you can't reach at all, so I mention it's too small. If the TTL is over 200, the value is ridiculously high and there is a remote chance you will increase congestion on some backbone (considering the larger scale again, 500,000 unique broadband users a month only on this site).

I agree a high TTL wouldn't have an immediate impact on the user, but try to consider the fact that millions use these guidelines... In a global sense it could have some impact, that's all I'm trying to say.

I understand, but I think most "lost" packets are "dropped" packets -- that is GONE for good and not floating around misdirected.

And I am not sure that there are a lot of packets that are lost anyways -- yes there are some -- but whenever I test my connection, I am loosing and/or dropping very few indeed.

The main place I see where a high TTL is desirable is with Satellite connections. I have seen SLOW connections where this makes a big difference.

Just thought I would give you my opinion! Thanks for listening.

[ 03-14-2001: Message edited by: rmrucker ]

HUH???????
The old saying "WHO"S on First" comes to mind here.


[ 03-14-2001: Message edited by: Buggyman ]

^

I've just returned from a sabbatical (actual, some time away from technology), and have spent the evening reading through the changes and pertinant (to me) posts. Thanks for the new analyzer which performs accurately for my box - which is behind a linky router. I like the new layout as well. Keep up the great work everyone, and I'm going to work to get myself back up to speed on the tweaking breakthroughs you've all come up with

I just love this thing