Raspberry Pi geen 100Mbit

[Cidolfas]

Ik heb sinds een tijdje dat bij het kijken van films op mijn Raspberry Pi vanaf mijn NAS het beeld hapert. Soms gebeurd het een hele film niet, soms 2x tijdens een film.

Vandaag heb ik eens wat metingen verricht met iperf waarvan de output mij iets doet verbazen, ik hoop dat iemand er met een frisse blik naar kan kijken.

Eerst mijn setup:

Rasperry Pi -> ethernet -> GS105e switch -> ethernet -> WNDR3700 router -> ethernet -> NAS.

Mocht het relevant zijn (ik denk van niet), de GS105e switch trunked 2 vlans over 1 kabel voor LAN en IPTV.

Iperf server op mijn NAS, client de Pi:

code:

root@raspbmc:~# iperf -c 192.168.1.201 -p 5555 -t 60
------------------------------------------------------------
Client connecting to 192.168.1.201, TCP port 5555
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.202 port 57849 connected with 192.168.1.201 port 5555
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec   310 MBytes  43.4 Mbits/sec

Volgens mij is 43Mbits/sec net genoeg voor een full HD film, met dat idee kan ik er in komen dat het beeld af en toe vast loopt bij het kijken van een film.

Om de infrastructuur te testen heb ik ethernet kabel uit de Pi gehaald en in mijn laptop gestoken:

Iperf server op NAS, client op laptop (dezelfde kabel als de Pi):

code:

------------------------------------------------------------
Client connecting to 192.168.1.201, TCP port 5555
TCP window size:  129 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.183 port 65351 connected with 192.168.1.201 port 5555
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  5.25 GBytes   751 Mbits/sec

Kan beter, maar met die snelheid lijkt het streamen van een HD film geen enkel probleem. Dus mijn verdachte is de Pi zelf.

Puur voor een test heb ik de server eens op de Pi laten draaien en de NAS de client laten spelen met de verwachting weer rond de 40Mbits/sec te halen:

code:

------------------------------------------------------------
Client connecting to 192.168.1.202, TCP port 5555
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.201 port 57940 connected with 192.168.1.202 port 5555
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  47.9 MBytes  80.3 Mbits/sec

Een verdubbeling van snelheid!

Mijn vragen:

Kan iemand verklaren waarom de snelheid verdubbeld tussen upload/download?
Heeft iemand tips om de snelheid altijd rond de 80 Mbits/sec te krijgen?

[FatalError]

Je moet je wel even realiseren dat de netwerkchip in de rPi via USB 2.0 aangesloten is en de chip an sich al niet geweldig is. Daarnaast is de CPU van het beestje niet al te rap. Ik heb zelf ook al enorme verschillen in netwerksnelheid gezien tussen verschillende kernels voor de rPi. Blijkbaar wordt daar nog weleens aan gesleuteld. Maar het blijft natuurlijk een erg mager platform voor netwerkintensieve taken.

[swbr]

Ik weet niet precies wat de code van iperf doet, maar ik kan me zo voor stellen dat de server kant alleen een socket opent en alles wat daar op binnenkomt naar /dev/null doorsluist, terwijl de client daadwerkelijk een datastream moet genereren en de statistieken daarover moet berekenen. Aangezien het netwerk interface op je rpi via usb loopt, gaat de snelheid daarvan last hebben van zaken die cpu usage veroorzaken.

Als die gedachte klopt, dan is het niet het netwerk dat je bottleneck is, maar je cpu. Laat eens een top meedraaien op je rpi, zowel wanneer je die als client, als wanneer je die als server gebruikt. Zou me niets verbazen als je daar een fiks verschil in cpu belasting gaat zien.

[FatalError]

Daar noem je wat.. een TCP test in iperf is erg intensief voor de CPU als hij de ontvangende kant is van het verkeer. Doe voor de grap ook eens een UDP test. En laat bij de TCP test inderdaad even top mee lopen.

[Cidolfas]

De iperf trekt inderdaad de CPU dicht, die het toch al zwaar had met het xbmc.bin proces. Wel vreemd want ik heb het probleem niet altijd gehad.

Wellicht is het geïntroduceerd met een van die automatische updates van Raspbmc, ik zal eens kijken naar de configuratie files.

Bedankt tot zo ver, dan hoef ik mijn netwerk niet verder te verdenken

[laurens0619]

Schokken in beeld bij films wordt meestal veroorzaakt door een combinatie van gebruikte audio codec in een film met het type receiver wat aangesloten zit. (passthrough vs encoding)

Pi's blijven nu eenmaal niet de beste apparaten als mediaplayer

[Janoz]

Cidolfas schreef op donderdag 01 mei 2014 @ 12:38:
Volgens mij is 43Mbits/sec net genoeg voor een full HD film, met dat idee kan ik er in komen dat het beeld af en toe vast loopt bij het kijken van een film.

