Hi all - I'm having a problem when streaming video of my unRaid array and I'm looking for advice on how to track down the cause.  Essentially, when streaming bulk AV content (usually during DVD playback via MCE) the video will sometimes underrun and stutter.  When I look at the network load monitor which I run in my sidebar on vista, I notice that the network activity seems to drop out and then come back again a little later, when the video recovers and continues.  I have actually noticed this happening when I'm browsing photos or copying files too the array as well, but its really not very annoying when that happens.  I only really notice when it interrupts movie playback.

 

I'm pretty sure that its the unraid array which is stuttering, but I can't figure out why it would be doing so.  Anyone have any ideas or diagnostics I should run?

 

Hi all - I'm having a problem when streaming video of my unRaid array and I'm looking for advice on how to track down the cause.  Essentially, when streaming bulk AV content (usually during DVD playback via MCE) the video will sometimes underrun and stutter.  When I look at the network load monitor which I run in my sidebar on vista, I notice that the network activity seems to drop out and then come back again a little later, when the video recovers and continues.  I have actually noticed this happening when I'm browsing photos or copying files too the array as well, but its really not very annoying when that happens.  I only really notice when it interrupts movie playback.

 

I'm pretty sure that its the unraid array which is stuttering, but I can't figure out why it would be doing so.  Anyone have any ideas or diagnostics I should run?

Google "vista slow network"

 

You are not alone... (I think SP1 fixes this)

 

Well, I think I got to the bottom of it.  I took some traces using ethereal and went over them.  I found that occasionally a burst of packets at the end of an SMB block read was getting dropped.  I suspect one of the cheap switches in my network, but it could be the NIC at either end as well I suppose.  Either way, it was the retry playing out which took all of the time.  Vista has the TCP nagle algorithm turned on by default, so when the end of the burst of packets got dropped, the system waited the default timeout (200mSec) before acking the first packets of the burst.  The unRAID machine's tcp stack then responds by sending just one of the dropped packets and waiting for an ack from the Vista machine.  The nagle algorithm kicks in again and there is another 200msec delay before the packet is acked.  This continues until all of the packets which were dropped have been sent again and the system continues.  Since there are usually 5-10 packets dropped, this means a total dropout of 1-2 seconds which causes the video to underrun.

 

Generally, this is less than optimal behavior on the part of both network stacks.  I think the linux side should probably keep sending from the retransmission point and the windows side certainly should not delay the ack of any retransmitted packets.  Still, the root cause was the lost packets in the first place.  I suspect one of the switches in my network probably had its buffers overflow for some reason.  I ended up working around the problem by disabling the nagle algorithm on the windows machine.  Now I can play pack with no stuttering, even while putting a bunch of other load on the unraid server at the same time. 

 

BTW - RTM Vista ignores the registry settings which allow you to do this.  You need to have either the hotfix or SP1 installed in order for it to pay attn to the nagle settings.    SP1 alone didn't address the problem, however.

 

Well, I think I got to the bottom of it.

 

...

 

Outstanding analysis!  Well done, man!

John could you please list the appropriate registry changes here for future reference?

 

 

The settings for a give nic can be found under

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<NIC Guid>

where NIC guid is the guid for the NIC as reported by either ethereal or sometimes under the Description field when using ipconfig /all.

 

There are two keys you will need, they were not created when I added mine, but they may be there already for you.  Both are DWORD values.  They are

TcpAckFrequency

and

TcpDelAckTicks

 

TcpAckFrequency controls the maximum number of un-acked packets before the algorithm kicks in.  It should default to 2.  Generally speaking, my driver does not seem to be servicing the NIC fast enough for this to matter most of the time, but setting it to 1 effectively will shut of the algorithm (every time there is 1 unacked packet, an ack should be sent, although as noted above because of the service frequency by the driver, there are usually many packets to ack by the time the stack gets around to it).

 

TcpDelAckTicks controls the amt of time to wait while the number of unacked packets is below TcpAckFrequency before senting an ack (units are in 100mSec chunk, so 1 == 100mSec, 2 = 200mSec, etc).  Default is 2, setting it to 0 should disable nagle.

 

Once changes have been made, either bounce the tcp/ip service and your NIC or reboot.

 

Please note that the stock versions of most editions of windows ignore these settings unless you have the appropriate hotfixes.  For vista, SP1 should do the trick.  For XP and other OSs, see the a wrap-up of the topic and patches here

 

http://smallvoid.com/article/winnt-nagle-algorithm.html

Good wiki subject?

 

Thanks man.