Question about Windows registry settings

[Jodokast96]

Without getting really technical, what is the difference between the DefaultRecieveWindow and TcpWindowSize?  What does each one do on it's own, and how if at all do they relate to each other?

[VanBuren]

Without getting really technical, what is the difference between the DefaultRecieveWindow and TcpWindowSize?  What does each one do on it's own, and how if at all do they relate to each other?

DefaultRecieveWindow DefaultSendWindow is AFD parameters thats act like a RWIN / SWIN on windows XP SP2

read this thread http://www.broadbandnuts.com/index.php?board=4;action=display;threadid=3126

quote from http://www.broadbandnuts.com/index.php?page=9

1. DefaultReceiveWindow - The number of receive bytes that AFD buffers on a connection before imposing flow control. For some applications, a larger value here gives slightly better performance at the expense of increased resource utilization.

Value Type: REG_DWORD

Default: 4096/8192/8192

2. DefaultSendWindow - This is similar to DefaultReceiveWindow, but for the send side of connections.

Value Type: REG_DWORD

Default: 4096/8192/8192

32. TcpWindowSize - This parameter determines the maximum TCP receive window size offered by the system. The receive window specifies the number of bytes a sender may transmit without receiving an acknowledgment. In general, larger receive windows will improve performance over high (delay * bandwidth ) networks. For highest efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS).

Value Type: REG_DWORD

[Jodokast96]

Thanks, I guess it's all just a little beyond me at this point.  So far, it seems to me that they do the same thing, as in a particular value set for one, will have the same exact effect when that value is set in the other.  For example:

If I set TcpWindowSize to 13068 (don't know why I need it so low) and leave DefaultReceiveWindow blank, I get decent speeds to local sites, poor speeds to distant ones.

If I set TcpWindowSize to 63888 and leave DefaultReceiveWindow blank, my speeds drop to local sites, but rise for distant ones.

If I set TcpWindowSize to 13068 and set DefaultReceiveWindow to 63888, I get the same results as setting TcpWindowSize to 63888 and leaving DefaultReceiveWindow blank.

I haven't yet tried TcpWindowSize set to 63888 and DefaultReceiveWindow set to 13068.

Is that the way it should work?  Not being able to, all of a sudden, use any of your tweaks has me trying to learn what all this stuff actually does so I can come up with my own.

[trogers]

DefaultReceiveWindow (or RWIN) setting affects the throughput limit of your comp and should be adjusted to suit your bandwidth and latency - not about distant or local sites.

You may get the impression that there is some relationship. The real relationship is that your latency to local sites usually is less than 100 ms and latency to international sites  can be 300 ms. You can see this by doing a tracert test.

So a small (RWIN) will not affect speed to local sites but will slow download time for distance sites.

As a rule of thumb, DefaultReceiveWindow(RWIN) = bandwidth x latency

TcpWindowSize affects efficiency of your signal transmission. Too large will cause excessive packet losses and many retransmissions.

You can experiment changing the values of these values and carry out a network diagnostic test to see results on throughput, speeds, packet losses at this site:

http://nitro.ucsc.edu/

[peepnklown]

If you are using CableNut this should help, but it also can help you calculate the settings you are looking for.

CableNut Generator

[Jodokast96]

I think I understand what you guys are saying...however none of it seems to apply to me.  At this point, I believe I've found the settings that work best for me, and will stick with them, but they seem so totally opposite of what they should be, and I'm really just trying to learn why.  I'm just so bugged by the fact that what you are saying used to apply exactly, and now it doesn't. 

Trogers, take a look again at my settings and the affects they have.  If what you say about a high Rwin not affecting speed to local sites really applied to me, when I set a high Rwin with a low TcpWindow size, it shouldn't behave that way, right?  Which is also the same effect (maybe for different reasons, I don't know) as having a high TcpWindow size.  As far as latency, for near sites, I'm talking less than 30ms, and far as about 100ms.  I haven't messed with anything over 100ms as of yet.  Is it making sense to you?  I know I don't understand how all of this comes together, but something just seems abnormal.  The other part about all of this, and I understand that they can't be totally relied on, is that I can practically guarantee great results (or lousy ones) from any speed test site, just by adjusting these values.  I understand thats what they are there for, but what I mean is, should I be able to set myself up to get good results from one area (or latency range, however you want to look at it) while screwing all the others?  Why am I able to get good results from an area farther away (higher latency) than from closer to me (lower latency), and then flip things around and get the opposite?  Is this how all of this is supposed to work?

