OpenELEC speed problems (wired!)
#16
I'm feeling like an idiot, but i think the router is really the problem here.

My router (Fritz!Box 6360) has an "energy saving" option for the 4 LAN ports. You can manually set the speed of the port to 1 Gbit/s or 100 Mbit/s (to save energy, esp. if you only have a 100 Mbit/s device).

Obviously i had set the LAN port for my iMac to 1 Gbit/s. Due to the fact, that i don't have another 1 Gbit device, i couldn't test it so far. But back to topic: During further iperf tests between my iMac and my notebook i noticed that the iMac could download easily 90 Mbit/s from the notebook, but could only send 10-20 Mbit/s. After ruling out a software problem, i thought that the LAN port of my iMac must be damaged.

Well i don't know really why, but i played later a little bit with several options router and set all LAN ports to 100 Mbit/s and BOOM - speeds up to 90-95 Mbit/s!?! I changed it back to 1 Gbit/s and all the movies were stuttering again and i could reproduce the long mentioned speed problems. Changed it back again to 100 Mbit/s - everything worked fine again with 90-95 Mbit/s.

In summary: The 1 Gbit/s mode is f**ing everything up and this mess cost me 5 evenings. On the other hand: The Pi is flying again :-) I will exchange my router and will report if there is an improvement.

Thank you both for your help and patience!
Reply
#17
Good to hear you have a solution.
Reply
#18
Interesting discussion.
I've been pulling my hair out for a few weeks now trying to figure out why my RPi won't play my (raw) HD content (BluRay scrapes).

I've tried OpenELEC with NFS in the autostart.sh, NFS from within XBMC and CIFS from within XBMC.
I've tried streaming the same movies from my own PC (1Gbit, connected to the same switch as the server)
I've tried OpenELEC v3.2.4 and various Gotham alpha-builds (mostly alpha-10 through alpha-12) with various advancedsettings.xml tweaks (including 2-64MB cache).

No matter what I do the HD movies always stutter. They play fine for a while, then a few short (<1 sec) stutters and then a full freeze for 10-20 seconds. My setup is a bit different, but I could be having a similar problem since my "backbone" is 1Gbit.

My setup looks like this:

<100Mbit Router>-<PCs>
|
|
<1Gbit switch>-<RPi>
|
|
<1GBit switch>-<FreeNAS 9.2.0 Server> (Movies are streamed from here)

The server is plenty powerful (it can easilly saturate a 1GBit connection) so I've always suspected it's a problem in the RPi, but I never suspected the ethernet port itself. I've tried doing debug-logs but they reveal nothing about buffers running out. I've tried to run iperf over SSH, but it appears my current build (Millhouse Jan-27th) doesn't have it or something.

Any tips on how I might locate the problem?
Reply
#19
You can get iperf via the unofficial openelec repository http://wiki.openelec.tv/index.php/OpenEL...nofficial)
Reply
#20
Thanks for the help theowiesengrund.

I've done a lot of testing and found the solution (by accident actually).

I tested bandwidth both ways and found that my RPi could recieve TCP data at a pleasant 90Mbit/sec on one-direction transmissions and ~73Mbit/sec on simultaneous bi-directional transfers (iperf -d, with roughly 33Mbit/sec uploaded from the RPi).
I proceeded to test UDP bandwidth (my original NFS mounts used UDP so I thought "why not"). When I tested with 100Mbit/sec bandwidth (iperf -u -b 100m) I had about 6% packet-loss (that's a lot!) but if I lowered it to 90Mbit/sec (iperf -u -b 90m) I had zero packet-loss!

In my advancedsettings.xml I had the following lines:

Code:
<network>
    <cachemembuffersize>25165824</cachemembuffersize>
    <buffermode>1</buffermode>
    <limitcacherate>false</limitcacherate>
  </network>

24MB cache, buffer all sources and no limitations on network speed when buffering.

Well, with what I discovered when I did the UDP-test (the massive packet-loss) I replaced <limitcacherate>false</limitcacherate> with <readbufferfactor>1.8</readbufferfactor>.
This means that at worst, the buffer filling process should never use more than 90Mbit/sec (movie @ 50Mbit/sec * 1.8 = 90Mbit/sec cache fill-rate).

I've also reduced the cache to 16MB and movies load a lot faster now (3-4 seconds instead of ~20 seconds). I could try reducing the cache to 8MB but 16MB gives a ~2.5sec buffer at 50Mbit/sec, which I think is good to have.

I know it's not the same issue as the OP, I felt I had to share my findings so that others might benefit from my findings.
Reply
#21
If you're still using NFS, you could try OS mounts and specify tcp instead of udp. Though personally I'd be trying to identify the cause of the lost udp packets rather than reducing maximum throughput in an effort to avoid the problem (which may crop up elsewhere). Can you try a different router?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#22
(2014-01-30, 01:09)MilhouseVH Wrote: If you're still using NFS, you could try OS mounts and specify tcp instead of udp. Though personally I'd be trying to identify the cause of the lost udp packets rather than reducing maximum throughput in an effort to avoid the problem (which may crop up elsewhere). Can you try a different router?

I believe lost packets with udp is entirely normal when sending at a higher rate than the link supports. You'll get the same effect on any platform.
You can see this effect easily with iperf. Send at 200mbit/s udp over a 100mbit/s link and you'll get ~50% packet loss.

It's an interesting question if nfs over udp has the same issue.
My guess is that something in the nfs protocol will detect this and reduce the transmission rate, but I don't know for sure.

We do know that most people get better performance when copying files using nfs over udp than nfs over tcp/ip, so I'm not convinced this is an issue.
Reply
#23
(2014-01-30, 01:22)popcornmix Wrote: I believe lost packets with udp is entirely normal when sending at a higher rate than the link supports. You'll get the same effect on any platform.
You can see this effect easily with iperf. Send at 200mbit/s udp over a 100mbit/s link and you'll get ~50% packet loss.

I would have thought so too, but I've run tests with iperf between a Pi (client, Raspbian) and FreeNAS 8.x (server, HP Microserver N36L, Intel NIC) and saw no UDP packet loss even with -b 200m! I also tried different length datagrams (eg. -l 32k) and again no udp packet loss. This is with the client and server connected to a GigE switch. I really don't know why iperf isn't "losing" packets when sending 200Mb/s over a 100Mb/s link, although I wouldn't expect to see packet loss when the bandwidth is at or below the link speed, which is the OPs problem.

Code:
pi@raspberrypi ~ $ iperf -c 192.168.0.3 -t 60 -i 10 -u -b 200m
------------------------------------------------------------
Client connecting to 192.168.0.3, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.4 port 42129 connected with 192.168.0.3 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   114 MBytes  95.7 Mbits/sec
[  3] 10.0-20.0 sec   114 MBytes  95.6 Mbits/sec
[  3] 20.0-30.0 sec   114 MBytes  95.5 Mbits/sec
[  3] 30.0-40.0 sec   114 MBytes  95.6 Mbits/sec
[  3] 40.0-50.0 sec   114 MBytes  95.6 Mbits/sec
[  3]  0.0-60.0 sec   684 MBytes  95.6 Mbits/sec
[  3] Sent 487654 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec   684 MBytes  95.6 Mbits/sec   0.132 ms    0/487653 (0%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply

Logout Mark Read Team Forum Stats Members Help
OpenELEC speed problems (wired!)0