OpenPLi NFS opnames TEST workaround

[Oldfield]

Origineel bericht van: MiLo

Je krijg nu alleen nog gestotter als je een _lopende_ opname afspeelt, en dus niet als je een opname afspeelt die al gereed is (terwijl er nog opnames lopen)?

Dat is na wat testen precies wat ik zie.

Ik ben overigens zeer onder de indruk van de manier waarop je je in dit soort lastige problemen vastbijt. Compliment!

Heb jij (of één van de andere protocol-deskundigen) nog een opvatting over de geconstateerde performanceverschillen tussen UDP en TCP en wat is de opvatting over de optimale block size?
Vind het zelf vreemd dat UDP beter lijkt te werken dan TCP

[Gast MiLo]

Morgen nog eens testen dan, ik het zojuist m'n fix ingevoerd.

 

Wat betreft UDP/TCP, meestal performt TCP beter, niet voor niets is TCP de default geworden in de latere versies. TCP kan ook gebruik maken van accelleratie functies van de netwerk kaart (nou zal die van de dreambox dat wel niet hebben, maar je NAS misschien wel), met UDP kan dat niet. En TCP onderhandelt met de ontvanger over van alles en nogwat.

 

In dit specifieke geval werkte het timeshiften met UDP waarschijnlijk beter omdat die een andere timing heeft. Lastig uit te leggen zonder een goed glas wijn erbij...

[Oldfield]

Het is dat je zo ver weg woont, anders was het interessant om het er een keer over te hebben (en er ééntje te drinken).

 

Je fix van gisteren / vannacht heeft het probleem niet opgelost. Getest met zowel UDP als TCP.

[Gast MiLo]

En morgen weer een nieuwe poging, heb weer wat aangepast

 

Met 5 gelijktijdige HD opnames kreeg ik ook wat stotter op de VU bij het afspelen, met deze wijzigingen is dat effect verdwenen.

 

Wat betreft TCP/UDP, het lijkt erop dat op de 800 UDP beter loopt (vermoedelijk bug in de netwerk driver van de 800). Op de boxen die ik hier heb (8000, 7025, VU+Duo) is er niet echt verschil in performance of CPU gebruik tussen TCP en UDP.

[Oldfield]

Afspelen tijdens opnemen is een stuk verbeterd, maar werkt nog niet zoals de oude versie deed. Kan je nog eens aan wat knoppen draaien?

 

Opnames doen het echt super: 4 HD kanalen (ned1-rtl4,discovery en ngc) tegelijk opnemen gaat zonder enige rimpel. Ook de HD kanalen met hoge bit rates doen het prima.

 

Vandaag ook uitgebreid getest met TCP en UDP en verschillende block sizes. Op een DM800 is UDP met block size 8192 het snelst. De time-out parameters lijken weinig invloed op de performance te hebben.

 

Het lijkt er overigens op dat een opname die direct wordt afgespeeld (dus met een vertraging van ongeveer 20 seconde) het slechter doet dan wanneer de achterstand groter is. Kan dit echter niet consequent reproduceren. Wellicht kan je er iets mee?

[Gast MiLo]

Origineel bericht van: Oldfield

...Kan je nog eens aan wat knoppen draaien?

Mja, ik ben nog niet uitgedraaid. Voor deze wijzigingen kon de 7025 namelijk BBC-HD op een USB stick opnemen (de 7025 heeft een trage USB 1.1 poort), dat gaat nu weer minder soepel.

Grotere achterstand laat hem nu inderdaad soepeler lopen. Zodra je meer dan 2 MB achterloopt (is afhankelijk van de bitrate hoeveel seconden dat is) zou het beter moeten gaan.

[Erik Slagter]

Origineel bericht van: Oldfield

Heb jij (of één van de andere protocol-deskundigen) nog een opvatting over de geconstateerde performanceverschillen tussen UDP en TCP en wat is de opvatting over de optimale block size? Vind het zelf vreemd dat UDP beter lijkt te werken dan TCP

Ik heb een paar dagen geleden nog uitgebreid getest met NFS op een dm800 (omdat die de meeste problemen heeft).

Daar kwam in ieder geval uit dat (inderdaad) UDP veel beter performt dan TCP (met NFS dan). Ik vermoed dat dat te maken heeft met dat NFS heel lang alleen op UDP is geimplementeerd is geweest en dat de TCP-implementatie gewoon nooit zo geoptimaliseerd is geworden.

Dit alles geldt voor als je een bedraad netwerk heb. Met een draadloos netwerk raak je regelmatig packets (c.q. fragments) kwijt wat de performance heel sterk beinvloed. Ik heb even getest met een read/writesize van 1024, waardoor de UDP packets niet gefragmenteerd hoeven te worden, maar dan houd je helemaal geen performance meer over. Mijn advies dus: gebruik UDP (rw-size is default 32768) op een bedraad lan en TCP (ook default rw-size) op een draadloos netwerk.

