Ich habe seit Anfang Dezember zwei uno4kse und meine Frau nutzt die Geräte sehr intensiv mit vielen parallelen Aufnahmen auf die interne HDD (seagate baracuda 2TB).
Vorher hatten wir zwei ET8000, die mit openpli gelaufen sind. Diese Boxen hatten aber Problem mit der Ethernetschnittstelle, daher der Wechsel zur uno4kse.

Die HDD Performance bei mehreren gleichzeitigen Aufnahmen, parallelem Moviecut und parallelem Verschieben auf ein NAS Sstem ist extrem schlecht. Anstatt 30-50Mbyte/s zu schreiben (Lesen muss die ja auch noch), schreibt die Box da oft nur ein paar MByte/s auf die interne HDD und daher sind die Aufnahmen dann gestört. Die Bedienung auf der GUI ist dann ebenfalls eine sehr schleppende Sache. Das ging mit der et8000 damals mit openpli alles geht gut, obwohl die uno4kse von der HW leistungsfähiger als die et8000 sein müßte (die hatten einen MIPS dualcore 1,5Ghz)

Nach langem Probieren mit openpli und VTI auf der uno4kse bin ich davon überzeugt, dass der Treiber für den internen SATA Port die Ursache für dieses Performanceproblem ist. Wenn ich eine externe USB3.0 HDD an die uno4kse hänge und diese anstatt der internen HDD nutze für die oben genannten Aufgaben, klappt das wieder problemlos und die Performance stimmt.

die interne ist mit SATA-III angeschlossen und macht auch mit hdparm -t 130-150 Mbtye/s. Daher sollten 30-50 Mbyte/s ja auch gehen, wenn man liest und schreibt.


Bei der SoC Ausstattung sollte das alles kein Problem sein und war es bei der ET8000 auch nicht. Außerdem funktioniert es mit der externen USB-HDD auch bei der uno4kse. Warum soll es auch nicht gleichzeitig gehen? Ein User, der viel aufzeichnet, will gar nicht darauf achten, wann er schneidet und verschiebt. Das sollte bei der CPU Leistung alles gehen.

Dass das Schreiben auf wenige MByte/s zusammenfällt, nur weil man liest und schreibt zur gleichen Zeit, ist nicht logisch.

Meiner Meinung nach ein dicker Bug und ich glaube, das werden noch andere User bemerken, die Box ist ja noch neu. Die bisherigen uno4k Benutzer haben das Problem ja nicht, die verwenden ja immer USB.

Vor vielen Jahren, also die SoC noch weniger leistungsfähig waren, ging das alles nicht, aber mit dem modernen SoCs sollte das gehen.

Ach ja, es war als filesystem EXT4, einmal mit 4K Cluster und einmal mit 256K Cluster formatiert. Ging beides nicht gut. Mit USB klappt es wunderbar

Ich bin hier immer noch nicht weiter, habe aber mal einen Vergleich gemacht zwischen meiner alten XTREND ET9200 mit 2x400Mhz MIPS Core und der uno4kSE mit 2x1700Mhz ARM core

Beide boxen haben gleichzeitig den Auftrag bekommen, auf vergleichbaren internen Platten (SATA) den gleichen Film mit MovieCut zu schneilden.

Resultat war:
beide Boxen waren gleich schnell fertig.
Die ET9200 hatte laut top Kommandos auf der CLI nur 8-16% I/O Last gehabt
Die uno4kse hate laut TOP eine I/O Last von 50-95%, was viel mehr ist und ich das nicht wirklich glauben kann, da der BCM7252S viel moderner als der BCM7405 in der ET9200 ist.

Ich habe den Eindruck, bei dem I/O Treiber stimmt irgendwas nicht. Wenn das alles per DMA läuft und laut DMESG sind auf beiden Boxen die SATA Platten im DMA Betrieb, dann sollte auch die uno4kse da nicht die CPU nur im I/O Code stecken haben, wenn das der deutlich kleinere Prozessor auch schafft.

Für mich sieht das Ganze nicht korrekt aus und müßte deutlich besser gehen, insbesonderewo es auch die ET8000 (Nachfolger der et9200), die ich als Garantiefall zurückgegeben habe (Ethernet defekt), das ebenfalls alles viel besser hinbekommen hat. Dort war auch noch ein MIPS mit 2x1500 Mhz drin

Vielleicht ist ja irgendwas bei der ARM Treibergeschichte für die hdds nicht effizient entwickelt worden, aber das kann vermutlich nur VU+ oder Broadcom sagen, wo die Treiber ja vermutlich herkommen.

