INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Windows networking discovery (thanks to Computer Audiophile)  (Read 5082 times)

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42336
  • Shoes gone again!
Windows networking discovery (thanks to Computer Audiophile)
« on: August 08, 2013, 06:10:42 pm »

Chris, our friend at Computer Audiophile, is working on an article about wireless networking.  He was having problems getting 192kHz FLAC files to play nicely over the wireless network using MC.

He helped do a bunch of tests, and what we learned is that reading from a file over the wireless network in small packets was orders of magnitude slower than reading with larger packets.

I was surprised by the result, because one of the basic jobs of the operating system is to provide an intelligent caching layer for file I/O.  You might expect a small performance improvement by changing read block sizes, but I would not expect large differences (unless you were doing something dumb like reading one byte at a time or disabling cache).

In the case of FLAC, the reference decoder reads about 8KB at a time (varying by a few bytes as frame sizes change).  Adding a simple caching layer to read slightly larger blocks changed the performance Chris got on the network by about 10x.  We don't know if this is specific to certain hardware, operating systems, etc.

As a result of this discovery, we've added a simple caching layer that engages whenever something reads in small blocks (like FLAC).  When something reads in large blocks, the layer does nothing.  It's possible this could help the performance in other parts of the program that read in small chunks.  Sometimes things read a header in little chunks before digging into real data, so this would help those cases as well.

This was the history change:
Faster: File I/O adds a buffering layer that engages when small reads are performed so that underlying reads are never too small (a real world example where this helps is with FLAC playback over some types of wireless networks).

Thanks to Chris for his help.
Logged
Matt Ashland, JRiver Media Center

Hendrik

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 10925
Re: Windows networking discovery (thanks to Computer Audiophile)
« Reply #1 on: August 09, 2013, 12:34:25 am »

I discovered the same some time and increased block read size on LAV Splitter as well back then, but the user was reporting from a high-latency/high-throughput wired network, but i guess the same concepts apply.
LAV now reads 128kb blocks on movie playback, that seemed to be a sweet spot that made it work properly for such network connections.

Windows' caches are probably too small, more in the range of 4kb to avoid a complete performance disruption when you read much smaller blocks.
Logged
~ nevcairiel
~ Author of LAV Filters

InflatableMouse

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3978
Re: Windows networking discovery (thanks to Computer Audiophile)
« Reply #2 on: August 09, 2013, 05:39:08 am »

I wonder if 'TcpAckFrequency' and 'TCPNoDelay' have anything to do with this. Maybe he had those set for something, tried to resolve streaming issues in the past or maybe he plays online games and thought it a good idea to reduce latency for better headshots.

I have no idea what the effect is on wireless networks but I suspect it can't be good if those are set incorrectly. Maybe its worth checking what those values are set to (default is they don't exist).

These are basically 2 registry keys under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{string}

You need to find which string is the interface you're using and see if TcpAckFrequency and TCPNoDelay exist and take note of their values. It may be difficult to find the correct interface, in that case I suggest you set a fixed ip address, this makes it easier to find.



Logged

Hendrik

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 10925
Re: Windows networking discovery (thanks to Computer Audiophile)
« Reply #3 on: August 09, 2013, 07:40:25 am »

If anyone toys with those settings, its their own loss, because they have usually only negative or at best cosmetic effects (ping looks lower, but it isn't really)
Logged
~ nevcairiel
~ Author of LAV Filters

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72402
  • Where did I put my teeth?
Re: Windows networking discovery (thanks to Computer Audiophile)
« Reply #4 on: August 09, 2013, 08:10:29 am »

This reminded me of another thread from a long time ago, about jumbo frames:
http://yabb.jriver.com/interact/index.php?topic=24101.0

Chris's problem may be driver related, not OS.
Logged

AUser

  • Junior Woodchuck
  • **
  • Posts: 62
Re: Windows networking discovery (thanks to Computer Audiophile)
« Reply #5 on: August 10, 2013, 04:19:37 pm »

It used to be that 64K was the recommended block size (best smallest size) for transferring through the windows IO subsystem
That size increased IO transfer speed from usb drives (by magnitudes over smaller sizes) with an mpeg2 parser I worked with
http://technet.microsoft.com/en-us/library/cc938632.aspx

How that ties info network speed/latency might be worth playing with
Logged

The Computer Audiophile

  • World Citizen
  • ***
  • Posts: 161
Re: Windows networking discovery (thanks to Computer Audiophile)
« Reply #6 on: August 13, 2013, 11:42:01 am »

This reminded me of another thread from a long time ago, about jumbo frames:
http://yabb.jriver.com/interact/index.php?topic=24101.0

Chris's problem may be driver related, not OS.
Jumbo frames not in use here.
Logged
Pages: [1]   Go Up