PDA

View Full Version : New TCP Analyzer.



Philip
03-05-01, 05:48 PM
We are testing a new tool that anallyzes your TCP parameters and sends back the information (such as effective RWIN, MTU, etc..), as well as some recommendations.

The TCP Analyzer is currently in Alpha-testing pariod, please check it out and report any bugs/problems/observations to the board, or you can email me directly at philip@speedguide.net .

The tool was designed by a good friend of mine and myself, we're still working on it.

Here's a link, all feedback is appreciated:
http://forums.speedguide.net/optd.shtml

Lobo
03-05-01, 06:03 PM
This is as cool as grits!!!!!!!!!!!!!!! :) :) :) :) :) :) :)

Duzmor
03-05-01, 06:09 PM
Philip: Looks Great - Tells all - Good Job :) :) :)
Duzmor :D :D

Lobo
03-05-01, 06:14 PM
Anyway to get pings in there, it is cool :p

Cyke
03-05-01, 06:20 PM
Neat! :D

Philip
03-05-01, 06:27 PM
Originally posted by Lobo:
Anyway to get pings in there, it is cool :p


That's reserved for another similar tool we're planning on :)

Lobo
03-05-01, 06:40 PM
Like Flint Westwood said, make my day, cool :cool: :cool: :cool: :cool:

cablenut
03-05-01, 06:59 PM
Phillip thanks for making a tweak tester that actually works!! Very good job it is easy for me to diagnose other people's problems and mine also... thanks again.

tekelberry
03-05-01, 07:29 PM
Phillip,
you give a reccomendation about my MSS. You never said anywhere on the registry tweak section about MaxMSS, just MaxMTU. Could you please explain?

HalfLifer
03-05-01, 08:23 PM
It said my RCW is 65535 when its really 373330?

Lobo
03-05-01, 08:31 PM
Hi I would take tweak test at dslr and if it says 65535, you need to download and install Vtcp386 Fix patch from patch page

Philip
03-05-01, 08:56 PM
Originally posted by tekelberry:
Phillip,
you give a reccomendation about my MSS. You never said anywhere on the registry tweak section about MaxMSS, just MaxMTU. Could you please explain?

MSS is calculated automatically by Windows to MaxMTU - 40 ... Microsoft has no reference to setting MSS in the Registry.

You can usually change MSS by changing MaxMTU.

Philip
03-05-01, 08:59 PM
Originally posted by HalfLifer:
It said my RCW is 65535 when its really 373330?

The TCP Analyzer is actually a server that captures SYN - SYN/ACK packets and extracts the header from your TCP packet. The results you see are what's actually advertized as your RWIN.

Dakota
03-05-01, 09:49 PM
Yeah, Baby!! :D This is awesome!!! A definite three thumbs up! ;)

cablenut
03-05-01, 10:26 PM
HalfLifer if you think your ScaledWindow gets used by every server your wrong. If you turn on TCP1323Opts Windows will send a request for the remote server in a ACK packet to use ScaledWindows if the remote server doesn't use ScaledWindows (which majority of them don't, hell majority of them use less then 64240 RWIN's) then your out of luck which then your Window is scaled down to 65K or less apporiatly.

minir
03-05-01, 10:44 PM
Hi Philip

Very Clean in presentation

Fast in deployment

concise in terms of explanation

thorough in evaluation

easy to implement


Nice, very professional

regards minir

Prey521
03-05-01, 11:29 PM
Weird, I set the MTU in my PC to 1496, but yet the TCP Analyzer shows it up as 1500 :confused:, I'm a newbie when it comes to this stuff :D


TCP options string = 020405b0010303030101080a000000000000000001010402

MTU = 1500

MTU is at optimal value

MSS = 1456

Default Receive Window (RWIN) = 373760
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 46720

For optimum performance, consider changing RWIN to 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)
192192 (MSS x 44 * scale factor of 3)
128128 (MSS x 44 * scale factor of 2)
64064 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 29900.8 kbps (3737.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 14950.4 kbps (1868.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5980.16 kbps (747.52 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = 1

Time to live = 51 hops

Timestamps (RFC1323) = 1

Selective Acknowledgements (RFC2018) = 1

IP type of service = 0

BTW, great Analyzer Philip, You Rock :)

Also, going by my Analyzed Stats, do you guys have any recommendations so that I can tweak this badboy. I used the Speedcorp Win2K Tweak and I was just curious thanx :)

[ 03-06-2001: Message edited by: Prey521 ]

Philip
03-05-01, 11:35 PM
Thanks minir :)

