Aussetzer bei Aufnahme über NFS (DM8000, Qnap-NAS)

Wir haben aktuell ein Problem mit dem Board und arbeiten an der Lösung...

    Hallo,
    ich habe mir vor ca. einem halben Jahr ein Qnap TS-569 Pro gegönnt, auf welches ich von meiner Dreambox 8000 aus aufnehme. Anfangs lief alles fehlerfrei, in letzter Zeit beginnen jedoch zunehmend unregelmäßige Aussetzer aufzutreten (ohne, dass ich an der Konfiguration vom NAS oder der Dreambox was geändert habe).
    Die Aussetzer sind nicht reproduzierbar. Häufig kommen mehrere kurz hintereinander, wobei es dann von Mal zu Mal schlimmer wird. Zu Beginn kann es nur mal einen Bruchteil einer Sekunde ein Standbild sein und sich dann steigern bis zu 3 Minuten Standbild in Kombination mit Zahnrädern und hängen der Box (nimmt während dieser Zeit keinerlei Befehle an). Typisch ist dabei auch, dass von der aufgezeichneten Sendung größere Stücke komplett fehlen - es also nach einem längeren Aussetzer unvermittelt in einer komplett anderen Szene weitergeht.


    Ich habe schon verschiedene Maßnahmen probiert: Von NFS mal probeweise auf Cifs umgestellt (geht tendenziell noch schlechter), von UDP auf TCP gewechselt, rsize, wsize geändert, die Parameter ganz weggelassen, ein Swap-File auf einer CF-Karte eingerichtet,...


    Langsam fällt mir nichts mehr ein, was ich noch probieren könnte. Vor allem ist mir ein Rätsel, woher der Fehler überhaupt kommt. Die Aussetzer sind alles andere als reproduzierbar. Manchmal läuft es eine ganze Stunde ohne Probleme, dann wieder ruckelt es alle 5 Minuten.


    An der grundlegenden Performance scheint es nicht zu liegen.
    Auf der einen Seite kann ich z.B. zeitweise, wenns drauf ankommt, tatsächlich drei (!) HD-Sender gleichzeitig aufnehmen und dabei gleichzeitig einen anderen, zuvor aufgenommenen Film anschauen. Alles kein Problem und ruckelfrei. Auf der anderen Seite kann es vorkommen, dass ich genau einen Film aufnehme (und sonst nichts mache - also minimale Auslastung) und dann später Aussetzer drin hab.
    Wenn nun tatsächlich das Netzwerk zu langsam wäre, könnte ich ja verstehen, dass ich einen Flaschenhals drin hab, aber so scheint mir das doch sehr merkwürdig und ich kann absolut nicht nachvollziehen, woher das kommen könnte. :confused_face:



    Das Netzwerk ist komplett kabelgebunden, IPs sind fest vergeben und zwischen der Dreambox und dem NAS hängen nur ein Switch und ein Router (beide Gigabit-LAN-fähig).
    Der Speedtest der Deambox misst: 100 MB geschrieben ind 9.4 s und 100 MB gelesen in 8.9 s.


    Das NAS selbst langweilt sich wohl die ganze Zeit bei einer CPU-Auslastung im einstelligen Bereich und über Gigabit-LAN erheblich höheren, möglichen Transferraten (Beim Kopieren NAS -> PC komme ich derzeit auf ~72 MB/s und PC -> NAS ~80 MB/s).


    Als Image habe ich derzeit ein original Experimental von 2013-08-01 mit Gemini-Plugin und sonst recht wenig Änderungen am Laufen. Vielleicht mach ich da demnächst mal ein Update (momentan grad nicht die Nerven dazu), aber ich glaub eh kaum, dass es daran liegt. Die NFS-Unterstützung sollte in diesem Image ja normal auch schon fehlerfrei sein...


    auto.network sieht momentan so aus:
    aufnahme -fstype=nfs,rw,nolock,soft,udp,rsize=8192,wsize=8192 192.168.2.13:/Dreambox


    Hat jemand eine Idee, was ich noch tun könnte?

    versuch´s mal hiermit


    Zitat

    aufnahme -fstype=nfs,rw,soft,nolock,tcp 192.168.2.13:/Dreambox

    Gruß Jörg


    DM 900 unstable Image 2.5 + GP4.2
    DreamOne AIO Image GPT + GP4.2
    Sony KD-65XD8577
    Sony KD-55XG7004

    Sennheiser AMBEO Soundbar Max + REL HT/1003

    Synology DS923+/DS720+

    Ich hatte genau das gleiche Problem und habe auch keine Lösung gefunden.
    Genau die gleichen Fehler wie du..auch meine Tests waren die gleichen...
    Mit einem oe16 image hatte ich jedoch deutlich weniger Spinner und Aussetzter als mit einem oe20 image.


    meine Ruckler sind jedoch weg nachdem ich mein Qnap509 durch ein Synology 414 ersetzt habe.


    das was ich nicht versucht hatte war eine "alte" Firmware aufs QNAP aufzuspielen...villeicht wurde ja da was verschlimmbessert bei den aktuellen Versionen.

    JörgH61: Wie im Startpost angegeben habe ich die letzten Tage einiges probiert. Dabei hatte ich vor drei Tagen tatsächlich bereits exakt diese Konfiguration probiert. Leider war das auch nicht der Schlüssel zum Erfolg.


    cs_e: Gut zu wissen, dass ich mit diesem Problem offenbar nicht alleine bin. Ist zwar nur ein schwacher Trost, aber trotzdem danke für die Information.
    Falls es wirklich am Qnap liegen sollte, wäre das echt mega enttäuschend (ist ja nun wahrlich nicht das billigste Gerät und die NFS-Freigabe wohl noch eine der trivialsten Funktionen), aber naja, möglich ist es natürlich.
    Dann werd ich wohl mal die Firmware davon aktualisieren und es im Zweifelsfall mal mit einer alten 3.x Firmware versuchen (Momentan läuft darauf QTS 4.0.2). :frowning_face:

    Also, ich kenne mich damit nicht so aus, vielleicht also alles quatsch...
    Aber: OE20 kennt ja nur die rsizw,wsize 8k, den parameter kann man sich also sparen.
    Vielleicht ist das aber bei einigen nfs implementierungen suboptimal, will sagen, da passen dann nfs server und client nicht so gut zusammen.
    Insbesondere gibt seit nfs 2.4 der server die größe vor, nicht der client . Vielleicht macht das Probleme ?


    Wer mehr tetsen will, interessiert vielleicht
    Nfs


    Ich habs nicht ausprobiert, da ich auf interne HD schreibe und dann kopiere und da bisher auch bei OE2.0 keine Probleme hatte

    DM8000 mit RGB-Display Skin=infinityHD/image=exp2011-09-06/GP3,DM7020HD, OE2.0 mit karatelight, DM7080HD

    Ich hatte ein ähnliches Problem mit meinem QNAP TS412 (Firmware 3.6.1) und meiner 7020hd unter Oe 1.6. Bei jedem Aufnahmestart stockte es am Anfang für ein paar Sekunden. Nun bin ich mit beiden Boxen auf das aktuelle OE2.0 experimental umgestiegen und die Aussetzer sind verschwunden, alle Aufnahmen sind einwandfrei. Demnach erwarte ich das Problem nicht im QNAP, sondern eher in der DM.

    Adler313: Sorry, wollte dir so nur mitteilen, dass es bei mir zumindest mit der alten QNAP Firmeware läuft. Ich scheue mich irgendwie davor hier upzudaten, erscheint mir irgendwie der sensibelste Bereich in meinem Netz zu sein. Ne Dreambox ist hingegen recht schnell aufgesetzt, aber ein zerschossenen NAS zu retten ist da schon eine gewaltige Aufgabe (zumindest für mich).
    Demnach war mein Ansatz, zu signalisieren, sich vielleicht nicht alleinig auf das QNAP in der Fehlersuche zu stürzen.


    By the Way:
    Ich nehme an, du hast Festplatten verbaut, die QNAP in ihrer Liste unterstützter Festplatten aufführt? Ggf. auch mal gecheckt, dass kein Festplattendefekt vorliegt?

    welcher Switch wird eingesetzt ?

    ich hatte diesen Fall bei einem defekten Netgear Gigabit Switch und bei einem Bekannten mit einem "billig Teil" von TP Link.

    Als Switch hab ich einen ASUS GX-D1081 im Einsatz.


    cs_e: Weißt du eigentlich noch, welche Firmware du auf dem Qnap hattest? War das schon eine 4.x oder noch eine der letzten 3.x Versionen?

    Hmm, diese Aussage hilft mir jetzt aber auch nicht viel weiter. Wann war das denn? Du wirst das Synology ja nicht erst seit gestern haben. Kann ja sein, dass es die 4.x Firmware zu diesem Zeitpunkt noch gar nicht gab...


    Ich habe im Übrigen gerade eben ein Downgrade gemacht und die Version 3.8.4 auf meinem Qnap installiert. Mal sehen, ob es damit jetzt besser wird. :face_with_rolling_eyes:

    Statusupdate: Das Downgrade hat auch nicht geholfen. Habe mit der Version 3.8.4 weiterhin Aussetzer.


    Außerdem habe ich es mal mit einem anderen Switch probiert - hat auch nicht geholfen.


    Allerdings habe ich beim Beobachten der Aktivtäts-LEDs vom Switch auch eine interessante Beobachtung gemacht: Während der Aussetzter kommt die Aktivität teilweise für mehrere Sekunden komplett zum Erliegen, außerdem hatte ich in dem Switch außer dem Kabel zur Dreambox und dem zum NAS noch ein weiteres zum restlichen Netzwerk und habe auf diesem Anschluss nach Aussetzern vermehrt Aktivität beobachtet.
    Irgendwie habe ich den Eindruck, dass die Dreambox einfach kurzzeitig komplett die Verbindung zum NAS verliert und dann vermutlich erst wieder neu verbinden muss? :face_with_rolling_eyes:



    Was mich auch jeden Fall mal interessieren würde: Gibt es irgendeine Möglichkeit, den Status von dem NFS-Mount zu loggen?!
    Einfach komplett blind nur nach dem Verfahren trial and error mal irgendwas machen scheint mir gerade wenig zielführend und ist einfach nur frustrierend. :frowning_face:

    Zitat

    Originally posted by Adler313
    Was mich auch jeden Fall mal interessieren würde: Gibt es irgendeine Möglichkeit, den Status von dem NFS-Mount zu loggen?!


    Wenn der ernsthaft wackeln würde, landet der diesbezügliche Log im Kernel Message Ringbuffer, den Du mit dmesg abrufen kannst. Der geht auch nach /var/log/messages, am einfachsten also ein tail -f /var/log/messages laufen lassen und dann zugucken, ob was wackelt (typische Meldung ist ungefähr "NFS server not responding, still trying" - die Nemesis jeden NFS-Admins).


    BTW, ändert sich was, wenn das Kabel zum Rest-LAN mal 'ne Weile nicht am Switch steckt? Nur um auszuschließen, dass von dort was kommt, was stört. Sei es, indem es die Platten im NAS in die I/O-Sättigung fährt oder sei es schlicht ein Traffic-Burst (womöglich Broad-/Multicast).


    Falls alles unauffällig bleibt, dann hilft nur noch der Snifffer dabei, die entscheidende Frage zu beantworten, ob die Dream in den Pausen auf Antworten des NAS für ausstehende NFS-Requests wartet oder ob sie schlicht keine sendet. Ich würde das mit tcpdump auf der Dream mitschneiden und das PCAP-File dann auf einen PC schaffen, wo man es mit Wireshark in Ruhe analysieren kann.


    Das tcpdump gibt's bei DMM auf dem Feed (opkg update && opkg install tcpdump oder, wenn man ein anderes Image fährt, manuell holen). Vorgehensweise ungefähr so:

    Code
    tcpdump -i eth0 -s0 -n -w /media/hdd/nfs-test1.pcap host IP.ADDR.OF.NAS


    Laufen lassen, Fehler provozieren (und Zeitpunkte notieren), nachdem man meint, genug im Kasten zu haben mit Ctrl-C abbrechen und das File zum Wireshark verbringen. Für die folgende Analyse Zeit einplanen und die RFCs zu ONC/RPC und NFS griffbereit haben :winking_face:


    HTH,
    Andre.

    Vielen Dank für diese sehr hilfreiche Antwort.
    Tcpdump war tatsächlich auch meine nächste Idee - ich bin dann nur an der Stelle hängen geblieben, wo ich keine passende Version für OE2.0 gefunden habe. Umso mehr nochmal danke, dass du extra eine gebaut hast. :smiling_face_with_sunglasses:


    Leider kann ich mich jetzt sofort nicht ans basteln machen (Dreambox steht bei meinen Eltern und ich komm erste zu Ostern wieder nach Hause). Werd das ganze dann nächsten Monat testen.

    Noch was,


    eine solche schleichende Verschlechterung kann zwar theoretisch an allem Möglichen liegen (z.B. Softwareupdates auf der Dream oder anderen beteiligten Komponenten, die sich über die Zeit so akkumulieren) - aber bei einem NAS ist das Erste, worauf man gucken müsste, natürlich die Platten-I/O. Wir haben da ja rotierenden Rost und darauf irgendwelche Filesysteme, und all das verändert sich mit der Zeit. Platten können "matschige Stellen" entwickeln, an denen die Zugriffe viel länger dauern als üblich, und der Effekt träte nur ein, wenn ein Lesevorgang über so eine Stelle stolpert. Dann hat er aber deutliche Auswirkungen und "rippelt" durch die anderen gerade stattfindenden Vorgänge, provoziert also u.U. neue Lücken in gerade geschriebenen Streams. In abgeschwächter Form passiert sowas auch gern mal auf rein logischer Ebene - Filesysteme fragmentieren. Anfangs stört das kaum, aber je mehr es den Freespace in ein Sieb verwandelt, umso mehr schaukelt sich das hoch. Gerade das Zugriffsmuster eines PVR (große Files schreiben, warten bis FS fast voll, dann einige davon Löschen damit wieder etwas Platz wird, Rince & Repeat) zersägt den Freespace nach ein, zwei Jahren gründlich. Dazu kommt, dass mehrere parallel geschriebene Streams schnell zu Interleave-Fragmentierung führen. Ich habe hier auf meiner XFS-Platte in der 7020HD schon Aufnahmen gehabt, die in >20000 Fragmenten vorlagen. Würde ich nix dagegen tun (regelmäßiges xfs_fsr) dann würde wohl auch hier die I/O langsam in Richtung Random Access driften, und dann wird es bei rotierendem Rost sehr schnell sehr lahm (im Worst Case deutlich unter 1MB/s).


    Falls Dein NAS eine Shell hat und XFS benutzt (beides würde ich erwarten, kenn das Teil aber nicht persönlich), dann mal drauf einloggen und xfs_fsr -v laufen lassen - da sieht man sehr schnell, was Sache ist.


    HTH,
    Andre.

    Hmm, also zur vorliegenden Symptomatik würde diese Theorie schon gut passen. Trotzdem wundert mich es etwas. Mit dem massiven Performance-Überschuss, der eigentlich vorhanden ist, sollte solche kleine Verzögerungen ja normal kaum ins Gewicht fallen. Vor allem müsste sich die Dreambox auch nicht jedes mal so massiv aufhängen. Ich hab manchmal im Extremfall 5 Minuten lang ein Standbild, kann aber in unter einer Minuten denselben Film komplett auf den Computer rüberziehen.


    Hat die Dreambox beim Lesen oder Schreiben eigentlich einen Puffer, bzw. könnte man da einen einrichten?



    Shell-Zugriff hätte ich (sogar jetzt, wo ich nicht zu Hause bin). Das NAS nutz aber kein XFS, sondern ext4. Das ganze übrigens mit 5 Festplatten, die als RAID-5 arbeiten.
    Das mit ext4 fällt mir übrigens jetzt, wo ich nochmal explizit danach geschaut hab, erst auf. Hatte gedacht, es wäre ext3, hab aber bei der Installation offenbar doch ext4 gewählt. Ob es wohl daran liegen könnte? :face_with_rolling_eyes:

    Zitat

    Originally posted by Adler313
    Vor allem müsste sich die Dreambox auch nicht jedes mal so massiv aufhängen. Ich hab manchmal im Extremfall 5 Minuten lang ein Standbild, kann aber in unter einer Minuten denselben Film komplett auf den Computer rüberziehen.


    Das kann dann nicht mehr wirklich fragmentierungsbedingt sein - ich hab auch noch mal Dein erstes Post Revue passieren lassen - nee, diese massiven und extrem langen Aussetzer mit blockiertem E2 Main Thread (Spinner) sprechen eine andere Sprache. Kann eigentlich nur passieren, wenn E2 da ewig in einem read(2)-Systemcall festhängt. Da hilft dann wohl wirklich nur strace und der Sniffer. BTW, kann die Dream das NAS noch pingen, während gerade so ein Aussetzer passiert?


    Zitat

    Hat die Dreambox beim Lesen oder Schreiben eigentlich einen Puffer, bzw. könnte man da einen einrichten?


    Lesen und schreiben geht durch den normalen Linux Buffer Cache, wobei E2 da AFAIR einiges über Hints per posix_fadvise(2) optimiert (z.B. muss der Lesestrom nicht gecached werden, da die Blöcke sehr wahrscheinlich nicht so bald ein zweites Mal gebraucht werden). Ein expliziter Read-Ahead-Buffer wie beim Streaming ist bei der Wiedergabe von Aufnahmen AFAIK nicht vorgesehen oder zumindest nicht parametrisierbar - kann mich da aber auch irren, hab den Code bisher nicht näher angeguckt.


    Zitat

    Shell-Zugriff hätte ich (sogar jetzt, wo ich nicht zu Hause bin). Das NAS nutz aber kein XFS, sondern ext4. Das ganze übrigens mit 5 Festplatten, die als RAID-5 arbeiten.
    Das mit ext4 fällt mir übrigens jetzt, wo ich nochmal explizit danach geschaut hab, erst auf. Hatte gedacht, es wäre ext3, hab aber bei der Installation offenbar doch ext4 gewählt. Ob es wohl daran liegen könnte? :face_with_rolling_eyes:


    Kaum, ext4 ist hinsichtlich der Performance auf Augenhöhe mit XFS, da macht man wenig verkehrt. Es wird auf der Dream selbst nicht für das Filesystem für die Aufnahmen empfohlen, aber das beruht wohl auf Ressourcenproblemen, die auf der schwachbrüstigen Hardware zu Tage treten. Auf dem Umweg über NFS sollte man davon nichts mehr merken - Extent Addressing ist auf jeden Fall effektiver als Block Addressing, daher ist ext3 IMO kein Thema, wenn man ext4 haben kann.


    Was Fragmentierung angeht: es gibt neben filefrag und e2freefrag zum Begutachten der Lage auch ein Tool e4defrag in den aktuellen e2fsprogs. Ich habe damit aber bisher keinerlei praktische Erfahrung, weiß also nicht wie sicher und zuverlässig man das auf seine Datenhalde loslassen kann. Aber wie gesagt, die Phänomene die Du da zum Teil hast lassen sich IMO nicht mehr mit Fragmentierung erklären. Vieles kurzes Gefreeze und Geruckel ja, aber keine 3min oder länger Standbild...


    HTH,
    Andre.