Ich finde das so sehr unbefriedigend. Eine moderne Box mit FBC Tuner scheint es nur mit ARM zu geben und überall wird ja auch damit geworben, wie leistungsfähig diese Maschinen sind. Aber wenn die Leistung nicht auf die Strasse kommt, dann sind diese Boxen damit nicht wirklich besser als die älteren.
Hat hier sonst keiner das Problem?

Meine Frau zeichnet recht viel auf und schneidet dann auch einfach zwischendurch und verschiebt auch Dinge. Für ist es einfach nicht zeitgemäß, wenn eine moderne Box das nicht mehr kann, wo es eine ältere ET8000 doch konnte.

Ich vermute aktuell, dass das mit jeder ARM Box so ist.

Wird nicht wieder vorkommen, sorry.

Das klingt ja ok. Bei der Solo4k ist glaube ich noch ein anderer Kernel (3.14) darunter als bei der uno4kse (4.1.20). Der Prozessor der uno4kse sollte eigentlich sogar etwas schneller sein und nicht langsamer

Ist alles sehr merkwürdig

Ich habe jetzt beim openpli eine Lösung gefunden, die vermutlich auch hier bei VTI klappt Ich habe den I/O Scheduler für die hdd von
cfq Completely fair queuing) auf deadline umgestellt und die Box ist nicht mehr wiederzuerkennen.

welcher scheduler eingestellt ist kann man auf der cli nachsehen mit

cat /sys/block/sd*/queue/scheduler
für alle platten oder
cat /sys/block/sda/queue/scheduler
für die erste Platte

da kommt vermutlich
noop deadline [cfdg]

ich habe dann deadline eingeschaltet einfach mit
echo deadline > /sys/block/sda/queue/scheduler

Wenn beim VTI aber kein deadline angeboten wird, dann kann man das so erstmal nicht ausprobieren

Das ist nach dem Booten auch wieder weg und muss entweder im Kernel reincompiliert werden oder mit den runlevel Scripten beim Start an passender Stelle eingeschaltet werden

Das hat wahre Wunder gewirkt. Keine Aussetzer mehr beim Aufzeichnen und parallelem Schneiden/Verschieben. Habe das mit 14 Aufnahmen, Schneidern und Verschieben getestet. Alles super.

Ist also doch kein Treiberproblem, aber ein Schedulerproblem. Entweder hat er cfq Scheduler auf ARM ein Problem oder er passt nicht wirklich gut zu den Echtzeitanforderung der Box mit gleichzeitigen anderen Plattenaufträgen. Wobei er bei den MIPS Geräten auch schon immer aktiv war und da hatte ich diese extremen Probleme nicht.

Zu den Schedulern gibt es einiges im Netz zu lesen, wer das mal wissen möchte

Habe heute noch etwas weiter getestet und bin mit deadline sehr zufrieden. Es kann sein, dass nur die ARM boxen mit dem 4.1.20er Kernel mit dem CFQ Scheduler Probleme haben.

Falls also einer von euch mal bei einer uno4kse HDD Performanceprobleme hat, am besten mal deadline anstatt cfq einstellen

Die Uno4kse hat im Vergleich zu einer Ultimo4k eine 4.1.20er Kernel und es hängt mit dem Kernel zusammen, so wie es aussieht

Vielleicht ist die Aussage falsch, dass es alle 4k Modelle trifft, aber jedenfalls alle uno4kse Geräte.

Ich habe das Problem bei zwei uno4kse Geräten, es ist also kein Einzelexemplarproblem. Und es tritt mit jedem Image auf und es ist absolut reproduzierbar. Der deadline Scheduler hat den Ruf, recht gut für Echtzeitumgebungen geeignet zu sein. Der cfq ist das von Natur aus nicht. Das ist er der Nachfolger BFQ, der ist aber in den Kernel aktuell nicht enthalten.


Ich bin nach meinen Versuchen sehr davon überzeugt, dass das Problem alle uno4kse Benutzer haben werden, die das mit dem Schneiden während der Aufnahmen probieren werden. Falls es also auch mal andere Benutzer tritt, soll das hier als Ratschlag dienen.

Kann gut sein, dass der ältere Kernel nicht betroffen ist, aber ich kann das bei der uno4kse nur mit dem 4.1.20er Kernel probieren, weil es keinen älteren gibt.

Dass bisher keiner mit der uno4kse das so berichtet, ist nicht verwunderlich. Die Box ist erst seit Dezember verfügbar und man muss schon einige Aufnahmen parallel machen, dann parallel Schneiden und noch Filme auf ein NAS über das Netzwerk schieben. Das haben zum heutigen Zeitpunkt sicherlich noch nicht viele ausprobiert und wenn es dann mal Aussetzer gibt, glauben vielleicht auch einige, dass das ja auch zuviel für so eine Box ist.

