Well, after numerous attempts at tweaking TCP parameters I think I have found a solution.
I had narrowed down the problem to TCP send on the Windows 7 system hosting MediaBrowser. Keeping tests just on my home network and limited to Windows I was seeing the following numbers when streaming a large .mpg file.
Connectivity was: Win 7 client 1Gb Ethernet
Win 7 server wireless AC - 650Mb (this system was also used as Win 7 client for test 1 below)
Win 8 client/server
1. Win 7 client (wireless) streaming file from Win 8 Server (MediaBrowser) - I was seeing 230 Mbs on the network resource monitor.
2. Win 7 client (Ethernet) streaming same file from Win 7 server (MB) (Wireless) - I was only seeing 25Mbs throughput
3. Win 8 client (Ethernet) streaming same file from Win 7 server (wireless) - also seeing 25Mbs throughput.
After tweaks I was getting for the same tests.
1. 284 Mbs
2. 90 Mbs
3. 90 Mbs
I think tests 2 and 3 are now receiver constrained because if I ran test 1 using the Ethernet connected Win 7 system I could still only achieve 90 Mbs. Plus I had done no tweaking of TCP settings on that system.
I did find that if I turned on TCP heuristics on the Win 8 system that the throughput for test 3 went up to 175 Mbs - but then I found I was having some other issues so disabled it again. It's possible that further tweaking may improve things.
Let me tell you what I did:
1. On the Win 7 system I set the Global TCP settings to:
RSS: Enabled
Chimney Offload State : automatic
NetDMA State : disabled
DCA : enabled
Receive Window Auto-Tuning level : normal
Add on Congestion control : none (people recommend enabling ctcp but I found no difference)
ECN : disabled
Timestamps : disabled
I tried lots of combinations of these and other settings but alone they did nothing to improve upload time. I finally found a posting that suggested the following .
2. I increased the size of the TCP send and receive buffer in Windows registry (restart is required): I could find no documentation specific to these settings for Win 7 except for one posting so I thought I'd try it and it worked.
[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Afd \Parameters]
DefaultReceiveWindow = 131072
DefaultSendWindow = 131072
When I first went to the Afd\Parameters section of the registry the 2 keys were not there - just an entry for default (value not set). So I had to create the entries by right mouse click in the right hand window (where the default entry is) click on New DWord 32bit value and assigning the name DefaultReceiveWindow (no spaces) then right click on the new entry and select modify press the decimal button and enter the number 131072 and hit OK. Repeat for send window and just exit the registry editor. Changes are made to the registry and will take effect after the next reboot.
If you do this please make sure you backup the registry before making any changes.
Initially I only set the send window but then my previous download numbers on speedtests which were always great dropped dramatically. I also found that setting the windows to the same value gave me the best performance. I may play around with these numbers some more. I only used numbers that were a multiple of 64K (65536) sine that is the default TCP send window at the winsock level API.
I also found that I needed to make sure TCP heuristics were turned on. You can do this my using the netsh command from and elevated command prompt:
netsh int tcp set heuristics wsh=enabled
If needed you can also make changes to the global settings above using the appropriate netsh command.
Here is a link to a good primer on netsh if you are not familiar with it:
http://www.colorconsole.de/cmd/en/Windows_7/netsh.htmHere is a link that gives a write up on AFD its old and pre Win 7 but you get the idea.
http://smallvoid.com/article/winnt-winsock-buffer.htmlHere is a link to the post I found that gave me the solution:
http://stackoverflow.com/questions/1069 ... ut-linux-iI'll try and have my son rerun the tests remotely and see if he notices any improvement. From previous posts he couldn't get the .mpg file to stream so it should be an interesting test.
Sorry for being long winded. If anyone tries this and gets better results with different numbers and settings please let me know.
Regards
Mike