Video playback from homebuilt NAS on gigabit network - slow?

Offloading HDDs and other functions to remote NAS or servers is increasingly popular
Post Reply
tbessie
Posts: 232
Joined: Tue Feb 05, 2008 10:07 pm
Location: San Francisco, CA

Video playback from homebuilt NAS on gigabit network - slow?

Post by tbessie » Wed Sep 30, 2009 8:47 pm

Hi all...

So I build a fileserver for myself to use instead of those SOHO NAS devices I had. Put Ubuntu Server on it, ran Samba, and exported a folder full of my ripped DVD library.

Well, using VLC (even with buffering amped up) plays anything back jerkily (little blips in the playback), and Windows Media Player Class/Home Cinema seems to have problems with Menus... but only over a network.

I'm using a Gigabit router, a Gigabit switch, CAT6 cabling, etc.

But I'm finding that, even when playing a video from two machines that are wired (no wireless), I get the above affect.

How does one go about debugging this kind of thing? I guess the 1st thing would be to check if I'm actually getting Gigabit speeds for one. What culprits have you found most previlent in these cases?

Edit:
By the way, I just tested this using a program that writes to a file and then reads it back to test speed on a mounted share. I got 221 Mbps (that's megabits, not bytes) write speed, and 182 Mbps read speed... I'm assuming the odd discrepency in write vs. read is due to buffering of that network traffic. Does that sound like enough raw speed for watching a glitch-free DVD? And does that sound particularly high or low, do you think?

- Tim

theycallmebruce
Posts: 292
Joined: Sat Jul 14, 2007 10:11 am
Location: Perth, Western Australia

Post by theycallmebruce » Wed Sep 30, 2009 9:57 pm

Interesting problem!

The throughput you quote sounds about right to me for the configuration you described. I would think that's plenty for stutter free DVD playback. Do you have jumbo Ethernet frames enabled for your network cards in both machines? If not, that may improve your throughput further.

One experiment you might like to try is to share out a directory in the RAM disk on your NAS (/dev/shm) using Samba, and see what performance you get to that. Then you could try copying some media to it and play back from there.

Let us know what you find!

tbessie
Posts: 232
Joined: Tue Feb 05, 2008 10:07 pm
Location: San Francisco, CA

Post by tbessie » Thu Oct 01, 2009 1:33 am

theycallmebruce wrote:Interesting problem!

The throughput you quote sounds about right to me for the configuration you described. I would think that's plenty for stutter free DVD playback. Do you have jumbo Ethernet frames enabled for your network cards in both machines? If not, that may improve your throughput further.

One experiment you might like to try is to share out a directory in the RAM disk on your NAS (/dev/shm) using Samba, and see what performance you get to that. Then you could try copying some media to it and play back from there.

Let us know what you find!
I'd thought of jumbo frames, tho' I don't think all of the devices on my network can use them, and I'm not in the mood to create internal subnets in my tiny space. :-)

I'll try the RAM disk idea, and see what I get. There may just be some funny bizniz with playing networked DVD rips... many people have done it fine, so I don't know why mine isn't working correctly.

- Tim

fwki
Patron of SPCR
Posts: 120
Joined: Mon Dec 17, 2007 7:06 am
Location: Houston, Texas U.S.A.

Post by fwki » Thu Oct 01, 2009 8:19 am

Your write speeds are higher due to RAM caching so the read speeds are a better indication of NAS performance. The theoretical maximum is 1000Mb/s and you are only hitting 18% of that. Some swtiches will reduce entire gigabit networks to 10/100 speeds when one client is 10/100, and you would have to turn off Flow Control in every NIC to prevent that problem. Give it a try.

jhhoffma
Posts: 2131
Joined: Mon Apr 25, 2005 10:00 am
Location: Grand Rapids, MI

Post by jhhoffma » Thu Oct 01, 2009 8:24 am

Does your router support QOS throttling? If so, enable it. That will prioritize traffic/latency based on the type of traffic. Media streams will take priority over file transfers. Gaming traffic takes priority over everything, etc...

What router and switch are you using? How is the network setup (diagram?).

tbessie
Posts: 232
Joined: Tue Feb 05, 2008 10:07 pm
Location: San Francisco, CA

Post by tbessie » Thu Oct 01, 2009 9:42 am

jhhoffma wrote:Does your router support QOS throttling? If so, enable it. That will prioritize traffic/latency based on the type of traffic. Media streams will take priority over file transfers. Gaming traffic takes priority over everything, etc...

What router and switch are you using? How is the network setup (diagram?).
Yes, the router supposedly suppots QOS.

Network toplogy:

[DLink DIR-655 WiFi Router]->[DLink DGS-2208 Switch] (Both gigabit)

All computers are plugged into the gagabit switch via CAT6 cables.
Plugged-in devices include:

