Optimierung des Datendurchsatzes (Wiedergabe / Transfermode / OSD) auf TT S2-6400

    Bei mir das gleiche mit den Bildfehlern:


    Ein Problem mit dem Laden der Module hatte ich noch nie!!!


    OSD ist immer in allen Varianten ok



    Board:Asus E35M1-I DELUXE Integrated AMD Dual-Core Processor E-350 with AMD Radeon™ HD 6310 Graphics
    TVcard: TT s2-6400
    Distri: MLD
    BIldquelle: zdf hd ~12M


    EDIT: Muss im dvbhddevice noch etwas eingestellt sein/werden?

    ------
    Hardware: ASUS E35M1-I Deluxe, 4GB RAM, ATI on Board (fuer Kodi), TT S2-6400 FF, Samsung 500GB 2,5"
    VDR: MLD5

    Einmal editiert, zuletzt von paulpanther ()

    Zitat von PaulPanther

    Bei mir das gleiche mit den Bildfehlern

    Ach verdammt!


    Das ist eine AMD E-350 CPU, 2 logische Kerne. Ueberraschend niedrige CPU-Last fuer 12 MBit/s, wow!
    Edit: Was ich vergessen hatte: x86_32 oder x64?


    Im Moment habe ich keine Idee, wo die Bildfehler herkommen koennten. phi_mode 0 ist uebrigens auch eine sinnvolle Einstellung, entspricht etwa der bisherigen Treiber-/FPGA-Kombination (ist evt. ein klein wenig schneller).


    Gruss,
    S:oren

    Da es laenger keine Meldungen mehr gab, hier mal eine Zusammenfassung des aktuellen Standes.
    Nach eigenen Messungen und Feedback von anderen Usern sieht es fuer mich so aus: Auf ARM und x86_64 funktionieren immer alle phi_mode-Werte, auf x86_32 haben CyberChris und PaulPanther mit phi_mode 3 bis 5 Bildstoerungen, die ich leider bei mir nicht nachvollziehen kann. Sowohl auf einem Via C7 als auch auf einem extra neu aufgebauten Testrechner mit Core-2-Duo sehe ich keinerlei Problem. Ich kann also nichts weiter testen, wenn jemand noch ein Problem hat und weitere Patches ausprobieren moechte, kann er mir gerne eine E-Mail schreiben...


    Da es mit den Standardeinstellungen (phi_mode=0, phi_clk=0) keinerlei Stoerungen oder andere Verschlechterungen durch den Patch gibt, sehe ich diesen Entwicklungsstand hier erstmal als final an. Hoehere Werte fuer phi_mode und phi_clk sollte man eben nicht einstellen, wenn es damit Stoerungen gibt. Ansonsten sind Durchsatzsteigerungen ueber Faktor 4 moeglich, mit entsprechend geringerer CPU-Last. Das bringt natuerlich besonders bei Single-Core-CPUs Vorteile.


    Ich bin mir aber trotzdem nicht sicher, ob der Patch in dieser Form mit den vielen Einstellmoeglichkeiten in den "offiziellen" Treiber uebernommen werden sollte...


    Gruss,
    S:oren

    Hallo S:oren,


    leider konnte ich in der letzten Zeit nicht mehr so intensiv testen.
    Mein Fazit bisher ist: alle phi_mode mit den phi_clk 0 und 1 sind bei mir uneingeschränkt einsetztbar, phi_clk 2 ist bei mir bei allen phi_mode mit sporadischen Fehlern (Menü, Bild und Reset) verbunden.
    Als Standarteinstellung hatte ich seit meinem letzten Beitrag phi_mode=3 und phi_clk=1, damit war ein Betrieb ohne nennenswerte Probleme möglich.


    Da sich mit Deiner neuen Firmware/Treiber-Kombination meine Kaltstartprobleme soweit erledigt haben, würde ich einen produktiven Einsatz befürworten.


    Zitat von S:oren

    Ich bin mir aber trotzdem nicht sicher, ob der Patch in dieser Form mit den vielen Einstellmoeglichkeiten in den "offiziellen" Treiber uebernommen werden sollte...


    Naja, das wäre ja nicht der einzige Treiber, der über Parameter konfigurierbar ist. Wenn das entsprechend in der README beschrieben ist und ohne zusätzlichem Parameter stabil läuft, sollte das doch kein Problem sein.


    Wenn ich das richtig verstanden habe, sonst korrigiere mich bitte, bedeutet - kein Parameter = phi_moe 0 und phi_clk 0 - und das entspricht in etwa dem wie es vorher war. Also verhält es sich doch immer prinzipiell erst einmal so wie vorher.


    Gruß


    Karl

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5

    leider konnte ich in der letzten Zeit nicht mehr so intensiv testen.

    Bei Dir ist ja soweit auch alles klar...


    Zitat von kamel5

    Mein Fazit bisher ist: alle phi_mode mit den phi_clk 0 und 1 sind bei mir uneingeschränkt einsetztbar, phi_clk 2 ist bei mir bei allen phi_mode mit sporadischen Fehlern (Menü, Bild und Reset) verbunden.

    Ob phi_clk=2 noch funktioniert ist rein eine Eigenschaft des individuellen PCIe-Chips auf der Karte, hat nichts mit dem Treiber an sich oder dem FPGA zu tun. Bei dieser Einstellung wird zusaetzlich zu phi_clk=1 ein interner Takt in der Bridge erhoeht. Leider steht in dem mir vorliegenden Datenblatt der Bridge nur drin, wie man die Takte einstellt und was der Standardtakt ist, nicht welche Takte maximal zulaessig sind (da steht nur: kann auch mit mehr als dem Standardtakt funktionieren, tolle Aussage). Muss man also probieren, wenns nicht zuverlaessig laeuft, dann nicht benutzen.


    Zitat von kamel5

    Da sich mit Deiner neuen Firmware/Treiber-Kombination meine Kaltstartprobleme soweit erledigt haben, würde ich einen produktiven Einsatz befürworten.

    Hoert sich sehr gut an. Am Treiberpatch wirds nicht liegen, kann aber schon sein, dass das neue FPGA-Design stabiler funktioniert. (kannst Du ggf. ja mal mit dem alten Treiber testen, das neue FPGA sollte auch damit funktionieren, nur eben nicht schneller, aber vielleicht trotzdem stabiler)


    Zitat von kamel5

    Wenn ich das richtig verstanden habe, sonst korrigiere mich bitte, bedeutet - kein Parameter = phi_moe 0 und phi_clk 0 - und das entspricht in etwa dem wie es vorher war. Also verhält es sich doch immer prinzipiell erst einmal so wie vorher.

    Ja, ohne spezielle Parameter wird phi_mode=0, phi_clk=0 benutzt. Damit funktioniert alles aehnlich wie frueher, nur etwas schneller - Du hattest ja 13% zu 10% CPU-Last gemessen...


    Gruss,
    S:oren

    Nachdem der erste (unspannende) Teil des Patches uebernommen wurde, ist hier eine neue Patchversion passend zum aktuellen Repository.


    Ich habe den Patch noch etwas vereinfacht, es gibt jetzt keinen phi_clock-Parameter mehr, nur noch phi_mode. Fuer phi_mode gibt es auch nur noch 3 Einstellmoeglichkeiten:
    0 - Verhalten wie ohne Patch
    1- schnellerer PHI-Takt
    2 - schnellerer PHI-Takt und Write-Combining


    Fuer die schnellen Modi braucht man nach wie vor die FPGA-Firmware von hier.


    Noch ein Hinweis: Ein Umschalten des phi_mode zur Laufzeit funktioniert nicht mehr zuverlaessig.


    Gruss,
    S:oren

    Hallo S:oren,


    ich habe den aktuellen Treiber mit dem letzten Patch jetzt ein paar Tage im Einsatz und kann bestätigen, das er bei mir prinzipiell gut funktioniert.


    Die ersten Tage habe ich mit phi_mode=2 getestet, zur Zeit läuft es mit phi_mode=1.


    Folgenden Effekt habe ich mit phi_mode=2 festgestellt (bei phi_mode=1 bisher noch nicht aufgetreten):
    Nach längerem Verbleib (mehrere Stunden) auf einem Kanal, fängt der AC3-Ton im Live-View an zu stottern.
    Aufgefallen ist es mir bisher 2x, ein Kanalwechsel hat den Effekt dann wieder behoben.


    Ein vergleichbares Problem habe ich mit dem alten Patch (seit längerem konfiguriert mit phi_mode=4 und phi_clk=1) nicht festgestellt.


    Vielleicht kannst Du zum Verständnis noch kurz schreiben, wie sich die neuen Parameter zu den alten verhalten.


    Gruß
    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5

    Nach längerem Verbleib (mehrere Stunden) auf einem Kanal, fängt der AC3-Ton im Live-View an zu stottern.

    Hm, auf den echten Liveview-Mode hat der Patch keinen Einfluss, da die Daten gar nicht ueber die PCIe-Bridge transferiert werden, sondern direkt vom Tuner/Demod an den Decoder weitergegeben werden.
    Hast Du irgendein spezielles Setup, das den Transfermode fuer Liveview erzwingt?


    Zitat von kamel5

    Vielleicht kannst Du zum Verständnis noch kurz schreiben, wie sich die neuen Parameter zu den alten verhalten.

    Direkt vergleichbar sind die Settings nicht (alle).
    - phi_mode 0 (neu) verhaelt sich exakt wie ohne Patch, also etwas langsamer als phi_clk 0, phi_mode 0 (alt).
    - phi_mode 1 (neu) entspricht etwa phi_clk 1, phi_mode 2 (alt)
    - phi_mode 2 (neu) ist das Gleiche wie phi_clk 1, phi_mode 4 (alt)


    Zitat von kamel5

    Folgenden Effekt habe ich mit phi_mode=2 festgestellt (bei phi_mode=1 bisher noch nicht aufgetreten) [...] Ein vergleichbares Problem habe ich mit dem alten Patch (seit längerem konfiguriert mit phi_mode=4 und phi_clk=1) nicht festgestellt.

    Das sind gerade die Modi, die exakt gleich sind. Vielleicht haengt Dein Problem mit der neuen Decoderfirmware (0.4.1) zusammen, da wurde ja an der AV-Synchonisation geschraubt. Vielleicht ist es auch nur Zufall!?


    Gruss,
    S:oren

    Zitat von S:oren

    Hast Du irgendein spezielles Setup, das den Transfermode fuer Liveview erzwingt?


    Ja, tatsächlich, wenn ich mich jetzt so erinnere, war das bei verschlüsselten Sendern.
    Komisch ist halt nur, das das vorher mit dem alten Patch nicht aufgetreten ist.


    Zitat von S:oren

    Das sind gerade die Modi, die exakt gleich sind. Vielleicht haengt Dein Problem mit der neuen Decoderfirmware (0.4.1) zusammen, da wurde ja an der AV-Synchonisation geschraubt. Vielleicht ist es auch nur Zufall!?

    Decoderfirmware war vorher auch schon die 0.4.1. Naja, so schlimm ist es jetzt auch nicht, wer schaut schon 6h den selben Sender ohne zu zappen. Jetzt läuft es mit phi_mode=1, da ist es mir noch nicht aufgefallen.


    Ich werde das weiter beobachten.


    Gruß
    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    So, die meisten Aenderungen aus meinem Patch sind nun im offiziellen Repository. Es fehlen nur noch ein paar kleine Aenderungen zur Reduzierung der Interrupt-Frequenz und damit der CPU-Load. Die benoetigte neue Firmware-Version ist noch nicht bei powarman gelistet, man kann problemlos die rc2 von hier verwenden...


    Gruss,
    S:oren

    Hallo Sören,
    habe den Treiber heute aktualisiert und ich lade den Treiber nun wie folgt:

    Code
    options saa716x_ff int_type=1 ir_keymap=1 phi_mode=2


    Bisher keine Probleme :D


    Fühlt sich flotter an... Weitere Tests folgen. ;)


    Viele Grüße, Uwe

    Jetzt gibts die neue FPGA Firmware auch offiziell: http://www.aregel.de/vdr/63/ne…firmware-110-fuer-s2-6400

    Zitat

    Es gibt eine neue FPGA Firmware Version 1.10. Diese enthält einige interne Optimierungen, die zusammen mit dem neusten Treiber die Transferrate über den PHI-Bus beschleunigen können, der hauptsächlich für das OSD und Playback benutzt wird. Das sorgt beim Playback für eine Verringerung der CPU-Last. Danke an Sören Moch für die Verbesserungen. Diese Version entspricht 1:1 der bereits seit einiger Zeit im VDR-Portal bereitgestellten 1.10 RC2.

    Seit einigen Minuten ist nun auch der letzte Teil meines Patches im offiziellen Repository. Der sollte nochmal Probleme beim Umschalten zwischen nicht-primaeren Tunern (oder von/auf Wiedergabe) beseitigen.


    Vielen Dank an powarman fuer die Aufteilung, Ueberarbeitung und Test der Patches!! Vielen Dank auch an alle anderen User, die beim Test und der Verbesserung des Patches geholfen haben!


    Gruss,
    S:oren

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden