Testing network performance

[Karamano]

Disclaimer: new to linux, so sorry for asking these questions.

I am unable to stream smoothly video files over the network. The old school regular quality dvd rips stream ok (barely), but anything larger than that (720p and so on) is not even close to running smoothly, buffering 20-30 secs for 2-3 sec segment. Trying to stream files form a Win7 x64 computer. Tested streaming protocols SMB, NFS and UPnP- all stutter. Files are .MKV and .M4V type- anything over dvdrip quality stutters.

Hooked via LAN to a router 54Mbps (G). Tried wirelessly as well with my Samsung phone which can tether at 100Mbps (N) and wifi dongle Edimax EW-7811UN- same stuttering.
Internet streams, even HD ones like BBC, Hulu etc. stream smoothly.
Using my weak and limited Sony SMP-N200 streamer everything streams perfect over LAN and Wifi.

I thought the best way to begin approaching this problem was testing the network performance on the Pi with something like iperf (as google brought up), but unable to get the command working via SSH. Adding 'sudo' before it did not help either: "iperf: command not found".
Can someone explain what code I can enter to test the capabilities of my network to stream/transfer files so I could begin to look for solutions why my Pi is unable to stream decently?

[CurlyMo]

Code:

sudo apt-get install iperf

[Karamano]

(22nd Dec, 2012 10:56 PM)CurlyMo Wrote:  

Code:

sudo apt-get install iperf

Thanks.

Quote:iperf -t 60 -c <SERVER_IP_ADDRESS> -d

Here are the results if someone can help me analyse the situation:
My setup- Raspberry Pi (512MB. Brand new) connected to a 54Mbps router. The "server" where I want to stream files from is my laptop, and it is connected via wifi to the router (since laptop-router connection is proven sufficient to stream at least 720p as tested with stand-alone streamer Sony SMP-N200 which was also connected via wifi to router).

Did 2 tests for Pi-router connection,
1st via wifi connection to router using dongle Edimax EW-7811Un (150Mbps):

Terminal

[216] local 192.168.0.2 port 51391 connected with 192.168.0.4 port 5001
Waiting for server threads to complete. Interrupt again to force quit.
[ ID] Interval Transfer Bandwidth
[216] 0.0-50.0 sec 42.8 MBytes 7.17 Mbits/sec
[180] 0.0-50.2 sec 9.63 MBytes 1.61 Mbits/sec

2nd via ethernet connection to router:

Terminal

[212] local 192.168.0.2 port 51472 connected with 192.168.0.4 port 5001
Waiting for server threads to complete. Interrupt again to force quit.
[ ID] Interval Transfer Bandwidth
[212] 0.0-60.0 sec 105 MBytes 14.6 Mbits/sec
[176] 0.0-60.2 sec 20.6 MBytes 2.88 Mbits/sec

Are these sufficient to stream 720p or even 1080p?
If so, why isn't the XBMC client able to stream them smoothly and keeps buffering?
If not, what can I do to speed this up?

Thanks.

[CurlyMo]

Which one is the cliënt and which the server.

[rikardo1979]

what files u trying to play?
is if full hd with dts sound ? and do you have dts capable receiver connected ?

[Karamano]

(23rd Dec, 2012 02:44 AM)CurlyMo Wrote:  Which one is the cliënt and which the server.

They are both from the RPi client if I understand your question correctly. I mean, these are the logs from the SSH windows used to connect to my Xbian. the 7Mbps was while my RPi was connected via wifi dongle, and 14Mbps was my RPi connected to router via ethernet.
My laptop was the server: iperf -s

My current understanding is that my laptop can transfer over the network at least 14Mbps, because the RPi produced 14Mbps when connected to router by ethernet, but when on wifi using only the dongle, my RPi could only produce speeds of 7Mbps from the 14 my laptop was able to send the router.
I re-ran the test using my Samsung phone as a tether replacing the router because it has IEEE 802.11n and the router is only 54Mbps. This time while on the dongle my RPi produced 8-10Mbps- still seems slow for a 150Mbps dongle, doesn't it?
As my dongle is the Edimax EW7811UN famous for its compatibility to the RPi, does these speeds seem normal?

[CurlyMo]

Yes it does.

[Karamano]

(23rd Dec, 2012 02:48 AM)rikardo1979 Wrote:  what files u trying to play?
is if full hd with dts sound ? and do you have dts capable receiver connected ?

Because of your comment firstly I turned off ac3 and dts supported receiver in settings, since I have no receiver. Then some sample downloads finished and I began running 720p videos to see if any work. Here are the details of those who worked smoothly vs. those that stutterd (via network).

Stutter 1:

Quote:Format file : Matroska
File size : 1.09 GiB
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Stream size : 848 MiB (76%)
Bit rate : 5 285 Kbps
Writing library : x264 core 104 r1713 c276662

Audio
Format : DTS
Format/Info : Digital Theater Systems
Bit rate mode : Constant
Bit rate : 1 509 Kbps
Channel(s) : 6 channels

*works smoothly via USB.

Stutter 2:

Quote:Format file : MPEG-4
Codec ID : M4V
File size : 710 MiB
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Bit rate : 4 111 Kbps


Audio #1
Format : AAC
Bit rate mode : Variable
Bit rate : 154 Kbps
Maximum bit rate : 258 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy

Audio #2
Format : AC-3
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits

*works smoothly via USB.

Runs smoothly 1:

