Ruckelt bei VU+ Uno 4K mit USB 3.0 Seagate 4TB

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Es geht hier aber nicht um SD Karten sondern um eine USB Festplatte an einer Uno 4k!!
      Nüchtern betrachtet war es besoffen besser.

    • Das stimmt. Hier werde zwei Ruckelfälle gemischt. Einmal der mit der HDD von vom Thread-Ersteller und einmal das Thema mit der SD Karte

    • ein detail dazu: 4TB (und groessere) hdds haben doch typisch 4k sektoren. die oi und vti unterstuetzen diese (seit ca jan 2016) uneingeschraenkt, auch praktisch mit 4TB hdds in bzw an der duo2 festgestellt. ausserdem haben die ext4 filesysteme dieser images per default das contiguous flag gesetzt. bs=512 ist somit bei solchen hdds der (max/med) datentransferrate wenig zutraeglich, daher min bs=4096 und realistisch eher bs=16384.

    • kann gerne in dem dd test noch angepaßt werden. Dann den Count um den gleich Fakter kleiner machen.

      Für die Unterschiedsmessung dürfte das aber egal sein. Der Kernel wird ja die Lese- und Schreibvorgänge vom dd entsprechend sammeln und in die 4K oder 16K Happen aufteilen.

      Das script wäre dann eher so

      dd if=/media/hdd/test1.img of=/media/hdd/test2.img bs=16384 count=62500 &
      dd if=/media/hdd/test.img of=/dev/zero bs=16384 count=62500 &
      dd if=/dev/zero of=/media/hdd/test3.img bs=16384 count=31250 &
      dd if=/dev/zero of=/media/hdd/test4.img bs=16384 count=31250 &
      dd if=/dev/zero of=/media/hdd/test5.img bs=16384 count=31250 &
      dd if=/dev/zero of=/media/hdd/test6.img bs=16384 count=31250 &
      dd if=/dev/zero of=/media/hdd/test7.img bs=16384 count=31250 &
      dd if=/dev/zero of=/media/hdd/test8.img bs=16384 count=31250 &
      dd if=/dev/zero of=/media/hdd/test9.img bs=16384 count=31250 &
      dd if=/dev/zero of=/media/hdd/test10.img bs=16384 count=31250 &

      und vorher dann mit
      dd if=/dev/zero of=/media/hdd/test.img bs=16384 count=62500
      dd if=/dev/zero of=/media/hdd/test1.img bs=16384 count=62500

      die beiden Dateien erzeugen

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

    • Ruckelt bei VU+ Uno 4K mit USB 3.0 Seagate 4TB

      Die Blockgröße bei Flash ist auch 4kbyte, dieses Entgegenkommen nutzte mir aber nicht. FAT32 mit 0,5kbyte Blockgröße und Clustern größer als besagte 4kbyte funzt auch, aber die Vus können Aufnahmen nicht splitten, um das 4GB Limit zu umgehen.
      Bei HDs könnte die Sektorgröße aber wichtig sein. Alle HDs von heute haben 4K Sektoren, die Meisten verwenden aber eine Emulation der traditionellen 0,5kbyte Blöcke, für bessere Kompatibilität. Externe Laufwerke verzichten teils drauf, Einbauplatten gibt es oft in ner Version mit und ohne Emulation. Das bedeutet ggf Finger weg von 4k Hds.

      • 4GB max dateigroesse ist FAT32 bedingt. bei ext2/3/4 kein solches problem. also kein Vu+ problem.
      • alle hdds groesser 2TB, welche frei formatierbar sind, taete ich behaupten. NTFS umschifft das bekannte 2TB limit nur durch cluster, welche aus einer festen anzahl groesser eins von 512B sektoren gebildet sind, deshalb die emulation. also mit 4kB cluster max 16TB.
      • unter unix und linux ganz im gegenteil, 4kB sektoren bedeuten nur vorteile, waren bei high performance SCSI hdds schon vor 15...20 jahren standard. die dortigen und heutigen ext filesysteme brauchen bzw verwenden die emulation naemlich gar nicht. limit ist hierbei 2^48 bzw bei durchgaengig 64bit sogar 2^64 sektoren.

    • Die HDDs mit 4K Sektoren sind definitiv kein Problem für Linux. Beim initialisieren muss nur darauf geachtet werden, dass eine Partition an einem Sektor beginnt, wenn man in 512 Bytes Sektoren denken würde, der ein Vielfaches von 4kbyte ist. Darauf achten die Images aber normalerweise beim initialsieren der Partition

    • Korrekt es wurde aligned:

      Quellcode

      1. Disk /dev/sda: 4294967295 sectors, 4095M
      2. Logical sector size: 512
      3. Disk identifier (GUID): d598f10c-6539-4c2e-b707-ba89a5f780c6
      4. Partition table holds up to 128 entries
      5. First usable sector is 34, last usable sector is 7814037133
      7. Number Start (sector) End (sector) Size Code Name
      8. 1 2048 7814035455 3726G 0700 disk1
      Aber das eine Platte standardmäßig mit 4k Blöcken arbeitet (Schnittstelle nicht physikalisch) ist aktuell noch recht selten. Bei unseren Server wird nur auf explizitem Wunsch 4k Platten verbaut. Ansonsten wird alles auf 512 gemappt, so wie bei dieser Externen auch.
      Receiver: 1x VU+ Uno 4, 1x VU+ Zero - Anlage: Inverto Unicablesystem - Skin: Fluid

    • ich habe gerade nochmal das Script mit den vielen dd Befehlen ausgeführt (diesmal mit bs=16374), was das Aufzeichnen, Schneiden und Verschieben simulieren soll.

      Auch da sieht man wunderbar, dass die Zeile, die nur eine Datei liest und dann ins /dev/zero schickt, also das Verschieben simuliert, beim cfq Scheduler sich anfänglich fast die ganze Bandbreite zur HDD krallt und die anderen echt zurückgedrängt werden, denn dieses dd kommt dann auf sehr hohe Werte,

      Mit deadline ist das aus meiner Sicht besser verteilt und alle kommen sinnvoll dran, insbesondere die schreibenden Prozesse

      Wenn man nur ein dd Kommando laufen läßt, ist es egal welches (nur Lesen, Nur Schreiben, oder beiden), dann ist die Performance mit cfq und deadline gleich.

      Für mich ist zumindest beim Kernel 4.1.20 deadline der bessere Algorythmus. Vielleicht hat cfq da ja auch einen Bug, den es vorher nicht gab.

    • Also ich hatte heute einen Ton-Ruckler (paar ms). Es ist zwar noch zu früh für genaue Aussagen, aber das ist viel weniger als sonst. In der gleichen Zeit habe ich bestimmt 3-4 Ruckler.
      Receiver: 1x VU+ Uno 4, 1x VU+ Zero - Anlage: Inverto Unicablesystem - Skin: Fluid

    • Hattest du den i/o scheduler umgestellt? Und wenn ja auch bootfest? Oder lässt du die Box durchlaufen mit normalen Standby?

    • Ich habe mir ein init.d script geschrieben. Aber generell lasse ich den im Soft-Standby durchlaufen. Ich habe mir auch die Scheduler im Detail angeschaut, das Prinzip finde ich auch fast noch besser als cfq. Was mich mehr ärgert, ist dass der Streambuffer so schnell geleert wird, ich kann mir kaum vorstellen, dass der RAM bei 1-2 Sekunden Verzögerung vollläuft, somit müsste man eigentlich nur den Buffer größer schrauben. Aber ich vermute dafür müsste ich Enigma2 selber kompilieren...
      Receiver: 1x VU+ Uno 4, 1x VU+ Zero - Anlage: Inverto Unicablesystem - Skin: Fluid

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

    • Leider hat bis her nichts geholfen, wenn auch der andere Scheduler es verbessert hatte. Ich werde jetzt aber mal eine andere Platte testen.
      Receiver: 1x VU+ Uno 4, 1x VU+ Zero - Anlage: Inverto Unicablesystem - Skin: Fluid

    • Vielleicht hast du ja mehrere Ursache. An die HDD glaube ich nicht wirklich als Ursache

      Hast du denn beim LIVE TV nie Störungen? Es könnte ja auch noch an der ganzen SAT Anlage liegen, die vielleicht die restlichen Störungen jetzt noch erzeugt.

    • Die Idee hatte ich auch schon, aber mir sind bis jetzt keine Störungen im Live-TV aufgefallen. Das verwundert mich halt. Ich werde weiter suchen...
      Receiver: 1x VU+ Uno 4, 1x VU+ Zero - Anlage: Inverto Unicablesystem - Skin: Fluid

    • Sind die Störungen nur, wenn mehrere Aufnahmen laufen oder auch schon bei einer? Große Cluster anstatt der 4K könnten noch helfen, ist aber mit Aufwand verbunden, weil die HDD mit mkfs.ext4 ein neues Filesystem braucht. Dann muss erstmal alles gerettet werden, was da aktuell drauf ist

      Komisch ist das aber schon

    • Hi,

      wie sieht so ein Init.d Script aus und wo im Filesystem wird das abgelegt das nach einem Neustart der I/O Scheduler auf deadline eingestellt ist?

    • Ich möchte mich der Frage von Ogni anschließen, auch wenn sie schon länger unbeantwortet ist.
      Würde auch gerne permanent auf Deadline umstellen ...

    • Beim openpli gibt es eine Datei rcS.local in dem Verzeichnis
      /etc/init.d
      die beim Systemstart ausgeführt wird, da habe ich die Kommandos für die Umstellung auf deadline untergebracht

      Das sieht dann so aus für die Umstellung von drei HDDs an /dev/sda, /dev/sdb und /dev/sdc.
      Es ist auch nicht schlimm, wenn man weniger HDDs angeschlossen hat, auch die anderen mit umzustellen

      Quellcode

      1. echo deadline > /sys/block/sda/queue/scheduler
      2. echo deadline > /sys/block/sdb/queue/scheduler
      3. echo deadline > /sys/block/sdc/queue/scheduler
      Damit die Datei ausgeführt werden kann, am besten noch mit
      chmod +x /etc/init.d/rcS.local
      das Ausfühungsattribut vergeben, falls die Datei vorher noch nicht da war.

      Man kann diese Befehle auch erstmal in der Linux Kommandozeile so eingeben und dann testen

      Wie der scheduler vorher eingestellt ist, kann man mit

      Quellcode

      1. cat /sys/block/sd*/queue/scheduler
      abfragen
      Das kann man dann auch mal nutzen, um zu sehen, ob das mit der rcS.local in /etc/init.d funktioniert nach einem Neustart.

      Entsprechen kann man auch wieder mit dem echo Befehl auf cfq umstellen

      Vielleicht kann noch einer mit vti Kenntnissen bestätigen oder einen anderen Vorschlag machen, wo man eigene Befehle für den Systemstart hinterlegen kann.

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