43.4 MBit/s komt neer op 19GB per uur. Dus tenzij je rips hebt van 2 uur durende films die 40GB of groter zijn denk ik niet dat je ook maar in de buurt komt van je bandbreedte beperking.

[FatalError]

Ja, maar dan zit de CPU dus al vol met het afhandelen van verkeer. Er is ook nog CPU capaciteit nodig voor het werkelijk weergeven van de film

[Ultraman]

Hangt ook nogal af van het gebruikte protocol. Via Windows sharing (Samba) schokt het dikwijls, terwijl ik het lang middels NFS heb gedaan wat prima werkte.
Het beste is een USB disk aan de Pi hangen en daar de films op zetten. Zo heb ik hier een 2TB WD 3.5" met eigen voeding aan mijn Pi hangen en films kopieer ik er naar toe over SSH of FTP. Gaat al anderhalf jaar uitstekend

Maar als je via het netwerk wilt, probeer het dan eerst een via NFS (of misschien FTP). NFS heeft minder overhead dan Samba en werkte hier destijds heel aardig.

[ Voor 17% gewijzigd door Ultraman op 01-05-2014 15:34 ]

[GioStyle]

Ik gebruik hier Windows Server 2012 met daarop Plex, bij de tv een Raspberry Pi met daarop Rasplex en heb totaal geen problemen qua netwerk.

Het enige 'gedoe' wat ik met de Raspberry heb is dat wanneer je een film kijkt met DTS dat er kans bestaat dat ie om de zoveel minuten moet gaan bufferen.

[Borromini]

Als je NFS gebruikt, check dan even je configuratie. Ik heb read en write size moeten wijzigen voor het netjes werkte op m'n Pi. Daarvoor kon ik muziek niet deftig streamen (en de bitrate van FLAC komt totaal niet in de buurt van video-rips).

Maar door de USB NIC (en de limitaties die dat met zich meebrengt qua belasting) is streaming inderdaad verre van ideaal op een RPi.

[Cidolfas]

Ik heb al eens geswitched tussen NFS en Samba, maar beide gaf hetzelfde probleem. Ik zit te denken om de buffers iets op te rekken als dat mogelijk is.

Het is zo zonde, eigenlijk werkt de Pi perfect als mediaspeler, op die ene hik in een film na..

[Janoz]

FatalError schreef op donderdag 01 mei 2014 @ 14:03:
Ja, maar dan zit de CPU dus al vol met het afhandelen van verkeer. Er is ook nog CPU capaciteit nodig voor het werkelijk weergeven van de film

Veel mensen overschatten schromelijk de nodige bandbreedte voor HD content. Dat is wat ik aan wil geven.

Voor het weergeven van de content heeft de Pi trouwens heel weinig CPU power nodig. De gebruikte chip is een media chip die zo krachtig is dat het generieke deel wat er toevallig nog bij zat krachtig genoeg is om als computertje gebruikt te worden. Het daadwerkelijk renderen van de (video) content doet hij met twee vingers in de neus. Downmixen van de audio kan daarentegen wel voor problemen zorgen (en ik vermoed dat dat hier eerder de boosdoener is)

[LnC]

Ultraman schreef op donderdag 01 mei 2014 @ 15:33:
Hangt ook nogal af van het gebruikte protocol. Via Windows sharing (Samba) schokt het dikwijls, terwijl ik het lang middels NFS heb gedaan wat prima werkte.
Het beste is een USB disk aan de Pi hangen en daar de films op zetten. Zo heb ik hier een 2TB WD 3.5" met eigen voeding aan mijn Pi hangen en films kopieer ik er naar toe over SSH of FTP. Gaat al anderhalf jaar uitstekend

Maar als je via het netwerk wilt, probeer het dan eerst een via NFS (of misschien FTP). NFS heeft minder overhead dan Samba en werkte hier destijds heel aardig.

Raar, want mijn Pi staat in verbinding met mijn pc boven d.m.v. Samba. Is het ook mogelijk dat het kan liggen aan welke versie je van een mediaportal je gebruikt? Ik gebruik OpenElec en heeb geen problemen met haperingen of hicups.

[Ultraman]

LnC schreef op vrijdag 02 mei 2014 @ 12:55:
[...]


Raar, want mijn Pi staat in verbinding met mijn pc boven d.m.v. Samba. Is het ook mogelijk dat het kan liggen aan welke versie je van een mediaportal je gebruikt? Ik gebruik OpenElec en heeb geen problemen met haperingen of hicups.

Die ervaring is meer dan een jaar geleden, sindsdien gebruik ik een USB harddisk. In die tijd zijn er meerdere verbeteringen doorgevoerd. NFS gebruikt wel nog steeds minder resources dan Samba, maar inmiddels is laatstgenoemde dus wel degelijk bruikbaar begrijp ik uit jouw woorden