Quote:Format file : Matroska
File size : 638 MiB
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Bit rate : 3 695 Kbps
Writing library : x264 core 128 r2216 198a7ea

Audio
Format : AC-3
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits

Runs smoothly 2:

Quote:Format file : Matroska
File size : 550 MiB
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Bit rate : 3 280 Kbps
Writing library : x264 core 120 r2164 da19765

Audio
Format : AC-3
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy

Anything stands out here as to why 1st two stutter while 2nd two run smooth effortlessly?

[CurlyMo]

What OC setting and SD card? All videos work perfectly here...

[Karamano]

(23rd Dec, 2012 06:26 AM)CurlyMo Wrote:  What OC setting and SD card? All videos work perfectly here...

No OC - I haven't yet determined the Xbian recommended OC setting that still has a low chance for kernel panic. When OC'ed to turbo got a quick kernel panic (obviously noob ).

SD card is SanDisk SDHC Ultra 8GB. (EDIT: class 4)

Still trying to determine if it's the wifi dongle, the router, the xbmc client or the raspberry pi

[CurlyMo]

Try overclocking to medium. When you want to be sure, make an backup of your SD card first.

[Karamano]

(23rd Dec, 2012 06:56 AM)CurlyMo Wrote:  Try overclocking to medium. When you want to be sure, make an backup of your SD card first.

I tried overclocking. No improvement with the first 2 formats I posted above as "stutter". Tried with alternative xbmc clients and openelec was able to play the DTS one a little better but still ultimate stutter every minute or two.
The .m4v stutters badly in every client. So this is a Pi or XBMC issue most likely.

Also enhanced cache size in advancedsettings.xml, helped with 1080p stuttering a little, but still stops every 30 seconds to a minute to buffer. Mind you all tests are via wifi.

If there are any other suggestions I'd be happy to try.

[Enigmach]

Just my two cents since I've experienced similar problems before changing my setup. (My previous setup was my media on the pc connected through wifi with an NFS server, and my RPi cabled with no DTS receiver. This caused a lot of stutter on most media, even with overclocking.)

If I were you I would look into a different class of SD-card. I recently switched from a new Kingston Class 4 card to a Class 10 card and everything is incredibly smooth. My reasoning behind this, is that the streams that stutter in your case have a video bitrate above 4000 kbps and the ones that don't have bitrates below that. I'm not sure on how the Pi uses the networked files, but it seems as though the minimum write speed of the SD card of 4 MB/s could be the bottleneck which it was in my case. So if you have another card lying around, or willing to pay €9,- or something you could try this out.

Just as a note: files from USB worked better in my previous setup as well.

[Karamano]

(23rd Dec, 2012 10:18 PM)Enigmach Wrote:  Just my two cents since I've experienced similar problems before changing my setup. (My previous setup was my media on the pc connected through wifi with an NFS server, and my RPi cabled with no DTS receiver. This caused a lot of stutter on most media, even with overclocking.)

If I were you I would look into a different class of SD-card. I recently switched from a new Kingston Class 4 card to a Class 10 card and everything is incredibly smooth. My reasoning behind this, is that the streams that stutter in your case have a video bitrate above 4000 kbps and the ones that don't have bitrates below that. I'm not sure on how the Pi uses the networked files, but it seems as though the minimum write speed of the SD card of 4 MB/s could be the bottleneck which it was in my case. So if you have another card lying around, or willing to pay €9,- or something you could try this out.

Just as a note: files from USB worked better in my previous setup as well.

A few tests I did on the matter of the sd card:

1) Loaded problematic video files onto sd card and all played smooth.
Further more, a 20min clip took less than 14min to transfer over the network onto the sd card, which I assume means there is hypothetically enough network juice to keep up with the video, just the Pi or XBMC can't process the file successfully on the fly.

2) Executed "sudo hdparm -tT /dev/mmcblk0" test and got:

Terminal

Timing cached reads: 162 MB in 2.00 seconds = 80.80 MB/sec
Timing buffered disk reads: 58 MB in 3.06 seconds = 18.96 MB/sec

So I think sd card is up to speed, if I'm not mistaken.

[raspberry_pd]

Firstly, sorry to hear of your problems. Life would be much easier if stuff 'just worked' more often.

I don't want to muddy the waters here but one thing that I have noticed in the last couple of days is the impact of power supply on video playback - or at least that is how I am interpreting recent evidence. That being that until I tried a higher amp power supply I was unable to play the birds example video file:

http://www.auby.no/files/video_tests/h264_1080p_hp_4.1_40mbps_birds.mkv

from my Drobo NAS powered SMB share.

However using a different power setup to my usual, I was able to play the birds clip without substantial stutter three out of four times. Sure it took a little time to initially load the file but once it started playing it was fine.

Of course a couple of factors may make my experience unscientific or unrepresentative:

- I had just switched to the 3.6.11 kernel
- I am using a Model B Rev 2
- If I remember correctly I had not just the normal micro-USB power, but also power running into one USB port

The frustrating part is that when the file stopped, more often than not, CEC control was unavailable! I'd expect that when the file was playing but not afterwards It was clear whether XBMC has frozen or not but in effect it might as well have.

I'm impressed by your desire to solve the problem and willingness to test. Can you try downloading the above birds file and playing it from your SMB share? I have a strong suspicion that although that file is very high bitrate, resolution and has full-screen movement whilst also panning, because it is only a short sample, even the Model B Rev 2 can save it fully into RAM and thus that must help the smoothness of playback.