60 replies to this topic

[anudanan]

Ich habs gefunden,anstatt defaults müßte defaults,nodelalloc in der fstab stehen. Muss im mal probieren, wenn de Boxen mal Aufnahmepause haben

[betacentauri]

Ja, müsste so richtig sein. Berichte gerne ob es irgendwelche Probleme gibt. Wenn nicht, könnten wir das vielleicht als Default einstellen.

[anudanan]

Wird  wohl noch bis nach Weihnachten dauern, bis ich das umstelle. Meine Frau hat unsere Boxen mit Timern zugepflastert

[anudanan]

Ich habe mal ein wenig gelesen, was das delalloc genau macht und bin zu der Erkenntnis gelangt, dass das für einen Receiver keine nennenswerten Performancevorteile bieten sollte. Bei delalloc werden die Platten-Blöcke erst allokiert, wenn die Daten wirklich auf die Platte gehen, also nach dem Durchlaufen der Puffer im Kernel. Bei nodelalloc passiert das schon. wenn vom Userspace in den Kernelspace gegangen wird, also beim write(). Da bei dem Receiver die Daten eh alle auf die HDD sollen, muss diese Allokierung ja eh gemacht werden und die Arbeit fällt auf jeden Fall an, bei nodelalloc dann nur etwas früher. Ich denke, das sollte dann keine Nachteile bringen. Bei EXT2/3 gabs das damals auch nicht. Ich habe heute abend doch um 20:30 die Möglichkeit, meine HDD mit nodelalloc zu mounten und werden dann beobachten, ob der freie Platz dann bei df und du gleich ist und nicht  mehr auseinanderläuft und natürlich schauen, ob es andere Nachteile gibt.

 

ich tippe aber, dass alleine durch die großen 256K Cluster mit bigalloc die Verwaltung der Blöcke schon so schlank ist, dass es keine Nachteile geben wird.

 

Werde dann berichten, was daraus gekommen ist.

Edited by anudanan, 23 December 2017 - 15:43.

[anudanan]

Habe jetzt auf nodelalloc umgestellt und erst noch ein paar Performancetest gemacht

 

Habe intern eine 2TB 2,5 HDD

aus einem Ordner habe ich in Summe 48 GByte in einen anderen Ordner auf der gleichen Platte kopiert. Das sind ja die großen *,ts und die anderen kleinen Dateien.

Auf der HDD wird dann gelesen und geschrieben

• nodelalloc: Kopieren dauerte 20m 12s, nach dem Löschen der kopierten Dateien war du und df immer noch synchron
• delalloc:  Kopieren dauerte 29m 29s, also länger. Nach dem Löschen war schon wieder eine Differenz zwischen du und df

 

Dann habe ich von einer anderen HDD auf diese interen HDD 11,GByte kopiert. die interne HDD musste dann also nur schreiben

• nodelalloc: Kopieren dauerte 3m 40s
• delalloc: Kopieren dauerte 3m 35s, also nur minimal schneller

Ich denke damit sieht es eher so aus, dass das nodelalloc keine Performancenachteile bringt, aber richtig zählt.

 

ich lasse das jetzt mal so und schaue dann in ein paar Tagen mal nach, nachdem wieder einige Aufnahmen gelaufen sind, geschnitten wurden und verschoben wurden, wie der Speicherplatz mit du und df aussieht. Das wäre dann vielleicht wirklich bis zum echten Fix wirklich ein guter workaround, wobei vermutlich nodelalloc auch später so bleiben könnte, wenn der Fix da ist.

[anudanan]

Bisher sieht es gut aus. du und df zeigen den gleichen belegten HDD Platz an mit nodelalloc als Mount Option

 

Ich hatte zwar gestern abend mal einen kompletten Absturz der uno 4kSE, die ist um 20:15 einfach komplett stehen geblieben. Wir waren nicht zuhause, aber Aufnahmen liefen. als wir nach hause kamen, stand die Uhrzeit auf dem Display auf 20:15 Auch ping auf die IP ging nicht mehr. Habe die dann neu gestartet, Ich glaube aber nicht, dass das mit dem nodelalloc zu tun hat. Meine alte et8000 hatte sowas auch gelegentlich mal. Da scheint noch irgendwas im Linuxkernel bzw Gerätetreiber so schief zu laufen, dass das ganze UNIX steht.

Edited by anudanan, 25 December 2017 - 13:59.

[anudanan]

Gestern um Mitternacht liefen einige Aufnahmen von der Hauptbox im Wohnzimmer und der Box im Schalfzimmer auf die interne HDD in der Wohnzimmerbox. Meine Frau hat Schnittaufträge beauftragt und auch noch Filme von der internen HDD auf ein NAS geschoben. Das hat bei der et8000 immer ganz gut funktioniert. In den Aufnahmen, die gestern zu der Zeit, wo die Schnitte gemacht wurden und Verschiebungen von Filmen stattfanden, waren Störungen vorhanden. Ob das jetzt mit dem nodelalloc zu tun hat oder einfach nicht geht, kann ich noch nicht einschätzen. Ich beobachte das weiter.

[anudanan]

Ich habe jetzt erstmal wieder auf default zurückgestellt. Folgendes habe ich in einem anderen Thread angemerkt. Ich kann man das alles noch nicht erklären, aber beim Filme Schneiden und auch Verschieben auf andere NAS Systeme mach die Uno4k SE sehr oft Gedenkpausen. Da wird die Ergebnisdatei von mcut (moviecut) sekundenlang nicht größer und auch das Verschieben auf ein NAS läuft nur schleppend. Ich habe den Eindruck, es wird schlimmer, je länger die Box läuft. Vielleicht hängt das auch mit diesem Bug hier zusammen, denn die Differenz zwischen df und du wird ja auch immer größer

 

Ich kann leider auf der UNO4kSE kein OpenPLI 4 ausprobieren, ob das damit besser klappt. Damit hat es mit der ET8000 immer sehr gut funktioniert und da gab es auch das df,du Problem nicht

 

Wäre es möglich, dass die Uno4Kse auch ein openpli4 bekommt? Für die UNO4K gibt es da ja und da ist ja fast alles gleich, außer die Einbaumöglichkeit der HDD und das Display

 

Hier noch der Link auf den anderen Thread wegen des langsamen moviecut

 

https://forums.openp...sometimes-slow/

[anudanan]

tritt das BigAlloc Problem mit allen Clustern größer 4K auf. OpenPLI macht ja 256K. wenn es z.b. mit 64K, 32K, 16K, 8K nicht auftritt, würde ich meine Formatierung nochmal umstellen

[betacentauri]

Das kann ich dir im Moment nicht beantworten, da ich es nicht getestet habe. Ich vermute aber, dass das Problem auch damit auftritt.

[anudanan]

nodelalloc scheint das Problem nicht komplett zu lösen. Aber es macht die Sache auf jeden Fall besser.
Zu Performancenachteilen kann ich nichts sagen. Theoretisch müsste es welche geben, aber ob die auf unseren Boxen spürbar sind, weiß ich nicht. Ich denke eher nicht.

Ich befürchte, dass es erstmal nur für den aktuellen Kernel 4.15 oder höher einen Fix geben wird. Hoffentlich können wir den auf ältere Kernel rückportieren.

Ich versuch hier im Thread was zu schreiben, wenn es Neuigkeiten gibt. Ich hoffe ich vergesse es nicht.

Some interessting information about the linux Kernel version on the openpli 6.1 with uno4kse  Until now I thought the Kernel is version 3.14, but today I´ve seen also openpli use like VTI the kernel 4.1.20. 

 

root@Schlafzimmer:/var/volatile/log# cat /proc/version

Linux version 4.1.20-1.9 (build@bouwserver2) (gcc version 6.2.0 (GCC) ) #2 SMP Tue Dec 19 01:32:18 CET 2017

root@Schlafzimmer:/var/volatile/log#

[anudanan]

Da bei uns die Receiver immer laufen, werde ich mir bis zum Bugfix für die Platte, wo viel aufgenommen, gelöscht und verschoben wird, mal einen Cronjob Eintrag machen, wo ich kurz ein umount und dann wieder ein mount probiere. Wenn auf der Platte gearbeitet wird, schlägt das umount ja fehl

 

if umount $1

then

echo umount $1, now mount $1

mount $1

fi

 

Das lasse ich dann mal alle paar Stunden ausführen auf /media/hdd bzw /media/usbhdd

[betacentauri]

Musst mal schauen, ob das überhaupt geht. Hängt davon ab, ob E2 oder ein anderer Prozess auf irgendwelche Dateien auf der Platte zugreift.
Das scheint recht häufig der Fall zu sein. Hab jedenfalls schon häufiger gelesen, dass User Probleme hatten die Platte unzumounten.

[anudanan]

Ja, das kenne ich, auch wenn keine Aufnahme läuft und auch keiner etwas aufgenommenes schaut, geht oft umount nicht, aber einige Minuten später dann doch. Habe auch keine Ahnung, wer da gerade auf der HDD steht. Ich probiere es einfach mal. Irgendein umount wird hoffentlich mal klappen ;-)

Edited by anudanan, 3 January 2018 - 16:19.

[anudanan]

Vielleicht probiere ich doch auch nochmal nodelalloc aus. Ich habe ja die ganzen Performanceprobleme bisher am Ende eher auf die interne HDD geschoben, also entweder die HDD selber oder aber die SATA Schnittstelle. Heute Abend teste ich diese interne 2,5 Zoll Platte in einem externen Gehäuse mit USB3.0. Mit einer anderen 3,5 Zoll tut das hervorragend, kein Vergleich zu  dem Erlebnis mit der internen Platte.

 

Wenn die am USB auch viel besser tut, dann liegt es irgendwie an der Unterstützung der internen SATA Schnittstelle bei dem BCM 7252S der uno4kSE

 

Dann würde ich auch das nodelalloc nochmal testen.

Edited by anudanan, 3 January 2018 - 16:48.

[anudanan]

Ich habe das mit dem nodelalloc heute mal kurz bei den performancetests benutzt und habe keinen Unterschied feststellen können. Aktuell lasse ich es bei meiner 3,5 Zoll Platte aber delalloc. Vielleicht stelle ich das später mal um, wenn wir mehr Erfahrung mit Box und dem Schneiden usw haben , was die Aussetzer in Aufnahmen angeht

[Pike_Bishop]

 

Das scheint recht häufig der Fall zu sein. Hab jedenfalls schon häufiger gelesen, dass User Probleme hatten die Platte unzumounten.

 

Das is wahr, es is sogar eher die Regel das nicht umountet werden kann bei ner Internen Platte.

 

 

Grüsse

Biki3

[anudanan]

Zum Thema nodelalloc habe ich noch was getestet, da ich ja auch das Speicherzählproblem habe, aber im Grunde noch ein viel massiveres Performanceproblem mit der HDD hatte.

 

Erstmal zu Historie nochmal, ich mache dazu jetzt hier keinen neuen Thread auf. Ich werde das nochmal in englisch im passenden Thread MoveCut sometimes slow von mir erläutern.

 

Ich bin einen großen Schritt weiter in meinen ganzen Untersuchungen, warum die uno4kse und vermutlich auch andere Boxen immer so eine schlechte Performance haben, wenn man parallel viele Filme aufzeichnet, dann eine Schneidequeue mit MovieCut betreibt und noch Filme verschiebt (bei mir mit EMC und letztendlich dem Linux mv Kommand). Das war bisher bei der uno4kse nicht zu machen. Ständig gab es Aussetzer in den Aufzeichnungen, die Box war nur träge zu bedienen. Das scheint immer dann zu passieren, wenn neben vielen Schreibevorgängen auch noch Prozesse sehr viel lesen wollen (mcut, mv)

 

Insbesondere, wenn man im Filmmanager ( EM oder den eingebauten im openPLI) sich mit der Markierung auf einer Filmdatei befindet, in die gerade geschrieben wird, sich also vergrössert, habe ich sehr oft den Spinner gesehen, bis die Dateigröße angezeigt wurde. Das kenne ich von meinen älteren Boxen auch schon. Das Linux tool TOP zeigt dann auch immer an, dass die CPU Kerne sich fast nur noch im I/O befinden, obwohl die Gesamt-Transferrate zu der HDD teilweise zum Erliegen gekommen ist oder nur ein paar MByte/s beträgt und dann mal wieder hochgeht. Das hat mir keine Ruhe gelassen, weil ich einfach nicht eingesehen habe, dass diese modernen Maschinen das nicht besser hinbekommen können. Die notwendige Transferrate zur hdd für obige Aufträge sollten die eigentlich hinbekommen und insbesondere müssen ja die Aufnahmen verlustfrei geben. Die Restleistung der Box darf dann auf Schneiden und Verschieben gehen, aber nicht umgekehrt. Bisher wurden die Aufnahmen letztendlich von den anderen Schneide- und Verschiebeprozessen verdrängt.

 

Nach vielen Versuchen mit openpli, openatv, VTI kam das Ergebnis raus, dass die alle das gleiche Problem haben. Alle setzen auch auf Linux 4.1.20 auf.

Auch Versuche mit größeren Clustern auf der Platte, verschiedenen Mount Optionen, dem Verwenden von dem nice Kommando für mcut/mv haben alle keine echte Verbesserung geschafft.

 