Prey, do you use some router or any hardware that might modify your MTU ? MSS is shown at the correct value, it is strange. I'll check the code.

Philip
03-05-01, 11:37 PM
Also, does the IP shown on the results page show your correct IP ? I'm wondering whether it picks up a proxy server or something else along the way.

Prey521
03-05-01, 11:37 PM
Originally posted by Philip:
Thanks minir :)

Prey, do you use some router or any hardware that might modify your MTU ? MSS is shown at the correct value, it is strange. I'll check the code.

Nope, this PC is not on my Router. I have it ICS'd with another PC in my room.

Prey521
03-05-01, 11:39 PM
Originally posted by Philip:
Also, does the IP shown on the results page show your correct IP ? I'm wondering whether it picks up a proxy server or something else along the way.

Nope, IP does not show, also, I ran this test from the Client but the IP also does not show up on the Host PC as well.

Philip
03-05-01, 11:40 PM
You mean you don't see anything on the IP line below the title ?

"TCP properties for IP = xxx.xxx.xxx.xxx"

Prey521
03-05-01, 11:47 PM
Originally posted by Philip:
You mean you don't see anything on the IP line below the title ?

"TCP properties for IP = xxx.xxx.xxx.xxx"

Whoops, Yeah, it shows up, i didnt see that up there LOL. It shows the IP of the cable modem 24.168.xxx.xxx

[ 03-06-2001: Message edited by: Prey521 ]

Prey521
03-06-01, 12:16 AM
OK,


The NIC that is on the Host PC that's connected to the Client has an MTU of 1500. Would changing that NIC's MTU to 1496 correct this?

Prey521
03-06-01, 12:35 AM
K,


I set the NIC on the Host to an MTU of 1496, also on the NIC that is connected to the modem, and it still shows up on the Analyzer test as 1500 on both machines. Is anyone else using ICS gettin there MTU registered correctly using the Analyzer?

[ 03-06-2001: Message edited by: Prey521 ]

Prey521
03-06-01, 01:07 AM
DSLReports Tester shows both machines MTU as 1496, just thought that you might wanna know that :)

dannjr
03-06-01, 01:18 AM
Philip this thing is great in more ways than I could describe.. it would take its own page with how much I like it...
However and I noticed and I'm sure you want to read the ugly side to... I have this blindness problem ever since I'v been working with cablenut :)hehehe Well I have to sdjust the page to 800x600 when you do the test goes off the page you might want to resize the frame just a suggestion...
Now Im on PPPoE I use a router and I also get a reading of 1500 for MTU, but it gets the MSS right.. In fact it nails that number right on all the machines here...
Im gonna play with it some more later....
Thanks again...
Do some sniffs :) If there s a particular way you would like me to do it let me know...

Prey521
03-06-01, 01:21 AM
Originally posted by dannjr:
Now Im on PPPoE I use a router and I also get a reading of 1500

K, good, I'm not the only one then :)

Scoot
03-06-01, 06:12 AM
Phillip,
I too get the 1500 MTU reading.
I have one pc with ZA. Correct IP, it is actually set at 1496 verified through registry and at Dslreports. The MSS shows correctly at 1456.
Sure is fast, good job.

Lobo
03-06-01, 06:26 AM
I'm not picking, info is all, I too set my MAXMTU at 1496, it read 1500, dslr read 1496
Your program read MSS as 1456, which would be right and I would agree with Dannjr, but a great start, keep up de good stuff :p :p :p :p

Philip
03-06-01, 09:55 AM
Well, seems there are still a couple of bugs we need to track down, thanks for the constructive feedback.

Philip
03-06-01, 04:05 PM
The MTU bug should be fixed now, let me know if you're still getting any errors.

cablenut
03-06-01, 04:11 PM
The MTU is fixed it correctly states my router limited MTU/MSS very good.

blebs
03-06-01, 04:16 PM
Just checked mine and now, MTU is incorrect. I have it at 1500 and the test shows it to be at 1512. Double checked it with DSL reports and in the registry. Unless I'm missing something here, it came up incorrect where before everything was right on que.

