DefaultSendWindow improves upload speeds >5 Mbps

[EricMartello]

Originally posted by: EricMartello
HKLM\System\CurrentControlSet\Services\AFD\Parameters

If DefaultSendWindow is not already there, add it. It is a DWORD value in HEX format.

I have 20/20 FiOS and mine is set to 2560000 and that should be good for you too. I get 20 up and down all the time.

Originally posted by: guyver01
unless you're on windows 95 98 ME or NT.. this doesn't do squat.

Windows XP and higher already automatically adjust the default send tcp window

Yesterday there was a good thread that got locked in ATOT regarding tweaks to improve upload speeds. This is largely for those of us who have upload caps of 5 Mbps or more.

This Guyver01 dude is spreading some misinformation about the DefaultSendWindow and its effect on TCP/IP performance. It DOES NOT auto adjust and the default parameters are not designed to accommodate TCP/IP uploads of 5Mbps plus. This is why you will not see your advertised upload speeds unless this tweak is made. Trust me, it works, it IS NECESSARY in XP, Vista and most likely Windows 7. For those of you who want to do this tweak, I wrote a detailed DefaultSendWindow How To Guide which also includes the formula to calculate your optimal value.

 

[imagoon]

All you doing is changing the defaults for a program that uses sockets to send data and fails to change the setting on its own. If the programmer changes the setting in the program call, it overrides this setting. The 2mbit limit you mentioned in your link to yourself is the default limit for the default send window. Whatever program you were using to test was failing to override the default. If this setting didn't adjust, as you insist it doesn't we would never go over 2mbit/s even on Gig ethernet. I am pushing 114MB/s a second at this moment to a server which is above 2mbit/s

Your change will only change the default on a program that doesn't change the setting like Adobe Flash, making it faster because the setting was forced higher by default.

Socket programs can change this value on the fly and those that do "auto tune."

http://support.microsoft.com/kb/823764

Afd.sys is the kernel-mode driver that is used to support Windows Sockets applications. When there are three default values, the default is calculated based on the amount of memory detected in the system:

* The first value is the default for smaller computers (less than 19 MB).
* The second value is the default for medium computers (<32 MB on Windows XP Professional, <64 MB on Windows Server 2003).
* The third value is the default for large computers (>32 MB on Windows XP Professional, >64 MB on Windows Server 2003).

For example, if the default is given as 0/2/10, a system containing 12.5 to 20 MB of RAM would default to 2.

The following values can be set under:

HKEY_LOCAL_MACHINE

\SYSTEM

\CurrentControlSet

\Services

\Afd

\Parameters
DefaultReceiveWindow

Value Type: REG_DWORD

Default: 4096/8192/8192

Description: 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. Applications can modify this value on a per-socket basis with the SO_RCVBUF socket option.
DefaultSendWindow

Value Type: REG_DWORD

Default: 4096/8192/8192

Description: This is similar to DefaultReceiveWindow, but for the send side of connections.


I have a screenshot of the all default TCP/IP settings pushing 291.82Mbit/sec outbound also.

 

[EricMartello]

That's a long post of pure fail which ignores the simple fact that changing the DSW value is a well-known and accepted method of improving upstream performance on connections with high upstream caps.

Plus I like how you linked to something completely unrelated to the issue at hand - this isn't an issue with a specific program, it is an overall cap on the upstream that MS put in place most likely to reduce the spread of worms/malware.

I don't know how to make it any simpler for you to understand. If your upstream is >5 Mbps and you are having upload speeds below your advertised speeds then adjusting the DSW in the registry WILL in most case remedy the problem. It's that simple, end of story... now please shut up and stop spreading this nonsense. It's ONE FUCKING REGISTRY VALUE. If you don't want to change it THEN DON'T.

If you use Windows XP/Vista are having slow upload issues THERE IS NO GOOD REASON NOT TO TRY THIS!

But this one change alone took me from 2 Mbps to the proper 20 Mbps and it has worked for everyone who tried it. Don't try to discourage people from trying it with your inability to understand this extremely simple concept: bigger upstream needs bigger buffer.

Now leave.

 

[EricMartello]

Originally posted by: imagoon
I have a screenshot of the all default TCP/IP settings pushing 291.82Mbit/sec outbound also.

Good for you! Want a medal? MINE THREE DID NOT push over 2 Mbps until I changed the DSW to a value appropriate to my upstream.

Anything else you care to add?

Oh and BTW there are differences in network adapters that can affect the performance. A system with a 300 Mbps upstream is probably a server with a server-grade NIC, it is not using a consumer-grade NIC, nor does said nic have consumer grade drivers which do everything in software. It has a hardware DSP which can explain why you allegedly get high performance with default settings.

 

[spidey07]

That's because windows TCP stack and TCP in general weren't good at dealing with high bandwidth/high latency connections (aka, broadband).

OP - you're correct. That value is the starting value and TCP is supposed to adjust it's window size based on latency, ack time, lost segments, etc. In a high latency network like broadband it nevers gets really big because the alogorithm prevents it. Making the window size much larger to start with overcomes this limitation.

