Update: Optimierter av7110 Treiber

  • Quote


    Tritt das Problem eigentlich bei allen Transpondern auf? Bei DVB-C kommt mir immer die Phrase "gestörter Empfang" in den Sinn. unglücklich


    Ich hab s nicht bis zum Ende durch getestet, aber nein. Ich habe das Problem ausschließlich auf ARD.


    TomJoad
    Und Danke. Ich hab schon gedacht ich wär der einzige mit dem Problem.

    Registered VDR User #841
    P4 1.7, 256 MB Ram, 200 GB Samsung, TT DVB-C 2.1, TT DVB-C 1500, VDR Extension Board, 12.1" TFT, Pearl Mod-It Gehäuse  
    Suse 10, Kernel 2.6.13-15.11-default, VDR 1.4.2-BP

  • @ UFO:


    Es gibt einige Rückmeldungen zu meinem LinVDR-Kernelpaket 2.6.20, wonach die FF-Karte deutlich schlechter läuft als noch beim 2.6.18 ("gpioirq DMA RX buffer overflow").
    In beiden Fällen sind hg Treiber mit Deinen performance-Patches drin, beim 2.6.18 vom 21.01, beim 2.6.20 vom 18.02.


    Außer der Kernelversion ist der Unterschied, dass ich beim 2.6.20 die neue Option 300Hz statt 250Hz Timerfrequenz ausgewählt habe (soll performanter sein).


    Die testweise Herausnahme der performance-Patches hat bei den betroffenen Usern eine Besserung gebracht, aber das System wird weiter als träge beschrieben.


    PK21 schreibt

    Quote

    32131 Interrupts produziert der saa7146 momentan pro Minute? (laut /proc/interrupts - 2.6.20)
    Ich hab jetzt keine Ahnung ob das viel oder wenig ist.


    Gibt es sonst irgendwelche signifikanten Änderungen im hg in der genannten Zeit, die die Probleme auf manchen Rechnern erklären könnten?

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Quote

    Original von kilroy
    Ein paar weitere Tests haben ergeben, daß ich derzeit mit

    Code
    1. #define DMA_RX_BUFS 16 /* RX transfers */

    keine Aussetzer beim timeshift bei ARD und ZDF mehr habe.
    ...


    Momentan mit

    Code
    1. #define DMA_RX_BUFS 12 /* RX transfers */

    stellt sich die Lage so dar, daß timeshift gut funktioniert. Auffällig ist nur, daß ich beim Abspielen
    von Aufnahmen sporadisch kurze Tonaussetzer habe. Der Verstärker wechselt seine Audioanzeige
    dann auch kurz zu "kein Signal". Im Log findet sich dazu leider nichts passendes. Die Aufnahme
    ist aber in Ordnung. Wenn ich die gleiche Stelle noch einmal abspiele, gibt es keinen Aussetzer.
    Lohnt es, mal den debug Wert des dvb_ttpci zu setzen?



    Jemand sprach die Interrupts an:

    Code
    1. zaphod:~$ grep "saa7146 (0)" < /proc/interrupts && uptime
    2. 12: 6936814 XT-PIC-XT saa7146 (0)
    3. 12:02:48 up 1:15, 3 users, load average: 0.25, 0.47, 0.56


    Da helau es gerade erwähnt:

    Code
    1. zaphod:~# grep CONFIG_HZ /boot/config-2.6.20 | grep -v "^#"
    2. CONFIG_HZ_1000=y
    3. CONFIG_HZ=1000
  • Quote

    Original von Dr. Seltsam
    Es gibt einige Rückmeldungen zu meinem LinVDR-Kernelpaket 2.6.20, wonach die FF-Karte deutlich schlechter läuft als noch beim 2.6.18 ("gpioirq DMA RX buffer overflow").
    In beiden Fällen sind hg Treiber mit Deinen performance-Patches drin, beim 2.6.18 vom 21.01, beim 2.6.20 vom 18.02.


    Außer der Kernelversion ist der Unterschied, dass ich beim 2.6.20 die neue Option 300Hz statt 250Hz Timerfrequenz ausgewählt habe (soll performanter sein).


    Hier läuft HZ=1000.


    Quote


    Die testweise Herausnahme der performance-Patches hat bei den betroffenen Usern eine Besserung gebracht, aber das System wird weiter als träge beschrieben.


    Treibermäßig fallen mir folgende größere Änderungen ein:
    - Umstellung des saa7146-I2C-Zugriffs auf Interrupt-Modus
    - Optimierung Stufe 2


    Um herauszufinden, woran es liegt, müßte man systematisch vorgehen:
    Kannst Du einen neuen Kernel mit altem Treiber bauen?
    Dann wüßten wir, ob es am Kernel oder am Treiber liegt.


    Die RX Overflows kann man vermutlich mit DMA_RX_BUFS auf 12 (av7110.h) beseitigen. Dazu hätte ich jedoch gern mehr Rückmeldungen...


    Was die Interrupt-Last angeht:
    Hardwarebedingt generiert der FF-Treiber wesentlich mehr Interrupts als der Budget-Treiber. Falls die HW also Probleme mit der Interruptverarbeitung hat, wird sich dies zuerst hier zeigen.


    Die Optimierung versucht, einige Interrupts einzusparen. Andererseits steigt die Interruptlast durch die erhöhte Transferrate auch wieder an. Ebenso die Auslastung der RX-Buffer...


    CU
    Oliver


    Edit:
    Mir fällt gerade auf, daß meine letzten Performance-Patches vom 7.1. sind.
    Also müßten doch die Treiber im beiden Kernels identisch sein, oder?


  • Außer höllisch vielen Log-Einträgen dürfte dies nichts bringen.


    Mal ein Schuß ins Blaue:
    Versuche, ob es hilft, in av7110.c SAA7146_USE_I2C_IRQ durch SAA7146_I2C_SHORT zu ersetzen. Damit wird der I2C-Zugriff für FF-Karten wieder auf Polling umgestellt.


    CU
    Oliver

  • Moin UFO,


    Rückmeldungen in Kernel 2.6.20 für LinVDR zufolge läuft ein 2.6.20 erheblich schlechter als ein 2.6.18, wenn in beiden Fällen der gleiche Treiberstand (hg vom 21.01. + 5 performance-patches von Dir) enthalten ist. Da ein Zusammenhang mit Plattenzugriffen zu bestehen scheint, verdächtige ich im Moment den IDE-Controller (neues Modul PATA_VIA statt BLK_DEV_VIA82CXXX).


    wann ist die Umstellung des I2C-Zugriffs auf Interrupt-Modus ins hg eingeflossen? oder ist das Teil der Patches?


    Ich werde dann wohl auch mal auf 1000 Hz umstellen. Gibt es da negative Seiteneffekte (Hitze, Stromverbrauch) ?


    Hast Du selbst auch schon mal 2.6.20 probiert? Vielleicht gibt es da ja Änderungen, die sich mit Deinen performance-Patches beissen. Es gibt nämlich auch Rückmeldungen, dass es bereits ohne die performance-Patches deutlich besser laufen soll.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Quote

    Original von Dr. Seltsam
    Rückmeldungen in Kernel 2.6.20 für LinVDR zufolge läuft ein 2.6.20 erheblich schlechter als ein 2.6.18, wenn in beiden Fällen der gleiche Treiberstand (hg vom 21.01. + 5 performance-patches von Dir) enthalten ist. Da ein Zusammenhang mit Plattenzugriffen zu bestehen scheint, verdächtige ich im Moment den IDE-Controller (neues Modul PATA_VIA statt BLK_DEV_VIA82CXXX).


    Kann ich nix dazu sagen. Ich verwende weder VIA-Chipsätze noch SATA-Platten. Beide stehen unter Verdacht, unter Umständen Probleme zu machen...


    Quote


    wann ist die Umstellung des I2C-Zugriffs auf Interrupt-Modus ins hg eingeflossen? oder ist das Teil der Patches?


    Seit 1.11.2006 im HG-Master. Und damit auch im av7110-refactoring.


    Btw, av7110-refactoring = HG-master + Performance Patches.


    av7110-refactoring enthält keine zusätzlichen Patches. Man kann sich also die Mühe sparen, HG-Master mit den Performance-Optimierungen zu patchen. Habe ich bereits gemacht. :)


    Quote


    Ich werde dann wohl auch mal auf 1000 Hz umstellen. Gibt es da negative Seiteneffekte (Hitze, Stromverbrauch) ?


    Ich denke nicht. Evtl. eine minimal höhere CPU-Last.


    Quote


    Hast Du selbst auch schon mal 2.6.20 probiert? Vielleicht gibt es da ja Änderungen, die sich mit Deinen performance-Patches beissen. Es gibt nämlich auch Rückmeldungen, dass es bereits ohne die performance-Patches deutlich besser laufen soll.


    Hier läuft auch 2.6.20. Keinerlei Probleme damit, läuft weder schneller noch langsamer als 2.6.18. (2.6.19 hatte ich ausgelassen.)


    CU
    Oliver

  • Quote

    Original von UFO
    Versuche, ob es hilft, in av7110.c SAA7146_USE_I2C_IRQ durch SAA7146_I2C_SHORT zu ersetzen. Damit wird der I2C-Zugriff für FF-Karten wieder auf Polling umgestellt.


    Das ergibt:

    Code
    1. /usr/local/src/v4l-dvb-av7110-refactoring/v4l/av7110.c:3011: error: 'SAA7146_I2C_SHORT' undeclared here (not in a function)

    Ist es vielleicht dieser: SAA7146_I2C_SHORT_DELAY?

  • Quote

    Original von kilroy


    Das ergibt:

    Code
    1. /usr/local/src/v4l-dvb-av7110-refactoring/v4l/av7110.c:3011: error: 'SAA7146_I2C_SHORT' undeclared here (not in a function)

    Ist es vielleicht dieser: SAA7146_I2C_SHORT_DELAY?


    Ja, sorry.


    CU
    Oliver

  • Hallo Leute!


    Kann mir einer vielleicht irgendwie einfach den unterschied zwischen CONFIG_HZ=1000 oder 250 erklären? Was tu sich da, oder was ist anders, was für timer ist das ? Nicht hauen, finde nicht genau was das bedeutet. Habs heute auch mal mit 300 probiert, sehe da kein unterschied.


    gruß
    lattensepp

    VDR: Intel DH77EB, i3-2125, 8 GB RAM, Debian Wheezy, Microsoft MCE Remote, Silverstone LC20 Black
    REST: Infocus IN8601 1920x1080 Projektor, Denon AVC-A1XVA, DENON DVD-A1XVA, 2x "AUDIMAX" Selbstbau, 4x Magnat Dipol 5, 1x Magnat Center 5, 1x "the bigONE" Woofer, Leinwand Möbelplatte 240x180cm...!

  • Morgen


    Mal eine etwas andere Frage, wie kann man bei den Drivern, das videmode=2 mit übergeben?


    Laden geschieht hier wie folgt.


    Code
    1. shell> make -C /usr/local/src/DVB/v4l load


    ----


    Später, ok schon erledigt (modules.conf)


    Code
    1. options dvb-ttpci vidmode=2


    MFG Ronny

  • Hallo Oliver,


    Quote

    Versuche mal, ob das Erhöhen der DMA_RX_BUFS die Fehlermeldungen unter Last verschwinden läßt.


    Habe ich noch auf dem zettel. Der geänderte treiber läuft schon seit eine woche, ich komme zeitlich nur nicht dazu es zu testen.


    Dann ein kleines danke schön für die gute arbeit bei den treibern :] Bei mir ist gestern abend der ARM zum ersten mal seit langem abgestürtzt :

    Code
    1. Mar 8 21:24:24 vdr kernel: dvb-ttpci: ARM crashed @ card 0


    Der Replay der lief ist hinterher weitergelaufen, einfach klasse :)


    Gruß
    Viking

  • [in av7110.c SAA7146_USE_I2C_IRQ durch SAA7146_I2C_SHORT_DELAY ersetzen]


    Huh, hier fehlt noch die Antwort.


    Die Interrupts scheinen reduziert (pro Sekunde):

    Code
    1. zaphod:~$ echo $(( $(grep "saa7146 (1)" < /proc/interrupts | tr -s [:blank:] " " | cut -f3 -d" ") / $(cat /proc/uptime | cut -f1 -d".") ))
    2. 615

    Allerdings beschwert "die Familie" sich immernoch über Tonaussetzer. Diese treten scheinbar
    immer auf, sprich sowohl beim live gucken (mit und ohne Transfermode), als auch bei Aufnahmen.
    Ich muß das nochmal verifizieren, da ich relativ wenig fern sehe und dann meist per Stream. ;)

  • Mift - warum bekomme ich jetzt wieder?

    Patchstand ist:
    SAA7146_USE_I2C_IRQ durch SAA7146_I2C_SHORT_DELAY ersetzt
    #define DMA_RX_BUFS 12 /* RX transfers */
    av7110-dump-rx.diff

  • Hi Oliver,


    irgendwie komm ich grad beim Kernelbauen nicht weiter. Habe den 2.6.20.4 gezogen und per makelinks.sh die refactoring-Treiber eingelinkt.


    Die dabei erstellte compat.h macht wohl irgendwie Probleme:



    Hast du ne Idee?


    Grüße & Danke
    Michi

    Wohnzimmer: Techsolo TC-400 :: ASUS P5N7A-VM :: Intel Core 2 Duo E7400 :: GeForce 9300 onboard :: vdr 1.7.15 e-tobi ::
    In Rente: Pimped Scenic 600 (Bilder und Aufbau) :: PIII 600Mhz :: Hauppauge Nexus-S 2.1 4MB :: vdr 1.5.2 e-tobi ::


    "Wer denkt, dass Volksvertreter das Volk vertreten, der glaubt auch, dass Zitronenfalter Zitronen falten." Zeit zum ändern!

  • Quote

    Original von skiller2k1
    irgendwie komm ich grad beim Kernelbauen nicht weiter. Habe den 2.6.20.4 gezogen und per makelinks.sh die refactoring-Treiber eingelinkt.


    Die dabei erstellte compat.h macht wohl irgendwie Probleme:


    Hast du ne Idee?


    Eigentlich sollte man den Kernel nicht mit den Sourcen von linuxtv.org vermischen. Im Kernel einfach alles bis auf 'DVB For Linux' abwählen und dann die DVB-Treiber in einem separaten Verzeichniss erstellen. Das setzt alledings vorraus, daß man die DVB-Driver unter dem neuen Kernel kompiliert.


    Gruß
    e9hack

  • Quote

    Original von e9hack
    Eigentlich sollte man den Kernel nicht mit den Sourcen von linuxtv.org vermischen. Im Kernel einfach alles bis auf 'DVB For Linux' abwählen und dann die DVB-Treiber in einem separaten Verzeichniss erstellen. Das setzt alledings vorraus, daß man die DVB-Driver unter dem neuen Kernel kompiliert.


    Hmm. Bisher hab ich das aber immer so gemacht und nie derartige Probleme gehabt.


    Grüße
    Michi

    Wohnzimmer: Techsolo TC-400 :: ASUS P5N7A-VM :: Intel Core 2 Duo E7400 :: GeForce 9300 onboard :: vdr 1.7.15 e-tobi ::
    In Rente: Pimped Scenic 600 (Bilder und Aufbau) :: PIII 600Mhz :: Hauppauge Nexus-S 2.1 4MB :: vdr 1.5.2 e-tobi ::


    "Wer denkt, dass Volksvertreter das Volk vertreten, der glaubt auch, dass Zitronenfalter Zitronen falten." Zeit zum ändern!

  • Gegenüber früher fehlen in der ...refactoring/v4l/compat.h

    C
    1. #include <linux/i2c-id.h>
    2. #include <linux/pm.h>
    3. #include <linux/version.h>
    4. #include <linux/utsname.h>
    5. #include <linux/sched.h>


    Wenn man die einfügt, geht es wieder - offiziell ist aber wohl die Antwort von e9hack

    vdr-2.6.1

    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • Quote

    Original von TomJoad
    Gegenüber früher fehlen in der ...refactoring/v4l/compat.h

    C
    1. #include <linux/i2c-id.h>
    2. #include <linux/pm.h>
    3. #include <linux/version.h>
    4. #include <linux/utsname.h>
    5. #include <linux/sched.h>

    Wenn man die einfügt, geht es wieder - offiziell ist aber wohl die Antwort von e9hack


    Danke! Scheint durchzulaufen.


    Da ich mir Kernelpackages baue, kommt die Lösung mit im nachinein DVB-Treiber kompilieren und per make install "drüberballern" für mich nicht in Frage.


    Grüße
    Michi


    EDIT: Wohl zu früh gefreut:


    Wohnzimmer: Techsolo TC-400 :: ASUS P5N7A-VM :: Intel Core 2 Duo E7400 :: GeForce 9300 onboard :: vdr 1.7.15 e-tobi ::
    In Rente: Pimped Scenic 600 (Bilder und Aufbau) :: PIII 600Mhz :: Hauppauge Nexus-S 2.1 4MB :: vdr 1.5.2 e-tobi ::


    "Wer denkt, dass Volksvertreter das Volk vertreten, der glaubt auch, dass Zitronenfalter Zitronen falten." Zeit zum ändern!