Dann habe ich mich mit dem I/O Scheduler für die Block Devices, also die Platten geschäftigt.

 

Der im Kern eingebaute Scheduler kann drei Betriebarten, NOOP, deadline, cfq

https://www.thomas-k...x_I/O_Scheduler

 

Default ist cfq, der aber scheinbar mit der Applikation als Receiver nicht wirklich gut klar kommt, weil er jeder Applikation die gleich Zeit zukommen läst, unabhängig vom Datenaufkommen.

 

Ich habe dann mal deadline ausprobiert, kann man ganz einfach im Betrieb umstellen mit

 

echo deadline > /sys/block/sdx/queue/scheduler

sdx ist dann das passenden hdd interface, meist sda. Bei mehreren Platten muss das für jede eingestellt werden

 

Anzeigen der Einstellung geht mit

cat /sys/block/sd*/queue/scheduler

 

Die Wirkung was dramatisch. Die CPU-Core Load geht drastisch im I/O Bereich zurück. Die hdd zeigt vernünftige Durchsatzraten. Die Wartezeiten bei der Anzeige der Dateigrößen im Filmmanager sind weg. Überhaupt ist die Bedienung bei viel Plattenlast einfach wieder vernünftig flüssig.

 

Habe dazu nochmal 14 Aufzeichungen gemacht, parallel Filme geschnitten und Filme verschoben. Nun ist es so, wie erwartet. Die Aufzeichnungen bekommen ihre Daten auf die hdd geschrieben und die anderen Aufträge kommen auch noch dran, bekommen aber dann halt die Restleitung, was ja ok ist. Wenn nicht aufgezeichnet wird, geht Schneiden/Verschieben natürlich schneller

 

Bei dieser ganzen Aktion habe ich auch nochmal die mount option nodelalloc ausprobiert und die geht damit auch problemlos und damit ist es Workaround für das falsche Zählen des freien Plattenplatzes machbar.

 

Für mich gibt es damit folgende Empfehlung, die ich an das openpli Team weitergeben möchte

 

nodelalloc als mount Option kann eingebaut werden., Ich habe es in die fstab aufgenommen bei mir

der i/o Scheduler sollte von cfq auf deadline umgestellt werden. Entweder irgendwie im Kernelbau umstellen der nachträglich bei den startscripten der Userlevel (3-5) aufnehmen mit

echo deadline >/sys/block/..... (wie oben geschrieben)

 

Für mich war die Box nach diese Änderung nicht mehr wiederzuerkennen. Bin mal gespannt was meine Frau dazu sagen wird, die hat das noch nicht probiert, ist aber bei diejenige, die hauptsächlich die Box in dieser Hinsicht fordert.

Wer das auch mal probieren will, kanns gerne machen und Feedback geben, am besten dann im Thread im englischen Teil über moviecut sometimes slow

[Pike_Bishop]

Hi anudanan,

 

Da hast dich ja ordentlich ins Zeug gelegt, klingt auch super deine Lösung

Hab hier zwar solche Probleme an der Ultimo 4k noch nicht festgestellt die hat aber ja auch noch Kernel 3.14.28 wo es auch das Problem mit bigalloc

in Verbindung mit der Speicherplatzanzeige ja noch nicht gibt.

Aber die wird ja auch mal nen 4er Kernel bekommen und dann is das hier alles gut zu wissen.

 

 

Grüsse

Biki3

Edited by Biki3, 11 January 2018 - 21:13.

[anudanan]

Ich bin fast verzweifelt bei der ganze Performancethematik, da die uno4kse ja nicht schlechter als die et8000 sein sollte, aber es definitiv so war.  Machst du mit der Ultimo 4K auch solche Schneideaktionen mit mcut und Verschiebeaktionen gleichzeitig? Wenn ja, tut das bei dir problemlos? Wäre ja mal interessant zu wissen, ob die I/O Auslastung deiner 4 Kerne da eher mittel oder auch richtig hoch ist

 

Habe heute nochmal von einer remoten Box 9 Aufnahmen auf die HDD der localen Box gemacht, die selber 5 Aufnahmen machte. Ging super.

Da habe ich jetzt aber erstmal nicht parallel geschnitten oder verschoben. Den Test spare ich mir für später auf.

 

In dem englischen Thread wurde noch ein besserer Scheduler  BFQ erwähnt, der aber in dem Kernel aktuell hier nicht enthalten ist. Der wäre auch mal interessant zu testen.Vielleicht portiert das Team den noch zurück

Edited by anudanan, 11 January 2018 - 21:57.