Strange Results and a Question

Micro · Post by **Micro** » Sat Mar 24, 2001 1:07 am

Below is all the data. (Sorry for the length)
WinME, Linksys 1.38.2 firmware
RR across Time Warner
Netstat shows 248KB downloading from HappyPuppy at 2pm in the afternoon.
(Haven't run a late night test yet)

NOW, before anyone gets excited

I know this is not recommended, I'm just looking for a reason to the results I'm seeing.
*********************************************
Your Tweakable Settings:
Receive Window (RWIN): 65781760
Window Scaling: 10
Path MTU Discovery: ON
RFC1323 Window Scaling: ON
RFC1323 Time Stamping: OFF
Selective Acks: ON
MSS requested: 1460
TTL: 61
(less any hops behind firewall)
TTL remaining: 44

Example 146000 byte download
Actual data bytes sent: 146000
Actual data packets: 100
Max size packet sent: 1500
Max size packet recd: 1500
Retransmitted data packets: 0
sacks you sent: 0
pushed data pkts: 1
data transmit time: 1.176 secs
our max idletime: 82.7 ms
transfer rate: 93845 bytes/sec
transfer rate: 750 kbits/sec
transfer efficiency: 100%

ICMP (ping) check
Minimum ping: 45 ms
Maximum ping: 50 ms
Ping stability:
49 48 47 50 47 48 45 47 48 47

total packets: 57 total packets: 104
ack pkts sent: 56 ack pkts sent: 104
pure acks sent: 52 pure acks sent: 3
unique bytes sent: 4380 unique bytes sent: 146000
actual data pkts: 3 actual data pkts: 100
actual data bytes: 4380 actual data bytes: 146000
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 3 pushed data pkts: 1
SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1
req 1323 ws/ts: Y/N req 1323 ws/ts: Y/N
adv wind scale: 10 adv wind scale: 0
req sack: Y req sack: Y
sacks sent: 0 sacks sent: 0
mss requested: 1460 bytes mss requested: 1460 bytes
max segm size: 1460 bytes max segm size: 1460 bytes
min segm size: 1460 bytes min segm size: 1460 bytes
avg segm size: 1459 bytes avg segm size: 1459 bytes
max win adv: 65781760 bytes max win adv: 14600 bytes
min win adv: 49152 bytes min win adv: 5840 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 65782473 bytes avg win adv: 14431 bytes
initial window: 1460 bytes initial window: 2920 bytes
initial window: 1 pkts initial window: 2 pkts
ttl stream length: 4380 bytes ttl stream length: 146000 bytes
missed data: 0 bytes missed data: 0 bytes
truncated data: 4242 bytes truncated data: 141400 bytes
truncated packets: 3 pkts truncated packets: 100 pkts
data xmit time: 0.063 secs data xmit time: 1.176 secs
idletime max: 161.4 ms idletime max: 82.7 ms
throughput: 2815 Bps throughput: 93845 Bps
RTT samples: 4 RTT samples: 51
RTT min: 0.0 ms RTT min: 54.4 ms
RTT max: 0.1 ms RTT max: 75.0 ms
RTT avg: 0.1 ms RTT avg: 60.3 ms
RTT stdev: 0.0 ms RTT stdev: 4.0 ms
post-loss acks: 0 post-loss acks: 0
segs cum acked: 0 segs cum acked: 50
duplicate acks: 100 duplicate acks: 5
triple dupacks: 0 triple dupacks: 0
max # retrans: 0 max # retrans: 0
min retr time: 0.0 ms min retr time: 0.0 ms
max retr time: 0.0 ms max retr time: 0.0 ms
avg retr time: 0.0 ms avg retr time: 0.0 ms
sdv retr time: 0.0 ms sdv retr time: 0.0 ms

TCP options string = 020405b40103030a01010402

MTU = 1500
MTU is fully optimized for broadband.

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

Default Receive Window (RWIN) = 65781760
RWIN Scaling (RFC1323) = 10 bits
Unscaled Receive Window = 64240
RWIN is 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: 2631270.4 kbps (328908.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 1052508.16 kbps (131563.52 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

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

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00000000

donald_k · Post by **donald_k** » Sat Mar 24, 2001 1:21 am

Can you post your average speed on here. My average myself is 500KB/s down and 135KB/s up.

cablenut · Post by **cablenut** » Sat Mar 24, 2001 1:21 am

Oh thanks I needed a laugh

hahaha

Micro · Post by **Micro** » Sat Mar 24, 2001 2:51 am

Originally posted by cablenut:
Oh thanks I needed a laugh hahaha

Glad you enjoyed it

But I was serious as to why I'm seeing those results at those settings.
Especially with sackopts set as 3
The 248KB is apparently to my cap.
It's my understanding that the TCP/IP stack in WinME has a Max DefaultReceiveWindow of 1gig and that setting I used is the highest octal (1460 x 44 x 128 x 8)
I can acheive the same download speeds from HappyPuppy at a DefaultReceiveWindow of 64240 without scaling turned on, but at these settings, web pages load notably faster than at that or any other setting.
Just trying to understand why I'm seeing those results, since they are obviously flawed and looking for a reason web pages load fastest for me at that setting.

Originally posted by donald_k:
Can you post your average speed on here. My average myself is 500KB/s down and 135KB/s up.

At that high a DefaultReceiveWindow setting there appears to be a problem with test site's results. They vary from 2400Kb/s up and 380Kb/s down to 358Kb/s up and 368Kb/s.
At a "normal" DRW they display normally, very close to my cap, 2000Kb/s up and 380Kb/s down, depending on the test server.

Lobo · Post by **Lobo** » Sat Mar 24, 2001 9:23 am

Well I have never seen a number like that, any packet loss at night, but if it works for you, keep it, I tried it on mine, man what a mess, so I went back to old faithfull, ask Cablenut as he is de Geru round here or Dannjr

Micro · Post by **Micro** » Sat Mar 24, 2001 10:11 am

Originally posted by Lobo:
Well I have never seen a number like that, any packet loss at night, but if it works for you, keep it, I tried it on mine, man what a mess, so I went back to old faithfull, ask Cablenut as he is de Geru round here or Dannjr

Cablenut seemed to think I was kidding

It only works with TcpOpts set to 1, if timestamps are turned on it won't even load a page or download a file.

These are my settings currently-

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPer1_0Server"=dword:00000050
"MaxConnectionsPerServer"=dword:00000028

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"BSDUrgent"=dword:00000001"
"DefaultRcvWindow"="65781760"
"DefaultTTL"="64"
"PMTUBlackHoleDetect"=dword:00000000
"PMTUDiscovery"=dword:00000001
"SackOpts"="3"
"Tcp1323Opts"="1"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters]
"MaxDupAcks"=dword:00000003

with all NetTrans set as follows (In my case 13 of them)

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0012]
"MaxMTU"="1500"
"MaxMSS"="1460"

Funny thing is that time of day doesn't seem to make any difference, results are the same from the same servers as far as download speeds go. Some are always faster than others, but time of day (traffic) doesn't seem to matter.
It does work here and has for some time, I'm just trying to figure out if it is unique to the cable system I'm on, a fluke, or if it works for others.
And why I see those results.
I understand that the Tcp/Ip page here at SpeedGuide is calculating theoretical speeds and not actual, and that explains it's results.
The DslReport's page actually transfers a small (100k) file and that skews it's results.
But at HappyPuppy I download a 100meg+ file and the average speed is consistent throughout the download according to Netstat, with just a relatively gentle sine wave in real time on the chart and time of day doesn't matter. It's always in the 246-248KB/s , which is consistent with my cap.

Just trying to figure out why?

Lobo · Post by **Lobo** » Sat Mar 24, 2001 10:17 am

I don't have answer for you, I just have never seem a RWIN like that, I d/l at 600-650KBs and not nearly as hign a RWIN as you,
but if it works for you, go with it, but it does seem funny

Storm90 · Post by **Storm90** » Sun Mar 25, 2001 12:54 am

Lobo right! I have never seen a wrin setting like that either. I am surprised it works. Must just be luck! GoodLuck!

rmrucker · Post by **rmrucker** » Sun Mar 25, 2001 4:26 pm

I have had my RWIN at 1,073,725,440 for awhile -- just playing around. It does not do anything exceptionaly BAD or GOOD for me -- I just did it to test it out.

That number is the largest ACTUAL RWIN you can get. The largest number you can enter in your DefaultRcvWindow is 1,073,741,823 -- however, if you enter that number you will still measure an RWIN of 1,073,725,440.

My biggest question is:

What in the world is a SackOpt of 3??

Also, I have no idea what this means:
"why I'm seeing those results, since they are obviously flawed"

Am I missing the obvious flaw??

Micro · Post by **Micro** » Mon Mar 26, 2001 11:50 pm

Originally posted by rmrucker:
I have had my RWIN at 1,073,725,440 for awhile -- just playing around. It does not do anything exceptionaly BAD or GOOD for me -- I just did it to test it out.

That number is the largest ACTUAL RWIN you can get. The largest number you can enter in your DefaultRcvWindow is 1,073,741,823 -- however, if you enter that number you will still measure an RWIN of 1,073,725,440.

My biggest question is:

What in the world is a SackOpt of 3??

Also, I have no idea what this means:
"why I'm seeing those results, since they are obviously flawed"

Am I missing the obvious flaw??

To the best of my knowledge SackOpt has only two valid values, 0 or 1. The value of 3 was installed by an early "tweak" file from DSLreports and obviously was wrong. But out of curiosity, I tried it again with these really high settings and it produced better results than a 0 or 1 setting, which makes no sense since, as an invalid value, it should be interpreted as a "0" setting.

The "obvious" flaw is that the Speedguide TcpIp checker appears to use a "calculated" value for "potential" throughput, rather than a real value based on actual file transfer checking.
CPU speed, FSB and other factors can really skew this as to what is acheivable.
DSLreport's checker uses a file transfer to "calculate" a real throughput rate, but the file is way too small to acheive an accurate "real" rate as it doesn't give the server and connection time "to settle".

Both are excellent "quickie" tests and fine for "getting in the ballpark", but not really accurate of what is "real" or good for fine tuning.
Don't get me wrong, I certainly couldn't write anything half as good, but I think the best way to test is a the way Lobo suggests.
It takes longer but is much more accurate.
And I certainly don't mean to offend the author's of either tester as they are both invaluable aids in optimizing a connection, I just don't feel they don't give accurate rates, but do give accurate "relative" rates.
(Hope that makes sense)