Sorry for being such a pain in the ***.  Just trying to find the why, if it even exists.  BTW I'm attaching my CableNut settings just in case your curious and want to check them out.  I know they would kill anyone elses connection, but it's what is needed on all 3 of my pc's (2 win2k, 1 98SE)

[trogers]

I cannot really give comments on the settings of your ccs file until I have performance test results and your advertised speeds.

What are your advertised speed and are you using cable or DSL?

Speed test reults in www.testmy.net

Post test results of

https://www.speedguide.net/analyzer.php

http://nitro.ucsc.edu/

Post the results for Statistcs and the last two paragraphs of More Details.

Examples:

WEB100 Enabled Statistics:

Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done

running 10s outbound test (client to server) . . . . . 455.87kB/s

running 10s inbound test (server to client) . . . . . . 750.79kB/s

  ------  Client System Details  ------

OS data: Name = Windows XP, Architecture = x86, Version = 5.1

Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_06

  ------  Web100 Detailed Analysis  ------

Cable modem/DSL/T1 link found.

Link set to Full Duplex mode

No network congestion discovered.

Good network cable(s) found

Normal duplex operation found.

Web100 reports the Round trip time = 243.9 msec; the Packet size = 1444 Bytes; and

There were 31 packets retransmitted, 69 duplicate acks received, and 74 SACK blocks received

The connection stalled 1 times due to packet loss

The connection was idle 0.47 seconds (4.7%) of the time

This connection is receiver limited 11.19% of the time.

This connection is network limited 88.78% of the time.

Web100 reports TCP negotiated the optional Performance Settings to:

RFC 2018 Selective Acknowledgment: ON

RFC 896 Nagle Algorithm: ON

RFC 3168 Explicit Congestion Notification: OFF

RFC 1323 Time Stamping: OFF

RFC 1323 Window Scaling: OFF

Information: Network Middlebox is modifying MSS variable

Server IP addresses are preserved End-to-End

Client IP addresses are preserved End-to-End

estimate = 0.68 based on packet size = 11Kbits, RTT = 243.9msec, and loss = 0.004418262

The theoretical network limit is 0.68 Mbps

The NDT server has a 101.0 KByte buffer which limits the throughput to 3.23 Mbps

Your PC/Workstation has a 62.0 KByte buffer which limits the throughput to 1.99 Mbps

The network based flow control limits the throughput to 2.03 Mbps

Client Data reports link is 'T1', Client Acks report link is 'T1'

Server Data reports link is '10 Gig', Server Acks report link is 'Ethernet'

[trogers]

Take note that the Cablenut adjuster for 98SE is different for WIN 2K and XP. I am not familiar with settings for 98SE.

For assistance in cablenut settings for 98SE, go to this link

http://www.j79zlr.com/cablenutME98.php

[Jodokast96]

