Tuning Windows 10 for Protocol-2

Forum rules
Until such time as the New Protocol firmware goes into general release, all discussion will be concentrated here.
User avatar
W2PA
Posts: 73
Joined: Sun Apr 09, 2017 6:34 pm
Location: LaGrangeville, NY
Contact:

Tuning Windows 10 for Protocol-2

Postby W2PA » Sun Feb 03, 2019 3:23 pm

This is probably the right place to post this, rather than "Network Connections & Network Hardware" since this mostly has to do with P2 and that other topic it mostly about hardware.

After some recent experimenting with Windows 10 network settings, I came across one that made a big difference in reducing UDP glitches and sequence errors that cause audible artifacts in the audio streams and visual ones in the display. I'm running firmware v1.6pre and Thetis 2.6.2 with the ANAN-8000DLE, and have been experiencing these discontinuities in the data streams over a dedicated Ethernet connection. By enlarging two socket buffer sizes I have seen a dramatic improvement with my setup. From what I've read on various forums, the default size of these buffers is 8k which is too small for UDP, particularly at high network speeds.

This change involves adding two new values to a registry entry - DefaultReceiveWindow and DefaultSendWindow. If you're uncomfortable playing with Windows internals this might be beyond your comfort level. If so, either don't do it, or at least make a backup of your registry so you can undo things. Obviously if you're not having any drop-outs, audio glitches, Seq errors, etc., you probably don't need to do it. But it's pretty simple.

Here's how it's done:

1) Start the registry editor (regedit) by typing "regedit" (without quotes) in the Windows search entry field next to the start button. Then click on regedit when it appears in the list above near "Best Match". Click Yes when it prompts you with the security warning.

2) In the navigation pane to the left, click down to the following key entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters
and single left-click on it (i.e. on "Parameters").

3) Right-click in the blank space in the right-side pane and choose "New - DWORD (32 bit) value" from the menu. A new value called "New Value #1" appears with the name highlighted.

4) Change the name of the new value to DefaultReceiveWindow (make sure to spell it correctly) and hit enter or click elsewhere to make it take effect

5) Right-click on this new entry and choose "Modify..."

6) In the popup window, make sure the Hexadecimal radio button is selected, enter 200000 in the Value data field, and click OK.

7) Repeat steps 3, 4, 5, and 6, but name this next new value DefaultSendWindow. You should now have two new values under "Parameters"

8) Close regedit and reboot Windows 10.

The above modification increases the default buffer sizes to 2M. I tried 20k and it had no effect and I haven't played around with the value any further. But at this level, in operating for hours over the past day or so, I no longer see or hear any glitches in data streams in either direction (to or from the radio) and the Seq errors are gone almost entirely. I still see a Seq->2 very rarely, always on a T/R transition, but never accompanied by any other symptom heard in audio or seen on the display.

I wondered about the effect on latency but I honestly have not noticed any whatsoever, even on high speed CW and FT8. I haven't attempted to measure it though (yet).

Anybody see any down side to this? I'm no Windows expert, but happy with the results.
Last edited by W2PA on Sun Feb 03, 2019 4:31 pm, edited 1 time in total.
73,
Chris, W2PA
User avatar
Tony EI7BMB
Posts: 242
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: Tuning Windows 10 for Protocol-2

Postby Tony EI7BMB » Sun Feb 03, 2019 4:29 pm

Thanks Chris, just implemented this on protocol 1 , will see how it goes.
User avatar
Tony EI7BMB
Posts: 242
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: Tuning Windows 10 for Protocol-2

Postby Tony EI7BMB » Sun Feb 03, 2019 10:34 pm

Could not see any noticeable change on protocol 1, but strangely when I reverted to original windows settings by deleting both reg entries I've had just one overflow in 3 hours and zero oops.
User avatar
W2PA
Posts: 73
Joined: Sun Apr 09, 2017 6:34 pm
Location: LaGrangeville, NY
Contact:

Re: Tuning Windows 10 for Protocol-2

Postby W2PA » Mon Feb 04, 2019 12:16 am

Thanks for the experiment, Tony. I wouldn't expect to see any improvement in P1, only in gig-E and P2. Interesting that you saw actual degradation.
73,
Chris, W2PA
User avatar
Tony EI7BMB
Posts: 242
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: Tuning Windows 10 for Protocol-2

Postby Tony EI7BMB » Mon Feb 04, 2019 9:58 am

Yeah not really sure why it would degrade, perhaps some other variable in play . I'll try again when I get around to upgrading to P2
User avatar
w-u-2-o
Posts: 1664
Joined: Fri Mar 10, 2017 1:47 pm

Re: Tuning Windows 10 for Protocol-2

Postby w-u-2-o » Tue Feb 05, 2019 2:22 am

I tried this and it made no difference whatsoever.
User avatar
W2PA
Posts: 73
Joined: Sun Apr 09, 2017 6:34 pm
Location: LaGrangeville, NY
Contact:

Re: Tuning Windows 10 for Protocol-2

Postby W2PA » Tue Feb 05, 2019 4:11 am

Well, your mileage may vary, Scott. This is something that may only make a difference if you’re having data flow issues.
73,
Chris, W2PA
User avatar
W1AEX
Posts: 205
Joined: Sun Apr 09, 2017 6:17 pm
Location: Connecticut, USA
Contact:

Re: Tuning Windows 10 for Protocol-2

Postby W1AEX » Tue Feb 05, 2019 11:59 pm

Chris,

I remember playing with the DefaultReceiveWindow and DefaultSendWindow registry values with different versions of windows over the years. I believe that Microsoft added the "auto tune" feature for those values with Windows 2000 or maybe Windows XP. As I recall, the OS would slide those values up and down from 8k to 64k to "optimize" the TCP stack for whatever data speed you were running, and it worked pretty well. That being said, I don't know if that "auto optimized" value range (8k to 64k) can really be optimal for a full gigabit direct connection, so it seems like experimenting with various manual settings would have merit if a user's ANAN was experiencing dropouts or other communication errors. It will be interesting to see if playing with those numbers can mitigate those problems for users who are seeing them.

I'm a lucky guy and Protocol 2 is running (almost) flawlessly so it's all academic for me (thankfully)!

73,

Rob W1AEX
"One thing I am certain of is that there is too much certainty in the world."

Return to “Protocol 2 (all radios)”