Serviio

Dan

the only way that I know of to change the TCP settings is either netsh or download a program called TCPip Optimizer from speedguide.net.

netsh int tcp show global

will give you the current settings

netsh int tcp show heuristics

will give you your current settings for heuristics. The link I sent for the netsh options is a great place to start. netsh is one of the capabilities I was aware of but have not thought or needed it for ages so that site was a great reference.

I just had my son run a test on that .mpg file that wouldn't play before and it worked perfectly. Network resource monitor showed 12Mbs throughput which is the max my ISP supports (they advertise 10Mbs) - so I think I declare victory.

On post with test results - for test 2 after tweaks I saw only 90Mbs throughput which surprised me. Turns out I have a defective Ethernet cable that links 2 routers in my network. The Win 7 server and Win 8 systems are connected to 1 router and the second Win 7 system, that was a client in test 2, is on the other. So in that test the maximum throughput would have been 100Mbs and I was getting a little over 90Mbs so I'm happy.

Will be a while before I can replace that cable as it runs through my basement and up through a wall behind built in bookcases !

Great work.

I had some issues during beta and worked through some cabling and NIC configuration issues and got it working, but I have siginificant bandwidth. Had forgotten completely the Win7/Server2003 builtin internet throttling. Hadn't had a need to do the netsh configuration in a long time.

I can stream full bluRay rips remotely without any stutter. (not that I would do that regularly!!!)

Zip with a little clean up this should be pinned to the support tab or included in the wiki.

Again thanks!

Agreed - the wiki would be the better place though.

The wiki is a user knowledge base, so I would encourage you/MikeL to create an article for the wiki.

I will do a write up next week. Want to give things a few days to make sure there are no detrimental effects of the changes.

Can anyone confirm that this fix works with Win 7 Ultimate, Professional and Enterprise - also any 32 bit versions?

Not sure why it wouldn't but I have no way of checking myself

I can confirm that it works on Win 7 Pro (stand alone and running under VMware) and Ultimate stand alone.

Further research suggests that an appropriate number for the DefaultSend and DefaultReceive reg hack can be optimized using the formula as follows:

upload speed/8 *1024

No real explanation as to how this was derived so take it for what it is.

Not sure where you came up with the 131K number, but it worked fine for me. For what it's worth, Using the research formula my number would be 499200. Testing I don't see any appreciable difference between the two values.

After further thinking about this I would like it if someone on the Serviio team could check and let us know if the code in the 1.4.x version used to set the socket send buffer size and if the code was modified in 1.5.1 to use the default (8K). From what I understand the value that I have updated in the registry can be overwritten on a per socket basis by setting SO_SNDBUF. so if the code were modified in a future release we could lose the benefit of making this setting in the registry (depending on what vale it was set to in the code).

So could I ask that if the code is going to be changed to make the value user settable in one of the config files. This would also negate the need for any kind of write up.

As to why I chose 131072 bytes.

I didn't want to make the value too big since my guess is that being a default value the OS will attempt to allocate that much memory on every socket that is opened (unless the app opening it is setting SO_SNDBUF). This could become a problem in systems that have limited memory and lots of network activity.
In most home computers most of the emphasis is on receiving large amounts of data as opposed to sending it so there could be lots of wasted memory allocation. (Does this make sense? I'm not sure if it is a valid assumption).

Also the value chosen is going to be a compromise as its effect will vary depending on your posted upload speed from your ISP and the RTT to the remote system that is trying to stream from MB. There is also limited value in setting it to a high value if the receiving system limits its TCP receive window.

For example watching a Wireshark trace of the traffic between a local ipad streaming from my Win 7 server the receive window advertised by TCP on the ipad does not go much above 131072.

I've never tried using Wireshark before today. I made 2 traces of the TCP traffic. One with the modified registry and one without (local access only). And basically the behaviour without the registry mod showed the sending system (Win 7 server) limited to sending 2 4K segments before waiting for an ACK. The receiving system (ipad) doesn't send the ACK immediately on receipt of the second 4K packet since it has advertised a receive window of 64K so the ACK is delayed until there is some timeout threshold on the ipad. So the transmission of the data is being throttled.

By comparison the trace after the registry mod is made and the TCP connection has worked its way through the TCP slow start and has reached a steady state. You see a steady stream of data packets with interspersed ACKs from the client - all in all a much more efficient use of the "pipe".

If my calculations are correct a window of 128K (131072 bytes) in my home network with a 1ms delay (RTT) should utilize the 1Gb network

131072 *8/0.001 = 1048576000b/s

over a remote link with a 30ms RTT I would need an upload bandwidth of approx. 35Mb/s. Since I have a 3rd of that I am not utilizing the send buffer to its max. As I said its all a compromise.

Hope this makes sense and my calculations and assumptions are correct.

Would really appreciate some feedback from one of the Serviio guys (preferably the guy who is programming with the Winsock API).

Cheers
Mike

We are now using a new library which doesn't allow setting the buffer out of the box, so yes, your theory is right. I will see if it can be easily added back.

Thanks Zip.

If it is to be added back then please consider making the value user settable in some way as the resultant behaviour is very dependant on a person's available upload bandwidth and the average RTT of any of their remote users.

Mike

Great thanks for that! It now works perfectly.

Since few days, my streaming speed was decreasing and I was unable to do torrenting. It means, my ISP is throttling my IP address. So, I bought a VPN because I read on this guide that by using a VPN you can defeat ISP throttling activities and enjoy fast internet speed.

This topic had nothing to do with Internet speeds. It's also too old to be applicable to the latest versions of both Serviio and Windows.