First, I'm only working with one of the Win2k machines.  The 98SE box is for the g/f, so anything over dial-up is fine.  The other Win2k is pretty much just a file server.  Just mentioned them because they are showing the same results.  As to the css file:  I wasn't really looking for ways to improve it (even though that would be great, I think its as improved as it's going to get);  it was just to give you a reference as to what is working best for me, and how it is not "the norm".  I'm on Verizon DSL, 3/768.

As for posting results to a speed test, this is what I'm talking about.  BTW, I'm in NJ.  I can give you one right now from Speakeasy NY, which are usually considered pretty good, and it will say about 2800.  The Testmy.net (TX, I believe) will probably give me about 1900, about the same as Speakeasy Dal.  And a couple of different ftp downloads will run at about 2600.  But if you want, I can get almost 2800 from Testmy.net (or Speakeasy Dal) by upping my TcpWindowSize or DefaultReceiverWindow, but it will definitely cripple the Speakeasy Ny results, and I believe, but not 100% positive, the ftp downloads.  The same will apply to speeds for different mirrors of that nitro.ucsc.edu test.  I can get any result you want, up to my top speed of about 2800, for any speed test you give me.  I just need to know where it's at so I can set the values accordingly.  Crazy, huh?

Here are the stats for the link you provided:

WEB100 Enabled Statistics:

Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done

running 10s outbound test (client to server) . . . . . 773.32Kb/s

running 10s inbound test (server to client) . . . . . . 1.04Mb/s

------  Client System Details  ------

OS data: Name = Windows 2000, Architecture = x86, Version = 5.0

Java data: Vendor = Sun Microsystems Inc., Version = 1.4.2_06

------  Web100 Detailed Analysis  ------

Cable modem/DSL/T1 link found.

Link set to Full Duplex mode

No network congestion discovered.

Good network cable(s) found

Normal duplex operation found.

Web100 reports the Round trip time = 100.33 msec; the Packet size = 1452 Bytes; and

No packet loss was observed.

This connection is receiver limited 97.00% of the time.

  Increasing the the client's receive buffer (12.0 KB) will improve performance

This connection is network limited 2.97% of the time.

Web100 reports TCP negotiated the optional Performance Settings to:

RFC 2018 Selective Acknowledgment: ON

RFC 896 Nagle Algorithm: ON

RFC 3168 Explicit Congestion Notification: OFF

RFC 1323 Time Stamping: OFF

RFC 1323 Window Scaling: OFF

Information: Network Middlebox is modifying MSS variable

Server IP addresses are preserved End-to-End

estimate = 110.41 based on packet size = 11Kbits, RTT = 100.33msec, and loss = 1.0E-6

The theoretical network limit is 110.41 Mbps

The NDT server has a 101.0 KByte buffer which limits the throughput to 7.86 Mbps

Your PC/Workstation has a 12.0 KByte buffer which limits the throughput to 0.99 Mbps

The network based flow control limits the throughput to 1.10 Mbps

Client Data reports link is 'T1', Client Acks report link is 'T1'

Server Data reports link is 'Ethernet', Server Acks report link is 'Ethernet'

Here's the results for a mirror in VA:

WEB100 Enabled Statistics:

Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done

running 10s outbound test (client to server) . . . . . 788.02Kb/s

running 10s inbound test (server to client) . . . . . . 2.89Mb/s

------  Client System Details  ------

OS data: Name = Windows 2000, Architecture = x86, Version = 5.0

Java data: Vendor = Sun Microsystems Inc., Version = 1.4.2_06

------  Web100 Detailed Analysis  ------

Cable modem/DSL/T1 link found.

Link set to Full Duplex mode

No network congestion discovered.

Good network cable(s) found

Normal duplex operation found.

Web100 reports the Round trip time = 36.32 msec; the Packet size = 1452 Bytes; and

No packet loss - but packets arrived out-of-order 0.04% of the time

This connection is receiver limited 99.33% of the time.

  Increasing the current receive buffer (12.0 KB) will improve performance

This connection is network limited 0.64% of the time.

    Web100 reports TCP negotiated the optional Performance Settings to:

RFC 2018 Selective Acknowledgment: ON

RFC 896 Nagle Algorithm: ON

RFC 3168 Explicit Congestion Notification: OFF

RFC 1323 Time Stamping: OFF

RFC 1323 Window Scaling: OFF

Information: Network Middlebox is modifying MSS variable

Server IP addresses are preserved End-to-End

bw = 304.97 based on packet size = 11Kbits, RTT = 36.32msec, and loss = 1.0E-6

The theoretical network limit is 304.97 Mbps

The transmit buffer (105.0 KByte) limits the application to 22.58 Mbps

Your receive buffer (12.0 KByte) limits the application to 2.74 Mbps

The network based flow control limits the application to 3.04 Mbps

Client Data reports link is 'T1', Client Acks report link is 'T1'

Server Data reports link is 'Ethernet', Server Acks report link is 'Ethernet'

From what I gather, both of them say increasing the Receive buffer (DefaultRecieveWindow, right?), will improve performance, but it doesn't.  If I do, I start getting lots of packets retransmitted according to them.  Like I said in my last post, I really don't know about any of this stuff, just what I'm experiencing, so maybe all of this is just normal.  It just doesn't seem like it.  And up until two months ago, your typical VB tweak would work for me, but now they kill me.  And 4 different modems have been used, so it's not a factor.  I know I'm being more anal retentive than a whole convent of nuns, and should just accept what is, but they why is really bugging me.  I don't know why, but it is.

[trogers]

Speed testing over the internet can give varied results due to factors which we have no control. Here is a link which I think give good advice in setting out a specific benchmark to gauge your comp's performance:

http://www.askmarvin.ca/testing.html

I have ask you to carry out the TCP/IP Analyzer test because your ccs file has left blanks some values. namely the RWIN and DefaultSendWindow values. By leaving these values blank will not reset them to default but may give you some unexpected results. From the test results above, your RWIN is set to 12 KByte, compared to XP's default vaue of 8 KByte.

As to desired settings to control packet losses, retransmissions, and throughputs, it is like a balancing act and the final results depend much on where we most often surf to and the traffic conditions we likely will face.

I found that in heavy traffic condition and high latency, I get better speeds having less packet losses and retransmission than to have higher throughput.

In medium traffic, I can achieve better speed by accepting some packet losses and with have a larger throughput.

I actually have 3 settings that I use when surfing the net depending on traffic conditions. Here is a link to another forum that I had posted:

http://forums.speedguide.net/showthread.php?t=192650

[Jodokast96]

The DefaultSendWindow value should not have been blank.  I have found that increasing that to 63888 has helped my uploads out by about 100kbps.  If it is blank, let me know, possibly I attached the wrong file.

Ok, this brings me back to the very first question I asked at the very beginning of this post.  The TCP/IP Analyzer reads the TcpWindowSize for it's RWIN number, not DefaultReceiveWindow.  It clearly says this, and I just checked it myself.  Nowhere on that page did it list the value I have entered for DefaultReceiveWindow.  Now I know VanBuren already tried to answer this, but perhaps I need a much simpler explanation.  What is the difference between the two, and how do they relate?  Because I keep seeing that they appear to do the same exact thing. 

DefaultRecieveWindow DefaultSendWindow is AFD parameters thats act like a RWIN / SWIN on windows XP SP2

Maybe this is where some of my confusion lies.  What exactly does act like mean?  Is it RWIN, or does it function kind of like RWIN?  Also, is this strictly an XP SP2 thing? Because I'm running 2k so does that even apply to me?

I glanced at that post you made, but haven't yet had the time to check those links you had in there.  As to what you say about different settings for different conditions, I'm talking about latencey differences here of less than 50ms.  Doesn't that seem to be a little on the sensitive side?

[Jodokast96]

Just ran a few quick tests.  Based on these and other's, here's some quick ideas.  Will use 3 values for examples.

For a given TcpWindowSize, and any DefaultReceiveWindow up to and including that, the TcpWindowSize is dominant.  Any DefaultReceiveWindow over the TcpWindowSize, and the DefaultReceiveWindow becomes dominant.

TcpWindowSize of 13068 and ReceiveWindowSize of 8192 gives same results as:

TcpWindowSize of 13068 and ReceiveWindowSize of 13068

TcpWindowSize of 8192 and ReceiveWindowSize of 13068.

TcpWindowSize of 13068 and ReceiveWindowSize of 63888 gives same results as:

TcpWindowSize of 8192 and ReceiveWindowSize of 63888

TcpWindowSize of 63888 and ReceiveWindowSize of 63888

TcpWindowSize of 63888 and ReceiveWindowSize of 8192

TcpWindowSize of 63888 and ReceiveWindowSize of 13068

I haven't tested each and every combination yet, but based on what I've seen so far, this is what I'm expecting to see.

[trogers]

Tweaking seeks to achieve at least 90% speed of both download and upload speeds.

Since the latency for sites that you surf to varies less than 50 ms, you have little worries about excessive loss packets (unless line quality is poor). You should maximise your throughput for both receive and send windows.

Try this ccs file and test it on this site:

http://www.microsoft.com/downloads/info.aspx?na=90&p=&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=049C9DBE-3B8E-4F30-8245-9E368D3CDB5A&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2f1%2f6%2f5%2f165b076b-aaa9-443d-84f0-73cf11fdcdf8%2fWindowsXP-KB835935-SP2-ENU.exe

[Jodokast96]

Tweaking seeks to achieve at least 90% speed of both download and upload speeds.

But that's just it.  Dealing with latencies of less than 50ms, I'm seeing decreases in speed of as much as 75%.  I can achieve that 90%.  My concern is that if I can acheive it from somewhere with a higher latency, why does it cause such a drop with a lower latency?  Or just to rephrase it, if I can acheive it from somewhere far away, why does that kill speeds near me?  With only a difference of 50ms or so?

I'll give that file a try, but I'm going to make a prediction first.  I looked at the settings, and I'm guessing that Speakeasy tests in California and Seattle will be in the 2500+ range, the East Coast ones will be about 800-1200, and the file download will be about 1800 or so. 

On a lighter note, I know you'd probably like to smack my head against the wall, but thanks for taking the time to keep following up on this.  I really do appreciate that you haven't gotten to the point of just saying, "Oh, man forget this clown".  Maybe one day I'll figure it all out.

[trogers]

I do not know if you have had monitored consistently and drew the conclusion of having lower download speed to sites with less latency.

You have to take into considerations traffic loads to those sites at different time of the day too. With higher traffic, the site server will allocate a smaller bandwidth to service you irrespective of your large bandwidth. The download speed you record is then a limit imposed by the site server, not your comp setting.

This is why the use of a server from Microsoft (with very large bandwidth) can make a good benchmark for more precise measurements to compare tweak settings.

[Jodokast96]

I've done this at all times of day, with the same results.  The low speeds with less latency only come with higher (over 20000 or so) TcpWindowSize or DefaultReceiveWindow values.  Ideally, I would like to find a list of good, large bandwidth servers that also list where they are located.  This would be a huge help in helping figure this out. 

With those new settings:

Speakeasy NY: 768Kbps about the same for the rest of the East Coast.  Lower RWIN usually about 2800kbps.

Speakeasy CHI:  1600Kbps usually gets the same as the East Coast, but not this time  However lower RWIN gives speeds of about 2790Kbps.

Speakeasy LA:  2100Kbps about the same for the rest of the West Coast.  Lower RWIN about 1000kbps.

Microsoft: 135-140Kbps which is about 1100Kbps I believe.  Even worse than I thought it would be.  Would probably get about 350Kbps, which should be about 2800Kbps with lower RWIN.

[trogers]

Try my ccs file setting and download from Microsoft again.

If you like to check download speed for a site with latency of 250 ms, here is the link to my ISP test site:

http://wow.asianet.co.th/16M.inc

[Jodokast96]

That was with your file.  I can't get that link to open, get the "Page Cannot Be Displayed".  I can ping it though, 585ms.

[trogers]

If your RWIN has been set to 12 kBtyes, then your download speed from Microsoft server reflected your setting.

[trogers]

Here is my ccs file with throughput set to 4 Mbps.

[Jodokast96]

With an RWIN of 12k, I can download at about 2800.  With you setting it drops to about 1000.

[Jodokast96]

Whoa, hold on a sec.  We're crossing messages here.  Everything I was just talking about was for the first file you sent.  I'll try the second one now.

[Jodokast96]

Second file gives roughly the same results as the first one.  Very minor improvements.

[trogers]

Web site of my ISP download test:

http://www.hispeedworld.com/main/speedtest.html

[Jodokast96]

Same as the last link, can ping and tracert it, but can't open it.