OpenPLi NFS opnames TEST workaround

[adri]

Milo,

 

Ik zag op git.opendreambox.org ook dat er updates zijn voor dreambox-dvb-modules.

Er zijn aanpassingen gemaakt voor 'better recording/playback/demux performance' op 28 mei 2010.

Op 6 juni 2010 zijn er nog een paar kleine aanpassingen doorgevoerd om onder andere de deinterlacer te fixen.

Misschien is het handig om deze versie ook op te nemen in OpenPli?

 

Adri.

 

[Oldfield]

Er komt geen overflow bericht langs als ik enigma met de hand start. Wel een hoop andere tekst overigens.

Heb je een advies voor een tooltje om het netwerkverkeer te meten? Op de QNAP draait nu alleen iets dat het totale dataverkeer meet, maar doet dat erg grof (een 24 uurs grafiek).

[Gast MiLo]

Als je geen OVERFLOW meldingen in de log ziet, dan is er geen probleem bij het wegschrijven van de data naar de NAS toe.

 

Dan blijven er nog twee mogelijkheden over: De (soft)cam/kaart en het afspelen.

 

Zitten de hikken in de opname zelf? Dus als je bijvoorbeeld met VLC op een PC afspeelt, hikt hij dan ook? En bij afspelen op de dreambox, zit een hik dan altijd op dezelfde plaats in de opname?

 

Als de hikken in de opname zitten, dan zou het probleem in de CAM moeten zitten, aangezien enigma2 het zou melden als hij de data niet snel genoeg naar het netwerk kan schrijven met een OVERFLOW melding. Probeer eens wat FTA zenders op te nemen (bijv. BBCHD en er zijn ook wat Duitse FTA HD zenders), en controleer of die wel hikloos kunnen worden opgenomen.

[Oldfield]

Ik heb je denk ik verkeerd begrepen: ik begrijp nu dat het de bedoeling is/was om te kijken of er Overflow berichten langs komen tijdens het maken van een opname. Zal dat zo even doen.

 

Het is niet CAM gerelateerd: ik test onder andere met Arte HD (FTA).

 

Zal ook even kijken of het een opneem- of afspeel probleem is.

[Oldfield]

Er verschijnt 'Overflow while recording' tijdens de opname.

Stotteren zit in de opname zelf - probleem zit steeds op dezelfde plaats. Klein stukje uit het log:

 

OVERFLOW while recording

TuxTxt: readerror

OVERFLOW while recording

OVERFLOW while recording

 

[Gast MiLo]

Ah, dan is dat in ieder geval helder dat hij de opname data niet snel genoeg weg kan schrijven.

 

Run onderstaand scriptje eens vanuit een telnet terwijl er een opname loopt (die hikt).

 

Code:

while truedo  echo "..."  cat /proc/meminfo  sleep 1done

 

(je kunt dit direct copy/pasten in je telnet window)

 

Let met name op de "dirty" en "writeback" pages, maar misschien valt je nog iets anders op.

 

Normaal gedrag:

- Writeback is meestal "0"

- "Dirty" loopt in 5 seconden op, tot enkele MBs

- Na 5s neemt "Dirty" snel af en is "writeback" af en toe niet 0

- Dirty "pingelt" zo op en neer, maar blijft beperkt tot enkele MBs (afhankelijk van aantal en aard van opnames).

 

 

[Erik Slagter]

Ik had trouwens een paar dagen geleden ook nog wat overflows bij kijken naar een opname van BBC HD en tegelijkertijd een opname vanaf RTL4 HD. Het is nog niet perfect dus, inderdaad.

[Oldfield]

Is de parameter NFS_unstable relevant en zo ja, wat zijn de normale waarden?

 

Wat is tot nu toe zie: op SD kanalen het gedrag zoals jij beschrijft (waarbij writeback bijna altijd nul is). Dirty wordt maximaal 7000kB.

 

Bij Arte HD loopt Dirty op tot rond de 8000kB en dan wordt NFS_unstable opeens ook ongeveer deze waarde (en dirty nul) om daarna weer nul te worden. Writeback zie ik nauwelijks veranderen.

 