[ 03-06-2001: Message edited by: blebs99 ]

Easto
03-06-01, 04:19 PM
So what exactly do: "The page cannot be displayed" mean?

Philip
03-06-01, 04:20 PM
blebs99, please post your entire results so I can troubleshoot it. Thanks.

Philip
03-06-01, 04:21 PM
Easto, it means the Analyzer server is down for some reason, it should be back up in a minute or so.

Prey521
03-06-01, 04:21 PM
Hmmmmm, on the WinME Host machine it reports my MTU as 1508 and on my Win2K the page just crashes :confused: :confused:

Prey521
03-06-01, 04:22 PM
These are the results from the WinME host:

TCP options string = 020405b0010303030101080a000000000000000001010402

MTU = 1508

Your MTU value seems to be larger than the Ethernet specs, consider lowering it to 1500 or 1496.
If you're on DSL that uses PPPoE, the maximum allowed packet size is 1492.

Philip
03-06-01, 04:24 PM
Back to the drawing board, argh.

The problem is, MTU is not reported in the TCP/IP headers or options... We are trying to get it from the MSS field and the Header+option size but it seems there is another problem with that.

The server shouldn't crash on Win2k, it was down for a minute.

Prey521
03-06-01, 04:24 PM
K, i got it to run on the Win2k client, but it gave me the same error as specified above, but I know that the MTU's are setup correctly on my PC's.

[ 03-06-2001: Message edited by: Prey521 ]

blebs
03-06-01, 04:37 PM
SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = 24.xxx.xxx.xxx
TCP options string = 020405b4010303020101080a000000000000000001010402

MTU = 1512

Your MTU value seems to be larger than the Ethernet specs, consider lowering it to 1500 or 1496.
If you're on DSL that uses PPPoE, the maximum allowed packet size is 1492.

MSS = 1460

Default Receive Window (RWIN) = 256960
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 64240

RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
256960 (MSS x 44 * scale factor of 4)
192720 (MSS x 44 * scale factor of 3)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 20556.8 kbps (2569.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 10278.4 kbps (1284.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4111.36 kbps (513.92 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = 1

Time to live = 50 hops

Timestamps (RFC1323) = 1

Selective Acknowledgements (RFC2018) = 1

IP type of service = 0


Sorry about taking so long! :)

[ 03-06-2001: Message edited by: blebs99 ]

Prey521
03-06-01, 04:38 PM
Those are the same results that I just got Blebs. We should just wait and see till Philip works out the kinks :)

Philip
03-06-01, 05:04 PM
Working on it, keep in mind it is an Alpha testing, so there are problems to be worked out :) ... We have an idea what
s going on, we'll get it right.

Lobo
03-06-01, 05:13 PM
I'm on WIN ME it shows MTU of 1512 when I know it's 1500, all else is right, this is going to be neat!!!!!!!!! :)

Philip
03-06-01, 05:34 PM
Well, let's test again, Prey, can you post your results once again ?

Anyone else having problems ?
TIA :)

Lobo
03-06-01, 05:42 PM
The information seems correct for mine, the box itself is alittle big, I use 800x600, pick,pick, pick, good job :) :) :) :)

tekelberry
03-06-01, 05:55 PM
Here are my results:
SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = xx.xxx.xxx.xx
TCP options string = 0204059c01010402

MTU = 1476

MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436

Maximum useful data in each packet = 1436, which seems to be 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) = 17232
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 17232

RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
252736 (MSS x 44 * scale factor of 4)
189552 (MSS x 44 * scale factor of 3)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 1378.56 kbps (172.32 KBytes/s) @ 100ms
Your RcvWindow limits you to: 689.28 kbps (86.16 KBytes/s) @ 200ms
Your RcvWindow limits you to: 275.712 kbps (34.464 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = 1

Time to live = 117 hops

Timestamps (RFC1323) = 0

Selective Acknowledgements (RFC2018) = 1

IP type of service = 0


I think the MTU on mine is 1500 but the routers I dunno. Im a linksys and if I recall the linksys has that mtu. So seems great!

Prey521
03-06-01, 06:29 PM
Sweetness, thanx Philip and to your friend whom helped you, You Guys Rock

TCP options string = 020405b0010303030101080a000000000000000001010402

MTU = 1496

MTU is at optimal value

MSS = 1456

Maximum useful data in each packet = 1444, which is less than MSS because of Timestamps, or other TCP options used

Default Receive Window (RWIN) = 373760
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 46720

For optimum performance, consider changing RWIN to 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)
192192 (MSS x 44 * scale factor of 3)
128128 (MSS x 44 * scale factor of 2)
64064 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 29900.8 kbps (3737.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 14950.4 kbps (1868.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5980.16 kbps (747.52 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = 1

Time to live = 51 hops

Timestamps (RFC1323) = 1

Selective Acknowledgements (RFC2018) = 1

IP type of service = 0

cablenut
03-06-01, 07:33 PM
Ah yes thanks tekelberry I know now what linksys uses now..

[ 03-06-2001: Message edited by: cablenut ]

dannjr
03-06-01, 08:55 PM
Mine was done on purpose this way and it read it right Very cool...

TCP options string = 0204059c0103030301010402

MTU = 1476

MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436

Maximum useful data in each packet = 1436, which seems to be 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) = 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:
252736 (MSS x 44 * scale factor of 4)
189552 (MSS x 44 * scale factor of 3)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 29736.96 kbps (3717.12 KBytes/s) @ 100ms
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) = true

Time to live = 247 hops

Timestamps (RFC1323) = false

Selective Acknowledgements (RFC2018) = true

IP type of service =

blebs
03-07-01, 07:26 AM
Here is the new test results! I turned scaling off and everything appears correct. Thanks Philip and fellow engineers!
SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = 24.xxx.xxx.xxx
TCP options string = 020405b40103030201010402

MTU = 1500

MTU is at optimal value

MSS = 1460

Maximum useful data in each packet = 1460, which seems to be equal to MSS.

Default Receive Window (RWIN) = 256960
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 64240

RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
256960 (MSS x 44 * scale factor of 4)
192720 (MSS x 44 * scale factor of 3)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 20556.8 kbps (2569.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 10278.4 kbps (1284.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4111.36 kbps (513.92 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 50 hops

Timestamps (RFC1323) = false

Selective Acknowledgements (RFC2018) = true

IP type of service field = 00000000



;)

dannjr
03-07-01, 05:44 PM
SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = xxx.xxx.xxx.xxx
TCP options string = 0204059c010303030101080a000000000000000001010402

MTU = 1476

MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436

Maximum useful data in each packet = 1424, which is less than MSS because of Timestamps, or other TCP 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) = 274560
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 34320

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: 21964.8 kbps (2745.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 10982.4 kbps (1372.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4392.96 kbps (549.12 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 110 hops

Timestamps (RFC1323) = true

Selective Acknowledgements (RFC2018) = true

IP type of service field = xxxxxxxx


Just a test WinME

dannjr
03-07-01, 07:29 PM
TCP options string = 0204052a01010402

MTU = 1362
MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1322
Maximum useful data in each packet = 1322, which seems to be 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) = 64240
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 64240

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
507648 (MSS x 48 * scale factor of 8)
253824 (MSS x 48 * scale factor of 4)
126912 (MSS x 48 * scale factor of 2)
63456 (MSS x 48)

bandwidth * delay product:
Your RcvWindow limits you to: 2569.6 kbps (321.2 KBytes/s) @ 200ms
Your RcvWindow limits you to: 1027.84 kbps (128.48 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 248 hops

Timestamps (RFC1323) = false

Selective Acknowledgements (RFC2018) = true

IP type of service field = 000xxx00

Precedence (QoS) = xxx
Delay = x
Throughput = x
Reliability = x
Cost = x

NT 4 test

Lobo
03-07-01, 07:35 PM
Think I'll start charging for tis :cool: :cool: :cool:

BMED
03-07-01, 09:50 PM
Question: How do I change my MTU in Win2k?

Mine is reading 1476 and I should set it 1500 for optimal performance.

Prey521
03-07-01, 09:54 PM
The MTU Key in Win2K is in:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Class\{83870D99-673F-4C3B-98D3-2803C09BC71E}

Juggernaut
03-07-01, 10:09 PM
hey prey, I can't seem to find that in my registry...I'm on Win2k too

Easto
03-07-01, 10:15 PM
It worked this time.

Bitchen' :eek:

cablenut
03-07-01, 10:25 PM
I'll explain this without getting technical (hehe)

Windows 2000 has dynamically assigned GUID's that are stored in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\

for ethernet adapters you have to find the right one (usually the one that has your IP, dns, and gateway info in it) then create a DWORD called MTU and set it to your desired valued.

BMED
03-08-01, 01:34 PM
Thanks for the MTU location, mine is already set to 1500.....so why is it reporting 1476?
---------------------------------------------
---------------------------------------------

TCP options string = 0204059c010303030101080a000000000000000001010402

MTU = 1476
MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436
Maximum useful data in each packet = 1424, which is less than MSS because of Timestamps, or other TCP 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) = 373760
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 46720
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: 14950.4 kbps (1868.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5980.16 kbps (747.52 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 21 hops

Timestamps (RFC1323) = true
Keep in mind that timestamps add 12 bytes to the TCP header of each packet, reducing the amount of useful data.

Selective Acknowledgements (RFC2018) = true

IP type of service field (RFC1349)= 00000000

cablenut
03-08-01, 02:30 PM
BMED do you have a linksys or UGate3200 router if so it is limiting your MTU.

BMED
03-08-01, 03:16 PM
Originally posted by cablenut:
BMED do you have a linksys or UGate3200 router if so it is limiting your MTU.

Thanks cablenut, It looks like my linky is the culprit here. I guess there's no way around this unless I disconnect the Linksys. My speeds are very satisfactory right now, if it ain't broke don't fix it....

Thanks again,BMED

rmrucker
03-08-01, 03:41 PM
Philip, I suspect that people are getting MTU's of over 1500 if you are adding the 12 bytes of Timestamping to the total...
~~~~~~~~~~```

Edit: Hmmm... this appears to be fixed now.

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

rmrucker
03-08-01, 03:47 PM
By the way -- excellent job!!! And I like the TOS flag readings as well. NICE!

One thing to note. You might want to clarify the TTL reading. This is the TTL that is in the packet that YOU recieve -- not the TTL of the machine sending the packet. We had multiple questions on that and in the end TTL was scrapped.

GOOD WORK!! I LOVE the correct RWIN. Outstanding!! Bravo!

~~~~~~~~~~~~~~~

Ah, one more question -- do you want the Unscaled Recieve Window to be the window used by routers that are not using TCP1323Opts??

Then, don't you want to change this:

Default Receive Window (RWIN) = 200000
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 50000

Instead, the NON-Tcp1323Opts routers would be using an RWIN of 3,392.

That is: 200,000 mod 65536 = 3,392.

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

Philip
03-08-01, 04:23 PM
rmrucker, we get the unscaled RWIN value directly from the SYN packet I believe, that's where a non-TCP1323 router would get it too, isn't it ?

I mean, in the packet there is an unscaled value (which we report), and then there is the scale option.


~~~~~~~~~~~~~~~~~~

You can try turning off Tcp1323 Options and see whether you can get it to display an incorrect value, I believe we have it set right.

[ 03-08-2001: Message edited by: Philip ]

Philip
03-08-01, 05:13 PM
As far as the TTL value you are somewhat right, we have no way of knowing the exact value of TTL since it is reduced by one each hop (unless we actually traceroute to the client and count hops).

However the value that's reported is the TTL left on the client packet.

rmrucker
03-08-01, 07:51 PM
TTL- correct. My point is that you could put a sentence in there that says: "This is the TTL value as it was read by the Analyzer. It is equal to your TTL minus the number of Hops to SpeedGuide."

OK, that is too wordy, but you get the point! :) The only reason for doing this is to AVOID getting a bunch of posts on this board asking, "Why does the Analyzer give me the WRONG TTL value?" Then you have to spend time explaining how the TTL value works...

I am trying to save you guys from the problems we had!! In the end Justin just took the TTL result out of the test...

I have come up with TWO methods to determine the "set" TTL. Your way (tracert) is the more time and labor intensive!

The other method is to simply send an ICMP Echo Request (ping) to the user. The ICMP Echo Reply that returns will contain a TTL field in its IP header. By default, the ICMP Echo Reply TTL field starts out with a TTL of 255. It would be reduced by the number of Hops it takes to get to SpeedGuide's Analyzer. Therefore, the correct TTL would be:

x = TTL value in TCP/IP packets FROM user
y = TTL value in ICMP Echo Reply FROM user

SetTTL = x + (255 - y)
_______________________________________

Unscaled RWIN -

I would have to say YES and NO to this:

"we get the unscaled RWIN value directly from the SYN packet I believe, that's where a non-TCP1323 router would get it too, isn't it?"

That sentence is correct, however, the Analyzer did not do this. Instead the Analyzer is reporting the ACK packet Window field as the Unscaled value.

For example- on my test I got:

Default Receive Window (RWIN) = 200000
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 50000

Obviously, the top number is equal to the bottom number times 2 to the power of the scaling bits:

50,000 * 2^2 = 200,000.

Therefore, the 50,000 is taken from my ACK packet -- not my SYN packet.

The SYN packet Window field would be equal to my Registry's RWIN mod 65536 -- as I said above.
____________________________________

Regardless, I love your Analyzer!!!! Why didn't you email me on this! I get more email from cablenut! ;)

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

Philip
03-08-01, 08:25 PM
Hmm, you might be right, I'll check. We do get the scaled RWIN from a non-SYN packet.

Anyway, thanks for the feedback, and I would've emailed you, just that the tool is not completely ready yet and I couldn't remember your address :)

Oh, the ICMP way of calculating TTL does sound good too :) We might add that at some point.

Buggyman
03-08-01, 09:09 PM
HUH? :eek:

rmrucker
03-08-01, 09:11 PM
I just saw the new TTL wording -- I think that is even more wordy that mine! ;)

I know -- it is a work in progress. But, honestly, GREAT JOB so far!

I am thrilled that I can be of ANY help!! I'll keep an eye on your progress.

rmrucker
03-08-01, 10:38 PM
One more thing...

The TOS flags. Justin has pulled reporting those -- again because they were a source of a lot of confusion and questions.

I agree that users like cablenut, dannjr, you, and I are interested in seeing these, but Newbies might be confused. I guess the point is that you have to go out of your way to educate the users...

Your present format is this:

IP type of service field (RFC1349)= 01011100
Precedence = 010
Delay = 1
Throughput = 1
Reliability = 1
Cost = 0

There is no explanation or interpretation. It is left as a mystery.

"Precedence" is also a confusing term -- perhaps the term "importance" or something could be included afterwards? Then, the binary numbers are not entirely useful -- although I agree these are the standard...

Then, at least some interpretation could be considered. For example:

Precedence (importance) = 2 (immediate)
Delay = 1 (low delay)
Throughput = 1 (high throughput)
Reliability = 1 (high reliability)
Cost = 0 (normal cost)

Just some thoughts...

But part of me feels like I have just opened Pandora's Box... :)

cablenut
03-08-01, 11:17 PM
rmrucker that box has been open for a long time :) I agree though about the different definitions of the bits...

Philip
03-08-01, 11:23 PM
I was planning to add descriptions, just being lazy :)

All feedback is appreciated.


~~~~~~~~~~~~~~~

K, descriptions added... Would you like them color coded too ? ;)

[ 03-09-2001: Message edited by: Philip ]

Bigpoppapump
03-09-01, 03:01 AM
I just ran the TCP/IP Analyzer and a few things seem to be incorrect.

The IP address under the title isnt mine. Do you think its a proxy server or something?

RWIN is incorrect, it says 49152 when it should read 256960.

MTU reads at 1500.... ok
MSS reads at 1460.... ok

What to do now??? Thx

dannjr
03-09-01, 03:33 AM
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) = true

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

Timestamps (RFC1323) = true
Keep in mind that timestamps add 12 bytes to the TCP header of each packet, reducing the amount of useful data.

Selective Acknowledgements (RFC2018) = true

IP type of service field (RFC1349)= 00xxxx00
Priority = 00x (priority some)
Delay = x (what delay)
Throughput = x (something throughput)
Reliability = x (something reliability)
Cost = 0 (normal cost)I like that price..

Next I think I'll set the Rwin to
0xffffffff Maybe I'll get lucky and it won't BSOD on me...

Philip
03-09-01, 08:57 AM
Originally posted by Bigpoppapump:
I just ran the TCP/IP Analyzer and a few things seem to be incorrect.

The IP address under the title isnt mine. Do you think its a proxy server or something?

RWIN is incorrect, it says 49152 when it should read 256960.

MTU reads at 1500.... ok
MSS reads at 1460.... ok

What to do now??? Thx

The Analyzer reports information for the IP that initiated the request, in your case it could be a proxy server.

Try turning off proxy, if you're running Internet Explorer the setting is in Tools>Internet Options>Connections>LAN settings

rmrucker
03-09-01, 09:33 AM
Not much time...

I see you opted for the word "Priority" -- that is the word I initially typed, then deleted. "Importance" is another viable option -- but "Precedence" is the correct term. Do you want to list both of them (e.g., Precedence/Priority)?

The reason why I backed off from "Priority" was for the ambiguity of the "level 1 Precedence":

Priority = 001 (priority)
_____________________________________

Also, do you think the terms "true" and "false" are more useful than "on" and "off" -- or even "yes" and "no"? Perhaps even ENABLED / NOT ENABLED? Or ACTIVE / INACTIVE?

I just think true and false seem strange -- although correct from a binary point of view!

What does everyone else think??
___________________________________________

Philip- I read through RFC793 and as best I can tell, you are correct about the RWIN. I would LOVE to connect to a WinNT server and test this out (WinNT should not be able to process Tcp1323Opts). Can you give me the address of a WinNT server???? Or any other server that you KNOW is not RFC1323 compatible?

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

rmrucker
03-09-01, 08:11 PM
Philip - I am really reposting to make sure you saw my last editing -- but while I am here... :)

Here is the most recent output:

_______________________

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

Timestamps (RFC1323) = ON
Keep in mind that timestamps add 12 bytes to the TCP header of each packet, reducing the amount of useful data.

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 01011100
Precedence (priority) = 010
Delay = 1 (low delay)
Throughput = 1 (high throughput)
Reliability = 1 (high reliability)
Cost = 0 (normal cost)
________________________________

1) I like the ON/OFF better than true/false -- I guess enabled/inactive did not interest you. ;)

2) I like the TTL statement! You *could* say "is decreased by at least 1..." if you wanted to be 1000% correct.

3) For continuity, the timestamps explanation could be made in *smaller type* (like TTL) and it could be worded similarly:
"Note: timestamps will add 12 bytes to the TCP header of each packet, reducing the space available for useful data."

4) I am not sure there is a "perfect" solution for Precedence. :) This way is fine, but you are now leaving off the description of the value.

5) Another thought is that you could add a line like this for MTU Discovery -- when it is OFF. "Note: if MTU Discovery is OFF, your Uploaded packets will be limited to a size of 576 bytes."

I recognize this is nit-picking!!! But I am just offering up suggestions!!

Cheers. Have a good week end.

Philip
03-10-01, 12:12 AM
Thanks for all the suggestions.

The TOS field not giving the description was a bug in the output parser, fixed.

Added/modified some descriptions as suggested.

Does turning MTU Discovery off limit MTU for all OSes ? I thought it's just a Windows glitch.

About RFC793, I read it the same way too, we still have to test to verify it.

As far as a non-1323 compliant test machine, I don't have one availale, but I'm sure some of our users have NT4 or older boxes... If anyone has one, please try the Analyzer and compare the RWIN/Unscaled Window result with your Registry setting and post some feedback. Or, if you are not sure how to help, just email me or rmrucker.

Thanks.

rmrucker
03-10-01, 11:05 PM
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 ]

dannjr
03-11-01, 03:00 AM
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..

dannjr
03-12-01, 02:36 PM
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...

dannjr
03-13-01, 06:41 PM
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..

rmrucker
03-13-01, 07:03 PM
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?

dannjr
03-13-01, 07:28 PM
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

dvblsd
03-13-01, 08:01 PM
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

Philip
03-13-01, 08:15 PM
" 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).

Philip
03-13-01, 08:25 PM
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.

rmrucker
03-13-01, 11:21 PM
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 ]

Buggyman
03-13-01, 11:31 PM
HUH??????? :confused:
The old saying "WHO"S on First" comes to mind here.
http://thebruces.stormbirds.org/forum/images/smilies/laugh.gif

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

Lobo
03-17-01, 09:50 AM
^ :eek:

JL Sparks
03-18-01, 08:43 PM
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

Lobo
03-23-01, 07:58 AM
I just love this thing