x Home built desktop PC with gigabit LAN
x Thinkpad T400 with gagabit LAN, in dock
x Home built HTPC with gigabit LAN
x Slim Devices "Squeezebox Receiver" with 100Mbps LAN

Everything else connects via WiFi to the router (802.11g, mostly).

Hmm, I'm wondering if that Squeezebox Receiver could possibly slow down the entire network since it's not using a gigabit LAN.

I think the switch's docs said a single non-gigabit device didn't slow down the entire switch.

Do you think that could slow things way down for everyone else?

- Tim

fwki
Patron of SPCR
Posts: 120
Joined: Mon Dec 17, 2007 7:06 am
Location: Houston, Texas U.S.A.

Post by fwki » Thu Oct 01, 2009 10:07 am

Do you think that could slow things way down for everyone else?
Yes it could, try the Flow Control trick.

See this http://www.smallnetbuilder.com/content/view/30212/54/

theycallmebruce
Posts: 292
Joined: Sat Jul 14, 2007 10:11 am
Location: Perth, Western Australia

Post by theycallmebruce » Thu Oct 01, 2009 5:14 pm

Ethernet flow control, good call fwki!! Bleh, that would certainly explain the stuttering.

I wonder which device is the culprit? Maybe fire up Wireshark and figure out where the pause frames are coming from?

Also, if you're interested here are comments from switch vendors on issues around flow control, and how their switches handle these pause frames: http://www.networkworld.com/netresources/0913flow2.html

tbessie
Posts: 232
Joined: Tue Feb 05, 2008 10:07 pm
Location: San Francisco, CA

Post by tbessie » Thu Oct 01, 2009 11:49 pm

Well, I tried about every trick in the book that was suggested here, in various permutations, that I could try of an evening, and nothing increased read or write speeds at all. Quite interesting.

So I *might* be being limited to my hard drive speed, in which case I'll try the ramdisk idea someone suggested.

Also might be my switch and/or router - there's been a lot of talk lately about the DLink DIR-655 having slowdowns and odd behavior with the latest firmware revisions.

Part of the problem may just be VLC behavior over a network - there may be some magic setting I haven't yet found. Some other media players seem to stutter less (possibly not at all, but I haven't tried watching a movie long enough to check - will try watching one on the NAS from my HTPC soon and see how things go).

- Tim

lm
Friend of SPCR
Posts: 1251
Joined: Wed Dec 17, 2003 6:14 am
Location: Finland

Post by lm » Fri Oct 02, 2009 3:51 am

Try connecting server and the client directly without any other devices in between. You need a cross-connected cable for this (swaps data in and data out wires).

tbessie
Posts: 232
Joined: Tue Feb 05, 2008 10:07 pm
Location: San Francisco, CA

Post by tbessie » Fri Oct 02, 2009 8:40 am

lm wrote:Try connecting server and the client directly without any other devices in between. You need a cross-connected cable for this (swaps data in and data out wires).
Well yes, that *would* be as fast as the NICs and machines themselves could support. :-)

- Tim

Wibla
Friend of SPCR
Posts: 779
Joined: Sun Jun 03, 2007 12:03 am
Location: Norway

Post by Wibla » Fri Oct 02, 2009 9:17 am

with gig-e you dont need a special cable, gig-e nic's have auto mdi-x built in :)

PartEleven
Friend of SPCR
Posts: 279
Joined: Sun May 06, 2007 10:37 am

Post by PartEleven » Fri Oct 02, 2009 12:53 pm

I didn't read the whole thread, but I can't believe that your problem is bottlenecked by network speed. Did you check if the problem is a driver and/or codec problem? Does the video play smoothly locally on the target machine?

tbessie
Posts: 232
Joined: Tue Feb 05, 2008 10:07 pm
Location: San Francisco, CA

Post by tbessie » Fri Oct 02, 2009 3:33 pm

PartEleven wrote:I didn't read the whole thread, but I can't believe that your problem is bottlenecked by network speed. Did you check if the problem is a driver and/or codec problem? Does the video play smoothly locally on the target machine?
That'd be hard to test, since I install Ubuntu Server, which doesn't come with any playback facility. I could install X, etc. to check it out, if I feel motivated to do that.

I still suspect that VLC itself may have something to do with it... I've never got it working great on shares mounted over a network.

- Tim

flyingsherpa
*Lifetime Patron*
Posts: 474
Joined: Fri Sep 26, 2003 6:28 pm
Location: CT, USA

Post by flyingsherpa » Sat Oct 03, 2009 9:13 am

tbessie wrote:That'd be hard to test, since I install Ubuntu Server, which doesn't come with any playback facility. I could install X, etc. to check it out, if I feel motivated to do that.
maybe just try a liveCD for local video playback testing

lm
Friend of SPCR
Posts: 1251
Joined: Wed Dec 17, 2003 6:14 am
Location: Finland

