Kopiergeschwindigkeit interne HDD auf USB HDD

    • Kopiergeschwindigkeit interne HDD auf USB HDD

      Möchte hier einmal meine Erfahrungen mit OE2.0 mitteilen.

      Mehrere Versuche (diese erstreckten sich über die letzen 6 Monate) sich mit der OE2.0 anzufreunden endeten bei mir in der unerklärlichen geringen Datengeschwindigkeit von der internen HDD auf eine USB HDD.
      Mit OE1.6 werden etwa 20MB/s erreicht.
      Mit OE2.0 werden nur etwa 7.5MB/s erreicht.
      Beide HDDs sind mit ext3 ausgestattet.

      Dieser Nachteil ist so gravierend, dass mich die vielen anderen Vorteile der neuen Version nicht überzeugen können.
      Schade, dass dieser Nachteil in der Entwicklerumgebung noch keinem aufgefallen ist.

    • Die Messungen resultieren aus Zeitmessungen mittels Stoppuhr und Taschenrechner beim Kopieren von Sendungsaufzeichungen (etwa 6GB Dateigröße) von der intenen zur externen HDD.
      Wie gesagt, diese Angaben lassen sich durch mehrmalige Wiederholungen reproduzieren.
      Die verwendete Hardware ist immer dieselbe, und die Übertragungszeiten erhöhen sich mit OE2.0 so drastisch.
      Ob eine Sendungkopie 6min oder mehr als eine Viertelstunde benötigt, ist schon ein KO Kriterium.

    • Habe schnell mal eine SATA I 120GB 2,5" Platte über USB auf meinen beiden SE getestet und mit einem 2GB File die write time gemessen:

      Quellcode

      1. time dd if=/dev/zero of=/media/mountpoint_der_USB-Platte/testfile bs=1M count=2048


      OE1.6 (NN² v3.1.4): 89,67sec = 22,8 MB/s
      OE2.0: 135,62sec = 15,1 MB/s

      das liegt am OE2.0 schätze ich mal, da ist wohl DMM der Ansprechpartner, wobei ich seltsam finde, dass deine Platte mit OE2.0 fast um 63% langsamer sein soll, ich verliere gerde mal 1/3 writespeed, was aber auch nicht unbedingt wenig ist ...
      Gruß Fred

      Die Dreambox ist tot, es lebe die Dreambox

      ¯\_(ツ)_/¯

      Quellcode

      1. root@dm920:~$ mount | grep "/ "
      2. /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered)
      3. root@dm920:~$

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Fred Bogus Trumper ()

    • Das der neue Kernel auf STB's nicht unbedingt performanter ist wissen wir schon das macht sich auch nicht nur bei Festplatten-Operationen bemerkbar sondern auch im Netzwerk.
      Dazu kommt das der Kernel 3.2 für den BCM7400 (dm8000) nicht von Broadcom unterstützt wird - da musste wohl DMM allerhand selber machen.

      Das und die 256MB RAM sind wahrscheinlich auch der Grund dafür weshalb die Box kein OE2.0 Release Image erhalten wird.
      Wenn man nicht unbedingt HBBTV oder eine >2TB Festplatte betrieben möchte dann lässt man wohl besser ein älteres Image auf der dm8000

      Ich kann mir zwar vorstellen das dm8000 Besitzer so etwas gar nicht gerne hören aber man muss dann auch mal so ehrlich sein und sich eingestehen das die Box 5 Jahre alt ist und der Prozessor ist vermutlich sogar noch etwas älter.

      Oder professioneller Kernel Hacker und Softwareentwickler werden und das Problem selbst beheben :)

    • Hi,

      der "neue" kernel .. oder allgemein die neueren Kernel können leider nicht so gut mit wenig RAM umgehen. Da ist das pagecache handing irgendwie total doof/kaputt.. hinzu kommt noch, dass im OE2 generell weniger RAM frei ist welches der Kernel als pagecache nutzen kann. Weil enigma2 selber mehr RAM benötigt für QT und andere libs.

      Also was man mal versuchen könnte wäre die libpagecache zu benutzen. Diese verhindert, dass der RAM voll läuft.. und dann die IO Last extrem ansteigt. Dazu kann man einfach LD_PRELOAD=/usr/lib/libpagecache.so dem cp oder dd Befehl voranstellen. Dann wird weniger gecached..

      Quellcode

      1. PAGECACHE_FLUSH_INTERVAL=$((4*1024*1024)) LD_PRELOAD=/usr/lib/libpagecache.so time dd if=/dev/zero of=/media/hdd/bla bs=1M count=2048
      PAGECACHE_FLUSH_INTERVAL setzt die maximale size die für den Pagecache verwendet wird... eventuell reicht da auch weniger.. 2 MB ... oder 1MB.

      Das könnte helfen. Ohne die libpagecache wird sehr viel CPU Zeit damit verschwendet darauf zu warten, dass wieder Platz im Pagecache vorhanden ist.. bzw.. der es wird dann angefangen auf die HDD zu schreiben und der kernel wartet bis das fertig ist.

      Eventuell vorher mal noch

      Quellcode

      1. echo 3 > /proc/sys/vm/drop_caches
      ausühren.

      cya

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von nokia ()

    • @medicusus

      aktiviere mal testweise vor dem Kopieren ein (256MB) swapfile auf der USB-HDD oder einem USB-Stick, vielleicht hilft das schon

      Auf der DM800SE mit dem OE1.6 Image hatte ich ein aktives swapfile auf USB beim write test, mit OE2.0 ohne swap getestet. Ich hab' jetzt den Test mal mit OE2.0 und aktiven Swapfile auf der Ziel USB-HDD wiederholt, und ist jetzt fast genau so schnell wie unter OE1.6

      Quellcode

      1. 2147483648 bytes (2.0GB) copied, 90.980128 seconds, 22.5MB/s


      selbst mit einem aktiven Swapfile auf einem extrem langsamen USB-Stick (512MB write mit 2,7MB/sec) erreiche ich 22,1 MB/sec write auf die USB-Platte, statt der 15,1 MB/sec ohne swap.

      Auch mit der 7020HD kann man mit aktiven Swap ein wenig mehr Speed rausquetschen (getestet mit der selben USB-Platte)

      ohne swap: 20.7 MB/s
      256MB swap auf dem selben USB-Stick wie mit der DM800SE: 21,8MB/s
      256MB swap auf der USB-HDD: 22.3MB/sec

      Der Unterschied ist zwar nicht mehr so groß wie auf der SE, aber immerhin.

      Interessanterweise ist die DM7020HD mit OE2.0 auch beim nfs speedtest um einen Tick langsamer als die DM800SE, obwohl sie den doppelten RAM hat


      Edit:

      @nokia
      ich hab' das auch mit deinem Ansatz auf der SE getestet
      Original von nokia

      Quellcode

      1. PAGECACHE_FLUSH_INTERVAL=$((4*1024*1024)) LD_PRELOAD=/usr/lib/libpagecache.so time dd if=/dev/zero of=/media/hdd/bla bs=1M count=2048


      ohne swap: 21.9 MB/sec
      mit swap: 22.6 MB/sec

      die Frage ist aber, wie sich das auf Enigma2 auswirkt, wenn man z.B. HbbTV etc, gleichzeitig nutzen sollte, oder was eben viel RAM braucht. Da fehlt mir ehrlich gesagt das Hintergrundwissen
      Gruß Fred

      Die Dreambox ist tot, es lebe die Dreambox

      ¯\_(ツ)_/¯

      Quellcode

      1. root@dm920:~$ mount | grep "/ "
      2. /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered)
      3. root@dm920:~$

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Fred Bogus Trumper ()

    • Danke allen, die sich bemüht haben, der Problematik auf den Grund zu gehen. Werde daraufhin demnächst einen weiteren Versuch unternehmen. Die Swapfunktion ist sicher eine interessante Option, möglicherweise für die Gesamtperformance.
      Die DM8000 besitzt einen CF-Kartenschacht, dieser sollte dafür gut geeignet sein.
      Werde jedenfalls danach berichten...

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

    • Gäbe es eigentlich auch die Möglichkeit einen Fortschrittsbalken anzeigen zu lassen, wenn man was von interner HDD auf USB-Stick kopiert.
      Einfach um bisschen besser abschätzen zu können wie lange es noch dauert.
      Oder vielleicht sogar auch noch die Übertragungsrate?