[Erledigt] Interne HDD ist beim Schneiden und Verschieben extrem langsam

  • [Erledigt] Interne HDD ist beim Schneiden und Verschieben extrem langsam

    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.
  • welches dateisystem und auch interface hat die interne hdd? typisch sind bei einer SATAIII mit ext4 ca 150 MB/s. ausserdem, die VU+ boxen sind keine multitasking-pcs mit zb DMA was simultanes read/write anbelangt, also warum alles gleichzeitig...
  • 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.
  • crossposting ist (nicht nur hier) mehr als ungern gesehen

    (erst recht nicht in Themanfremde Threads...)
    Threads zu den Plugins zu finden im Bereich Plugins
    Homepage für FS-Plugins - downloads, details, ...
    webradioFS, PictureCenterFS, PlanerFS, mspFS-Schichtplan, camoFS, HeizölpreiseFS, timFS-mein Menü, VolPlusFS und mehr

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von shadowrider ()

  • anudanan schrieb:


    Hat hier sonst keiner das Problem?

    ...

    Ich vermute aktuell, dass das mit jeder ARM Box so ist.
    Ich habe mal einen Film mit dem Cutlisteditor geschnitten.
    Auf der Solo4k etwas mehr als 2min. für einen Film, der geschnitten 6,7GB gross ist.
    Das sind wohl >50 Mbyte/s.
    Prozessorauslastungsanzeige schwankt zwischen 16 und 28%.

    Ich gebe zu auf dem PC (mit SSD) sind es ca. 22 sec.
    Ich bin mit dem Ergebnis meiner Box jetzt nicht unzufrieden.
  • 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

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von anudanan ()

  • Neu

    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
  • Neu

    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
  • Neu

    Ich habe keinen Schimmer wie du auf diese Aussage kommst:

    anudanan schrieb:

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

    Ich hab gerade bei mir nachgeschaut:
    root@vuultimo4k:~# cat /sys/block/sd*/queue/scheduler
    noop deadline [cfq]
    noop deadline [cfq]
    root@vuultimo4k:~#

    Ich hatte noch nie Performance Probleme mit meiner HDD, auch nicht in der Solo4K und ich schneide(Vor- und Nachlauf), während ich aufnehme und verschiebe



    Wie gesagt, deine "Thesen" halte ich für sehr gewagt und ich würde niemandem raten, deine Empfehlung umzusetzen, da sie m.E. völlig unfundiert sind und man nicht wissen kann, welche Auswirkung / Nebenwirkungen solche Spielereien auf das System haben.
    Es spricht ja nichts dagegen, das du dein System u.U. gefährdest, aber solche Experimente ohne hinreichende Tests und Grundlagen anderen zu empfehlen ist m.E, fahrlässig und gefährlich.
    Die Benutzung der Suche ist NICHT verboten! D:

    "Hilfe!!!" ist kein sinnvoller Titel für einen neuen Thread, ebensowenig "VU+Zero" oder vergleichbares.
    [url='https://de.wikipedia.org/wiki/Universal_Serial_Bus']USB-Spezifikationen[/url]
  • Neu

    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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von anudanan ()

  • Neu

    anudanan schrieb:

    Ich habe das Problem bei zwei uno4kse Geräten, es ist also kein Einzelexemplarproblem
    2 Geräte sind natürlich eine solide Basis!

    Wie gesagt: du darfst selbstverständlich mit deinen Boxen treiben, was du willst, aber bitte sprich keine Empfehlungen dafür aus. Das liest ein Anfänger, probiert es, ohne zu wissen, was er tut und bekommt dann womöglich unlösbare Probleme.

    anudanan schrieb:

    Ich bin nach meinen Versuchen sehr davon überzeugt, dass das Problem alle uno4kse Benutzer haben werden,
    "Versuchen" - überzeugt..
    du bist jedenfalls bisher der Einzige, der das Problem hat, zumindest so extrem wie du es schilderst.

    Eine STB ist übrigens keine Echtzeitumgebung

    Und die Aussage ist nicht vielleicht falsch, sondern ganz sicher.
    Die Benutzung der Suche ist NICHT verboten! D:

    "Hilfe!!!" ist kein sinnvoller Titel für einen neuen Thread, ebensowenig "VU+Zero" oder vergleichbares.
    [url='https://de.wikipedia.org/wiki/Universal_Serial_Bus']USB-Spezifikationen[/url]
  • Neu

    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.
  • Neu

    da du mich nicht im Ansatz verstehst/verstehen willst,. lies dir wenigstens mal die Definition für ein Echtzeitbetriebssystem durch (RTOS)

    und wieder basieren deine Auzssagen ausschliesslich auf nicht haltbaren Annahmen:

    anudanan schrieb:

    Dass bisher keiner mit der uno4kse das so berichtet, ist nicht verwunderlich

    Wenn es ernsthafte Probleme gibt, ist im allgemeinen das "Geschrei" groß, vor allem wenn das so gravierend sein sollte, wie deine Behauptung. Ok, das ist auch kein belastbarer Beweis, basiert aber auf bisherigen Erfahrungen (Mehrzahl) hier im Board.

    Ein letztes Mal:
    Das was anudanan schreibt ist m.E. KEINE Empfehlung, die für die Allgemeinheit geeignet ist, da sie ohne hinreichend fundierte Tests (Nein, 2 Boxen, die du selber eingerichtet hast, sind KEIN Fundament)

    Und nochmal für dich @anudanan:
    ich habe nicht behauptet
    dass das alles nicht sein kein
    Ich bestreite nicht, das das Problem in der geschilderten Form bei dir vorliegt oder deine Lösung Deines Problems, ich bezweifele ausschließlich deine Empfehlung.
    Und jetzt bin ich raus.

    Die Benutzung der Suche ist NICHT verboten! D:

    "Hilfe!!!" ist kein sinnvoller Titel für einen neuen Thread, ebensowenig "VU+Zero" oder vergleichbares.
    [url='https://de.wikipedia.org/wiki/Universal_Serial_Bus']USB-Spezifikationen[/url]
  • Neu

    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
  • Interne HDD ist beim Schneiden und Verschieben extrem langsam

    Neu

    Würdet ihr jetzt bitte die Auseinandersetzung beenden?
    Ich denke, jeder hat seinen Standpunkt ausreichend erläutert.

    Danke.
    Einmal dachte ich, ich hätte unrecht, aber ich habe mich getäuscht.