Als je de exacte waarden wilt weten geef je maar even een gil, dan stuur ik je de url van de thread waarin het besproken wordt.

[Erik Slagter]

Origineel bericht van: Oldfield

Het lijkt er overigens op dat een opname die direct wordt afgespeeld (dus met een vertraging van ongeveer 20 seconde) het slechter doet dan wanneer de achterstand groter is. Kan dit echter niet consequent reproduceren. Wellicht kan je er iets mee?

Dat is inderdaad verklaarbaar ;-)

Ik zou de komende tijd zeer regelmatig updaten en uitproberen!

[Oldfield]

Beste Eric,

 

Bedankt voor je toelichting op de UDP/TCP kwestie. Voor TCP kan ik op een DM800 met OpenPLi blocksizes kiezen tussen 2K en 32K, voor UDP kan je ook dezelfde range opgeven, maar alleen 2k,4k en max 8k worden effectief gebruikt.

 

Ben wel benieuwd naar de verklaring voor het feit dat een opname meer problemen geeft bij afspelen als de 'achterstand' kleiner is.

 

Groet, Nico.

[Gast MiLo]

E2 "pusht" nu actief file data uit de cache, zodat die sneller naar NFS wordt geschreven (anders zit de kernel 5 seconden uit z'n neus te eten en gaat dan als een gek proberen de achterstand in te halen). Dat zat namelijk ook in de oude versie, maar dit werkte toen niet op de nieuwe kernel.

 

Als je timeshift, dan heb je kans dat die "push" actie de data voor de opname als het ware onder de neus van de afspeelbuffer wordt weggekaapt, en dus moet die weer opnieuw via NFS verzonden worden, waarbij die write request nog extra in de weg zit.

Als je verder weg zit met de timeshift, dan is die data toch allang weg naar de NFS server en wordt hij niet meer weggekaapt.

 

NB: Op een 8000 of VU+ is de default NFS TCP buffer 256k. Op de 7025 was die aanzienlijk lager. Aangezien de 800 net zoveel RAM heeft als de 8000, zou ik ook verwachten dat die 256k kiest. Maar dat kan ook aan de server liggen.

[Erik Slagter]

Origineel bericht van: Oldfield

Voor TCP kan ik op een DM800 met OpenPLi blocksizes kiezen tussen 2K en 32K, voor UDP kan je ook dezelfde range opgeven, maar alleen 2k,4k en max 8k worden effectief gebruikt.

Als je geen rwsize aangeeft (wat we aanraden), dan neemt de linux kernel voor tcp 256k en voor udp 32k. Dat zijn imho optimale waardes. Ik zou niet lager gaan zitten dan 32k. Met nog wel mijn opmerking over tcp/udp vs. bedraad/draadloos in gedachten uiteraard.

Origineel bericht van: Oldfield

Ben wel benieuwd naar de verklaring voor het feit dat een opname meer problemen geeft bij afspelen als de 'achterstand' kleiner is.

Zie tekst MiLo met als toevoeging dat het netto effect momenteel per dag kan verschillen, aangezien er nogal wat getest wordt en er soms per dag dingen gefine-tuned worden, met als uiteindelijk doel dat er helemaal niks meer "overflowed", oftewel, geen hiks meer. Bij BBC HD is het nog steeds wel eens mis.

[Oldfield]

 

Als je geen rwsize aangeeft (wat we aanraden), dan neemt de linux kernel voor tcp 256k en voor udp 32k. Dat zijn imho optimale waardes. Ik zou niet lager gaan zitten dan 32k. Met nog wel mijn opmerking over tcp/udp vs. bedraad/draadloos in gedachten uiteraard.

 

Beste Eric,

 

Ik zie toch echt andere waarden: TCP kiest default 32K, UDP 8K (en kan ook niet hoger worden geforceerd)

[Gast MiLo]

Dan is dat wat je NFS server heeft ingesteld.

 

(Bij mij is dat een VM PC, die heeft geheugen zat)

[Erik Slagter]

Yep. Bij mij is het een linux (vanilla) server.

 

Het betreffende nas heeft waarschijnlijk een heel oude linux kernel, dat zie je vaak.

[Gast satmus]

 

DM800, vandaag geupgrade naar openpli en ook hier problemen met nfs en timeshift. Getest met Eurosport HD. Alle settings in deze thread geprobeerd, niets helpt. De defaults geven nog het beste resultaat. Met vorige PLI image van ongeveer 2 jaar oud geen problemen (moest wel TCP forceren).

 

NFS_Unstable gaat op en neer van 0 tot ongeveer 800 kb.

 

10.x.x.x:/disk/vid/media on /media/hdd type nfs (rw,vers=3,rsize=32768,wsize=32768,hard,nolock,proto=tcp,timeo=70,retrans=3,sec=sys,addr=10.x.x.x)

 

NFS Server is PC (AMD Athlon 4850e dual core) met RHEL5. Netwerk bedraad 1Gb switch, dm800 uiteraard 100Mb