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

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

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.

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

Yes it could, try the Flow Control trick.

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

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

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

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

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

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

maybe just try a liveCD for local video playback testing

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.

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

+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?

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.

I totally agree, except that we haven't established that X is broken. We assume X is broken, but need confirmation. In his/her original post, tbessie stated:

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.

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.