Wordt hier de buffergrootte overschreden?

 

[Oldfield]

Ter aanvulling je script ook gedraaid op een dm800 met de OpenPLi versie van 25 maart: Hier significant ander gedrag: ik zie writeback even een lage waarde krijgen en dan vervolgens nul worden. Meer opmerkelijk is dat dirty tijdens de opname niet groter wordt dan 500kB (in tegenstelling tot ruim 8.000kB bij de nieuwe versie van OpenPLi).

De parameter NFS_Unstable ontbreekt in de oude versie.

[Gast MiLo]

Welke mount parameters zijn er bij jullie in gebruik? Met andere woorden, stuur de output van het "mount" commando eens.

 

Het gedrag dat je beschrijft lijkt op NFSv2, waar de client data moet opslaan tot de server meldt dat het goed is (sync i.p.v. async dus). Met een backlog van 8MB kan dat behoorlijk lastig zijn.

 

Citaat:

NFS_UNSTABLE: Data/Metadata was not committed to stable storage on the server, and must be cached on the client until a subsequent client commit request assures that the server does send data to stable storage.

 

In mijn test opstelling (server is een Ubuntu Linux machine in VM) heb ik NFS_unstable op de dreambox nooit zien oplopen.

 

Op zich is het nieuwe gedrag beter, want hij maakt efficienter gebruik van de cache, schrijft grotere blokken weg, en blokkeert niet als een device zelf geen cache heeft. Op harddisks en memorycards is de nieuwe versie merkbaar beter (met de oude versie kon je niet timeshiften op een CF kaart bijvoorbeeld, met de nieuwe werkt dat prima).

[Oldfield]

192.168.1.24:/DM800 on /media/net/hdd type nfs (rw,noatime,vers=3,rsize=32768,wsize=32768,hard,nolock,proto=tcp,timeo=70,retrans=3,sec=sys,addr=192.168.1.24)

 

 

De oude versie van OpenPli meldt dit:

192.168.1.24:DM800 on /media/hdd type nfs (rw,v3,rsize=8192,wsize=8192,hard,udp, nolock,addr=192.168.1.24)

 

 

AANVULLING:

ook nog even getest met deze settings:

192.168.1.24:/DM800 on /media/net/hdd type nfs (rw,noatime,vers=3,rsize=8192,wsize=8192,hard,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=192.168.1.24)

 

Zelfde probleem en gedrag met je script.

[Gast MiLo]

Probeer het vandaag nog eens, het gedrag zou nu overeen moeten komen met de "oude" versie. Ik kan de problemen niet echt reproduceren, maar ik kan wel zien dat hij nu heel weinig dirty pages overlaat.

[Oldfield]

Het schrijven is nu opgelost: dirty wordt niet groter dan 750kB en NFS_Unstable is permanent rond de 1100kB. Opnames zijn perfect, maar.....

 

Als ik tegelijk tijdens het opnemen de opname weer afspeel, dan zijn er nog wel storingen. Deze verstoringen komen niet uit de opname zelf, dus zit aan de afspeelkant.

Om uit te sluiten dat het aan mijn netwerk ligt, dit experiment gedaan: opnemen van een HD kanaal op de DM800 met OpenPLi van vandaag en tegelijk de opname afspelen op mijn DM800 met OpenPLi van maart. Dan geen problemen. Het lijkt er dus op dat er nog gedoe in het 'leesdeel' zit.

 

Heb ook nog even getest met wsize.rsize van 8192: geen verschillen. Nog suggesties voor andere instellingen?

[Oldfield]

aanvulling op mijn vorige bericht na wat testen met andere instellingen : met UDP zijn de problemen bij het tegelijk afspelen van een opname die wordt gemaakt significant kleiner dan TCP. UDP lijkt dus een betere performance te bieden. Probleem is er niet mee weg.

[Gast 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)?

 

Op mijn systeem was dit natuurlijk weer geen probleem, maar ik weet wel hoe ik dit kan verhelpen denk ik. Komt morgen of overmorgen nog iets voor.