guyver01 is in the wrong here. He almost gets it. default send window is what the stack will start it's window size as and can give incredible difference in performance if you set it much higher. The window size is increased or decreased in small increments based on what I mentioned above and they are small increments. TCP window size will never really "ramp up" to the huge values you want with high bandwidth/high latency connections unless you kick it to start the algorithm much higher.

 

[imagoon]

Originally posted by: EricMartello

Originally posted by: imagoon
I have a screenshot of the all default TCP/IP settings pushing 291.82Mbit/sec outbound also.

Good for you! Want a medal?

Nope, because quite frankly you seem to be one of those people the can't accept that something you said *might* only apply in certain situations. Your tweak worked fine you, wonderful. It indicates you have a high latency connection. Your setting on low latency connection will have very different effects.

Originally posted by: EricMartello
That's a long post of pure fail which ignores the simple fact that changing the DSW value is a well-known and accepted method of improving upstream performance on connections with high upstream caps.

Plus I like how you linked to something completely unrelated to the issue at hand - this isn't an issue with a specific program, it is an overall cap on the upstream that MS put in place most likely to reduce the spread of worms/malware.

I don't know how to make it any simpler for you to understand. If your upstream is >5 Mbps and you are having upload speeds below your advertised speeds then adjusting the DSW in the registry WILL in most case remedy the problem. It's that simple, end of story... now please shut up and stop spreading this nonsense. It's ONE FUCKING REGISTRY VALUE. If you don't want to change it THEN DON'T.

If you use Windows XP/Vista are having slow upload issues THERE IS NO GOOD REASON NOT TO TRY THIS!

But this one change alone took me from 2 Mbps to the proper 20 Mbps and it has worked for everyone who tried it. Don't try to discourage people from trying it with your inability to understand this extremely simple concept: bigger upstream needs bigger buffer.

Now leave.

You fail to see that I was not discrediting you. Pointing out that your tuning method is specific to you.

If you use Windows XP/Vista are having slow upload issues THERE IS NO GOOD REASON NOT TO TRY THIS!

There is but you won't listen.

bigger upstream needs bigger buffer.

This also is not always the case but you blindly assume it is so.

Originally posted by: Spidey07
That value is the starting value and TCP is supposed to adjust it's window size based on latency, ack time, lost segments, etc. In a high latency network like broadband it nevers gets really big because the alogorithm prevents it. Making the window size much larger to start with overcomes this limitation.

Originally posted by: EricMartello
It DOES NOT auto adjust and the default parameters are not designed to accommodate TCP/IP uploads of 5Mbps plus.

I think spidey just proved you wrong on a chunk of your post. He says it adjusts based on parameters. That is autoadjusting. Moving it to a better starting point is tweaking that might be relevant to a certain type of connection, IE high bandwidth and high latency. Just because it works for you it is not best for everyone. Did you get your speed results on one of those speed test sites?

Get off your high horse.

No wonder the post got locked. This one should be to.

 

[EricMartello]

Originally posted by: imagoon
Nope, because quite frankly you seem to be one of those people the can't accept that something you said *might* only apply in certain situations. Your tweak worked fine you, wonderful. It indicates you have a high latency connection. Your setting on low latency connection will have very different effects.

High latency? What? You don't even understand why setting the buffer to a static value improves performance. It has nothing to do with latency. It has to do with the fact that the default values cause the buffer to fragment packets. Setting the DSW to the appropriate size for your upstream will reduce or eliminate the fragmentation thus allow you to maintain full throughput.

You fail to see that I was not discrediting you. Pointing out that your tuning method is specific to you.

If you use Windows XP/Vista are having slow upload issues THERE IS NO GOOD REASON NOT TO TRY THIS!

There is but you won't listen.

There is no perceptible performance impact from setting the DSW if your on a system that is even remotely modern. Those examples you cited...seriously, who is running a system with 32-64 megs of ram these days? Obviously a person running an outdated system like that is not going to be splurging for the fastest internet connection. -.-

bigger upstream needs bigger buffer.

This also is not always the case but you blindly assume it is so.

I'm not talking about all possible contingencies, am I? I am talking about a specific situation where setting the DSW is required to get maximum throughput.

I think spidey just proved you wrong on a chunk of your post. He says it adjusts based on parameters. That is autoadjusting. Moving it to a better starting point is tweaking that might be relevant to a certain type of connection, IE high bandwidth and high latency. Just because it works for you it is not best for everyone. Did you get your speed results on one of those speed test sites?

It does not auto-adjust to the CORRECT VALUE, which is what the Guyver01 guy was wrong about. If you divide the decimal value of the DSW by 128, the result will be the value in Kbps for which that size DSW buffer is suited for.

8192 / 128 = 64 Kbps
256,000 / 128 = 2,000 Kbps

It will not auto-scale to optimal values because there is a limitation to the maximum scaling factor applied to these values, i.e. you will not get 256,000 by leaving it on the default setting, and Spidey is simply stating that. As the data rate increases, a small buffer cannot do it's job effectively and packets get dropped and/or fragmented. By setting the value in the registry, it will not need to scale and "guess". It's a similar benefit to how using a fixed-size swap file improved disk performance on XP vs having a dynamic swap file that windows kept resizing.

The thread was locked for being in the wrong forum, not because there was anything wrong with the information in it!