Post by lm » Sat Oct 03, 2009 10:36 am

Wibla wrote:with gig-e you dont need a special cable, gig-e nic's have auto mdi-x built in :)
Oh, I didn't know that! So in that case this test should be the first thing, because it's very easy to do and it would help eliminate the effect of other networked devices and the switch.

If the playback would be fast this way, then it would be pretty much positive that the switch or other devices on the network are somehow the culprit.

PartEleven
Friend of SPCR
Posts: 279
Joined: Sun May 06, 2007 10:37 am

Post by PartEleven » Sat Oct 03, 2009 6:11 pm

tbessie wrote:That'd be hard to test, since I install Ubuntu Server, which doesn't come with any playback facility. I could install X, etc. to check it out, if I feel motivated to do that.

I still suspect that VLC itself may have something to do with it... I've never got it working great on shares mounted over a network.

- Tim
I didn't mean locally on the server. I meant play the file locally on whatever system you are using to view the movie.

tbessie
Posts: 232
Joined: Tue Feb 05, 2008 10:07 pm
Location: San Francisco, CA

Post by tbessie » Sun Oct 04, 2009 1:17 am

PartEleven wrote:
tbessie wrote:That'd be hard to test, since I install Ubuntu Server, which doesn't come with any playback facility. I could install X, etc. to check it out, if I feel motivated to do that.

I still suspect that VLC itself may have something to do with it... I've never got it working great on shares mounted over a network.

- Tim
I didn't mean locally on the server. I meant play the file locally on whatever system you are using to view the movie.
Ahhhhh! Good idea, I'll try that and see what happens. Probably the 1st test I should have tried.

- Tim

Jay_S
*Lifetime Patron*
Posts: 715
Joined: Fri Feb 10, 2006 2:50 pm
Location: Milwaukee, WI

Post by Jay_S » Mon Oct 05, 2009 6:21 am

PartEleven wrote:I can't believe that your problem is bottlenecked by network speed.
+1

Neither can I. The maximum allowed combined bitrate for DVD is 10.08 Mb/s, though I've never seen a DVD encoded that high. Even if you were on a 100Mb/s network, it's plenty for streaming DVD rips. Hell, a 2 hour 30GB blu-ray rip only needs 4.3 MB/s (math: 30720MB / 7200 seconds); roughly 35 Mb/s.

This sounds like a codec problem to me. What did you discover when playing files locally?

lm
Friend of SPCR
Posts: 1251
Joined: Wed Dec 17, 2003 6:14 am
Location: Finland

Post by lm » Tue Oct 06, 2009 4:57 am

When X is broken, "I can't believe that Y affects X" is not a very good way to find the cause.

Obviously a correctly functioning network should not be the bottleneck. But what if the network is faulty?

Of course the local playback test should probably be tried first.

Jay_S
*Lifetime Patron*
Posts: 715
Joined: Fri Feb 10, 2006 2:50 pm
Location: Milwaukee, WI

Post by Jay_S » Tue Oct 06, 2009 6:44 am

lm wrote:When X is broken, "I can't believe that Y affects X" is not a very good way to find the cause.
I totally agree, except that we haven't established that X is broken. :D We assume X is broken, but need confirmation. In his/her original post, tbessie stated:
221 Mbps ... write speed, and 182 Mbps read speed...
So s/he is already achieving speeds in excess of 100base-T. Which tells me that the other non-gigabit devices on his network are not forcing the switch to throttle down to 100Mb. These speeds are also well beyond what is needed for reliable video streaming.

tbessie: you can use jperf to test the maximum throughput of your network. jperf is the same as iperf, but has a java GUI. Get it here:
http://code.google.com/p/xjperf/

The GUI looks like this. jperf/iperf does TCP stream tests from any NIC, over your network, to any other NIC. This takes the CPU, disk subsystems, higher-level protocols, etc. out of the equation - it's strictly a measurement of what your network is capable of. It needs to be running on both computers on either end. One side will run it in server mode, the other in client mode. You should see 800-900 Mb/s from between your gigabit-NIC hosts. To make sure you saturate your network, play around with TCP Window Size on the host - I cannot get 900Mb/s without setting TCP Window Size to 64k or higher.
Last edited by Jay_S on Tue Oct 06, 2009 7:13 am, edited 1 time in total.

PartEleven
Friend of SPCR
Posts: 279
Joined: Sun May 06, 2007 10:37 am

Post by PartEleven » Tue Oct 06, 2009 7:11 am

lm wrote:When X is broken, "I can't believe that Y affects X" is not a very good way to find the cause.
True, that was just my personal opinion from experience with my own network. Except here we also haven't found out that "Z doesn't affect X", and Z is arguably easier to test than Y. My main argument was that tbessie jumped in and assumed that the network must be at fault.

Post Reply