Du kannst mir ruhig glauben, dass ist mit dem cfq und Kernel 4.1.20 und der uno4kse nicht vernünftig machbar. Schaltet man auf deadline um, ist die Box in einer anderen Performanceklasse unterwegs und macht das, was man erwartet.


Was das Thema Echtzeit angeht. Die Aufzeichnungsthreads stellen durch ihre permanenten Daten, die ja beim Empfang in die Box reinkommen, (1-1,5 MByte bei HD Sender) eine Anforderungen an das System, diese auch mit dieser echten Realtime Geschwindigkeit auch auf die Platte
schreiben zu müssen. Andere Dinge in der Box dürfen das nicht verhindert. Daher muss der I/O Scheduler auch eine Echtzeitfähigkeit mitbringen.

Habe heute morgen 20 HD Sender parallel aufgenommen, andere geschnitten und nochmal andere verschoben, alles parallel Die Box was bedienbar und die Platte hat alle Aufnahmen ohne Verluste gespeichert. Das wäre mit cfq undenkbar bei der uno3kse und Kernel 4.1.20. Wie schon geschrieben, habe das mit openpli, openATV, VTI und dem Originalimage probiert. Keins bekommt das mit cfq hin

Ich wünsche mit etwas mehr Offenheit, wenn man hier Probleme schildert, in die man auch schon einige Zeit gesteckt hat. Bemerkungen, dass das alles nicht sein kein, helfen nicht wirklich weiter. Ich wette, wenn das mal einer bei einer uno4kse probiert, dann wird er feststellen, dass es so ist.

Ist ja auch gut zu wissen, dass die ARM Boxen mit einem anderen Kernel das Problem wahrscheinlich nicht haben, dass kann ich aber nicht selber verifizieren.

Ich möchte einfach nur helfen, die Dinge zu verbessern, die nicht gut funktionieren. Und damit nicht jeder die gleichen Aufwände bei der Ursachenforschung betreiben muss, habe ich meine Erfahrung geteilt.

Wenn GarborDenes meint, dass meine Tests auf zwei Geräten nicht aussagekräft sind, ist das seine Meinung

Ich habe diese Tests auf zwei verschiedenen un4kse Geräten gemacht

Ich habe 4 verschiedene HDDs verwendet, 3,5 ZolL 2TB USB3.0 extern, 2,5 Zoll 1 TB USB3.0 extern , 2,5 2TB HDD intern, 2,5 2TB SHDD intern
Das ganze mit 4 verschiedenen Images (openpli, openATV, VTI, VuPlus Original)
Das ganze mit echten TV Sendern und Filemdateien
Das ganze mit simulierten Aufzeichnungen und Cutting, Moving mitteln dem CLI Tool dd
Das ganze mit verschieden großen Clustern auf der HDD (4K, 256K, 1MB, 2MB)
Das ganze mit unterschiedlich befüllten Platten
Ich habe mir die CPU Loads für idle, I/O angeschaut und auch die Performance der jeweiligen Schreibvorgänge.

Aus meiner Sicht sind das umfangreiche Tests und Analysen gewesen, die mir ein super gute Basis gegeben haben, diese Änderung von cfq auf deadline bei der uno4kse und Kernel 4.1.20 für gut zu befinden.

Mag hier jeder selber entscheiden, ob es das mal ausprobiert, falls es auf der uno4kse so solchen Problemen kommt

Nochmal das Rezept für die Tests

man starte 10 parallele Aufnahmen
Man schneide einige Filme mit cutlisteditor und lässt diese dann auf der gleichen HDD schneiden
Man verschiebe oder kopiere Filme über das Netzwerk auf ein NAS oder andere Box

Wer das bei einer uno4kse mit Kern 4.1.20 also hier dem aktuellen VTI 13 macht, wird schnell erkennen, dass die Aufnahmen massive Aussetzer haben, wenn der Standardscheduler cfq verwendet wird.

Falls es euch als mal erwischt, macht mal die Änderung auf deadline und ihr werdet begeistert sein

Heute morgen habe ich 20 parallele Aufnahmen gemacht und den Rest wie beschrieben.
Die Box schafft das dann problemlos und ist auch noch vernünftig bedienbar und die Aufnahmen sind ok.

Heute morgen hat aus einem anderen Forum ein Dreambox User schon bestätigt, dass es bei ihm auch nach Umstellung von cfq auf in dem Fall nur noop (einfacher Scheduler nach Fifo) auch eine gute Verbesserung gab. Es konnte deadline nicht einstellen, weil das bei ihm nicht eincompilert war. Es hat allerdings auch eine SSD eingebaut und da ist noop sicherlich ganz ok, das es keine Kopfbeweungen gibt, weshalb der I/O Scheduler nicht unbedingt nach Sektoren sortieren muss

Wie gesagt, soll jeder selber entscheiden. Auf Streitigkeiten hier habe ich echt keine Lust