fadvise wirklich nötig?

  • Beim Abspielen einiger Aufnahmen (insbesondere bei HD) auf einem Raspberry Pi (2), bei dem das Video-Directory via NFS gemountet ist, ist mir aufgefallen, dass der schnelle Vor- und Rücklauf extrem ruckelig ist. Für Sekundenbruchteile läuft es schnell, dann steht es wieder eine halbe bis ganze Sekunde, dann läuft es wieder kurz und so weiter. Nachdem ich in tools.c die Zeile


    #define USE_FADVISE


    auskommentiert hatte, liefen schneller Vor- und Rücklauf wieder flüssig.

    In der Datei INSTALL steht diesbezüglich ja


    Code
    If your video directory is mounted via a Samba share, and you are experiencing
    problems with replaying in fast forward mode, you can comment out the line
    #define USE_FADVISE
    in the file tools.c, which may lead to better results.

    Nun habe ich zum Vergleich die Wiedergabe auf einem VDR mit direkt gemountetem Video-Verzeichnis probiert und schneller Vor-/Rücklauf funktioniert absolut flüssig (Ausgabe über softhddevice), mit und ohne fadvise


    Da ich natürlich gerne möchte, dass VDR möglichst "out of the box" unter allen Umständen gut funktioniert, frage ich mich, ob es überhaupt Situationen gibt, wo fadvise wirklich etwas bringt. Daher die Bitte an euch, VDR mal ohne "#define USE_FADVISE" zu übersetzen und zu schauen, ob das einen Unterschied beim schnellen Vor-/Rücklauf macht.


    Klaus

  • Hallo Klaus,


    um sicher zu gehen: Ich habe das wie folgt auskommentiert:


    tools.c, Zeile 1765

    Code
    //#define USE_FADVISE

    In Verbindung mit softhddevice und vdpau kann ich keinen Unterschied feststellen. Test mit vaapi folgt später.


    Stefan

  • Hier ging es ja auch um SMB/NFS Shares, nicht um softhddevice.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Hallo Klaus,


    ich habe deine Änderung auf RPi2 und RPi3 laufen und es gibt mit beiden eine Verbesserung.

    Die Aufnahmen sind per NFS eingebunden.

    Mit dem Server konnte ich es noch nicht testen, da am Aufnehmen.


    Hier ging es ja auch um SMB/NFS Shares, nicht um softhddevice.

    Die Frage ist, ob jemand Nachteile durch das Entfernen der Funktion hat.

  • 9000H: thanks for the link.


    Ich habe inzwischen etwas nachgelesen. Die Verwendung von posix_fadvise() wurde damals (vor mittlerweile fast dreizehn(!) Jahren) ja eingebaut, um zu verhindern, dass der Filesystem-Cache mit Daten vollgeschrieben wird, die im nächsten Moment nicht mehr gebraucht werden, und dadurch u.U. andere Daten verdrängt werden. Es also einfach so abzuschalten ist sicher nicht der richtige Weg. Auf der anderen Seite leidet die flüssige Wiedergabe im schnellen Vor-/Rücklauf darunter in manchen Konstellationen halt doch erheblich.


    Ich werde daher, wie im beiliegenden Patch, vorerst mal das fadvise beim Lesen (also bei der Wiedergabe) defaultmäßig abstellen. Dazu habe ich das Macro USE_FADVISE in USE_FADVISE_READ und USE_FADVISE_WRITE aufgeteilt, mit entsprechenden Vorbelegungen.


    Langfristig wäre es natürlich schön, wenn fadvise auch bei der Wiedergabe sinnvoll nutzbar wäre, denn auch da macht es nicht viel Sinn, die Daten länger als nötig im Cache zu haben und dadurch evtl. anderes zu verdrängen und die System-Performance zu beeinträchtigen. Dazu müsste sich aber mal jemand, der sich damit besser auskennt, cUnbufferedFile::Read() näher anschauen. Vielleicht sind ja auch bloß die verwendeten Zahlenwerte nicht mehr ganz zeitgemäß:


    readahead = KILOBYTE(128);

    #define FADVGRAN KILOBYTE(4)

    #define READCHUNK MEGABYTE(8)

    if (readahead < Size * 32) { // automagically tune readahead size.

    readahead = Size * 32;


    Ich würde mich über Input hierzu freuen.


    Klaus

  • Hi,


    kls

    hat jetzt zwar mit FADVISE nichts zu tun aber ist Dir der hohe iowait bei UHD livetv aufgefallen der wahrscheinlich das satip plugin aus dem tritt bringt.


    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Meine Meinung zum Thema POSIX_FADV_DONTNEED:

    • Selbst winzigste Rechner haben heute vergleichsweise riesige Hauptspeicher, da ist nichts knapp.
    • Linux macht heutzutage einen guten Job bei der Verwaltung der Buffer. Ein "Hineinpfuschen" in die Automatik triggert nur schlecht getestete Code-Pfade mit eher negativen Folgen fuer die Performance. Das gilt besonders bei komplizierteren Speichersystemen (RAID, NFS, Samba,...).
    • Wenn man unbedingt die Daten aus dem Speicher werfen will, sollte man sich auch sicher sein, diese nicht mehr zu brauchen. Genau das gilt hier nicht: bereits verarbeitete Daten kann man u.U. wieder brauchen, z.B. beim Springen oder schnellen Ruecklauf. Geschriebene Daten braucht man z.B. dann wieder, wenn man so viel Werbung uebersprungen hat, dass man das Ende der laufenden Aufnahme bei der Wiedergabe einholt. Da gibt es momentan auch seltsame Effekte.
    • Ist es wirklich ein wichtiger Anwendungsfall, den vdr auf einem Rechner zu betreiben, der als Hauptaufgabe als Fileserver fuer jemand anderen fungiert und wo man moeglichst Daten von anderen Anwendungen im Speicher halten will? Ich denke nicht.
    • Die sync- (insbesondere) und advice-System-Calls kosten selbst jede Menge Performance.

    Konsequenz: Ich bin fuer komplettes Entfernen aller POSIX_FADV_DONTNEED.


    Gruss,

    S:oren

  • Mit UHD habe ich noch nicht wirklich was gemacht. Meine softhddevice-Installation ist noch immer sehr "rundimentär", da ich diesen PC noch nicht zum Kucken verwende, sondern nur als Aufnahmeserver.


    Klaus

    • Konsequenz: Ich bin fuer komplettes Entfernen aller POSIX_FADV_DONTNEED.

    Im Prinzip hätte ich da auch nichts dagegen. Die Notwendigkeit dafür ist immerhin mehr als ein Jahrzehnt her. Heute haben selbst kleine VDRs (Raspberry Pi) schon Gigabytes an Speicher. Aber das würde ich dann gerne erst nach der Version 2.4 anpacken, denn für so einen grundlegenden Eingriff sind wir jetzt zu nah an einer neuen Stable ,-).


    Klaus

  • Also hier am älteren Notebook mit xineliboutput und OHNE Hardwarebeschleunigung macht es beim schnellen Vorlauf keinen Unterschied (der schnelle Rücklauf funktioniert vermutlich wegen meiner Hardware oder dem Plugin nicht richtig).

    Ich habe inzwischen etwas nachgelesen. Die Verwendung von posix_fadvise() wurde damals (vor mittlerweile fast dreizehn(!) Jahren) ja eingebaut

    Und hatte wie es ausssieht die ganze Zeit einen Fehler der erst seit Kernel 4.7 behoben ist:

    https://git.kernel.org/pub/scm…8e9f6d8d446427d8b7691c194


    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!