K6-333 zu langsam für VDR?

  • Mein Igel-J, der ein Mahlzeit-3.2 iso per NFS bootet, ruckelt leider.
    Logread zeigt, dass er immer wieder Bytes wegwirft um synchron zu bleiben.
    Die 333MHz AMD-K6 CPU reicht wohl nicht. Bevor ich mich jetzt auf
    Hardware-Suche begebe und den Zorn des Finanzministers auf mich ziehe,
    frage ich hier noch mal nach, ob hier jemand eine Idee für eine Tuning-Maßnahme hat.


    Ich schrecke auch vorm Kernel umkonfigurieren nicht zurück. Musste ich ja
    sowieso machen um von NFS booten zu können.


    Ich benutze nur den Streamdev-Client-Plugin und den DXR3-Plugin.
    Arbeitet in dieser Konfiguration eigentlich der Livebuffer? Wäre wohl
    kontraproduktiv, da der Streamdev-Client-Plugin wohl eh schon buffert,
    oder?


    Logging abschalten wird wohl nicht viel bringen.


    Es wäre nett wenn Ihr ein paar Ideen hättet.


    Gruß
    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Einmal editiert, zuletzt von gda ()

  • Zitat

    Logread zeigt, dass er immer wieder Bytes wegwirft um synchron zu bleiben.
    Die 333MHz AMD-K6 CPU reicht wohl nicht.


    Das wundert mich doch sehr. Die Arbeit macht die DXR3-Karte. Deine CPU sollte da locker reichen. Was steht genau im Log? Was sagt "top"?

  • @smirl: danke das Du mir Mut machst es nochmal zu versuchen.


    top sagt:


    ein paar Auszüge aus logread:


    Ich nehme an das hat wohl nichts zu bedeuten:

    Code
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 18, 78, 254 not available from 192.168.99.5:2670                                               
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 18, 80, 240 not available from 192.168.99.5:2670                                               
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 18, 96, 240 not available from 192.168.99.5:2670                                               
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 20, 112, 255 not available from 192.168.99.5:2670                                              
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 0, 0, 255 not available from 192.168.99.5:2670                                                 
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 17, 66, 255 not available from 192.168.99.5:2670                                               
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 16, 64, 255 not available from 192.168.99.5:2670


    das wiederholt sich immer wieder:

    Code
    Mar  7 17:01:15 linvdr user.debug vdr: [1127] dxr3: audiodecoder: sample rate=48000                                                                          
    Mar  7 17:01:15 linvdr user.debug vdr: [1127] dxr3: audiodecoder: channels=2                                                                                 
    Mar  7 17:01:16 linvdr user.debug vdr: [1127] dxr3: audiodecoder: sample rate=48000                                                                          
    Mar  7 17:01:16 linvdr user.debug vdr: [1127] dxr3: audiodecoder: channels=2                                                                                 
    Mar  7 17:01:17 linvdr user.debug vdr: [1127] dxr3: audiodecoder: sample rate=48000                                                                          
    Mar  7 17:01:17 linvdr user.debug vdr: [1127] dxr3: audiodecoder: channels=2


    bis es dann durch das hier abgelöst wird:

    Code
    Mar  7 17:01:26 linvdr user.err vdr: [1128] ERROR: skipped 46 bytes to sync on TS packet on device 6                                                         
    Mar  7 17:01:26 linvdr user.err vdr: [1128] ERROR: skipped 21 bytes to sync on TS packet on device 6                                                         
    Mar  7 17:01:26 linvdr user.err vdr: [1128] ERROR: skipped 123 bytes to sync on TS packet on device 6                                                        
    Mar  7 17:01:27 linvdr user.err vdr: [1128] ERROR: skipped 171 bytes to sync on TS packet on device 6                                                        
    Mar  7 17:01:27 linvdr user.err vdr: [1128] ERROR: skipped 89 bytes to sync on TS packet on device 6                                                         
    Mar  7 17:01:28 linvdr user.err vdr: [1128] ERROR: skipped 28 bytes to sync on TS packet on device 6                                                         
    Mar  7 17:01:28 linvdr user.debug vdr: [1127] PES packet shortened to 552 bytes (expected: 2034 bytes)


    Mit unterschiedlichen Zahlenangaben wiederholt sich das immer wieder


    Dmesg zeigt nicht auffälliges:


    Übrigens benutze ich im Moment Kernel 2.6.19.3, weil ich mit 2.6.20 den lirc nicht übersetzt
    bekam. Den dxr3-Treiber habe ich aus dem CVS, weil der stabile mit dem Kernel nicht wollte.
    Lohnt es sich hier vielleicht andere Treiber- Kernel-Versionen auszuprobieren? Allerdings
    sieht es ja so aus, als würde nicht der dxr3-treiber das Problem ist.


    Gruß
    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat
    Code
    PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
     1127 root      25   0 38552  12M  2432 R    31.3  0.0   7:13 vdr
     1128 root      15   0 38552  12M  2432 S    20.3  0.0   4:56 vdr
     1129 root      16   0 38552  12M  2432 R    14.7  0.0   2:24 vdr
     1122 root      15   0 38552  12M  2432 S    13.5  0.0   3:27 vdr
     1121 root      15   0 38552  12M  2432 S     5.5  0.0   0:40 vdr
     1123 root      15   0 38552  12M  2432 S     1.2  0.0   0:08 vdr
     1090 root      15   0 38552  12M  2432 S     0.6  0.0   0:11 vdr


    Das ist in der Tat ein wenig heftig. Wäre mal interessant zu sehen welche Threads das alles sind. Such mal im Log nach Meldungen "thread startet (pid=... tid=...) in denen die PID aus "top" vorkommt. Wie sieht es aus wenn Du einen Sender mit sehr niedriger Bandbreite einstellst (bei DVB-S am besten einen Standbild-Sender raussuchen)? Ist die Last dann ähnlich hoch?


    Zitat

    Ich nehme an das hat wohl nichts zu bedeuten:

    Code
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 18, 78, 254 not available from 192.168.99.5:2670
    ...


    Du hast im streamdev-client die Filter aktiviert. Das ist halbfertiger Code der im Server deaktiviert ist. Kannst Du ausschalten, stört aber auch nicht.


    Zitat

    das wiederholt sich immer wieder:

    Code
    Mar  7 17:01:15 linvdr user.debug vdr: [1127] dxr3: audiodecoder: sample rate=48000                                                                          
    Mar  7 17:01:15 linvdr user.debug vdr: [1127] dxr3: audiodecoder: channels=2                                                                                 
    ...


    bis es dann durch das hier abgelöst wird:

    Code
    Mar  7 17:01:26 linvdr user.err vdr: [1128] ERROR: skipped 46 bytes to sync on TS packet on device 6                                                         
    ...


    Könnte schlechte Empfangsqualität sein (was sagt femon? Kannst Du Aufzeichungen anschauen oder gibt es dann die selben Probleme?). Um auszuschließen das es ein Kernel-Problem ist, würde ich mal das Mahlzeit-ISO testen. Bzgl. LinVDR vielleicht auch mal diesen Thread lesen: Kernel 2.6.20.1 für LinVDR. Da scheint jemand ein ähnliches Problem gehabt zu haben.

  • Zitat

    Such mal im Log nach Meldungen "thread startet (pid=... tid=...) in denen die PID aus "top" vorkommt.


    Mal sehen wann ich dazu komme, meine Frau kommt heute zurück, werde nicht mehr so viel Zeit dafür haben.


    Zitat

    Wie sieht es aus wenn Du einen Sender mit sehr niedriger Bandbreite einstellst (bei DVB-S am besten einen Standbild-Sender raussuchen)?


    Ich hab nur die PVR350 und die DVB-T Karte, getestet habe ich mit dem
    Signal von der PVR. Da ist die Bandbreite ja eh nicht so hoch.


    Zitat

    Ist die Last dann ähnlich hoch?


    Was würde Dir diese Informationen sagen?


    Zitat

    Könnte schlechte Empfangsqualität sein


    Das Bild auf dem Server ist aber Klasse und ruckelt nicht. Die PVR ist ja auch direkt am Kabel angeschlossen. Ein anderer Client mit einem AMD 2800+
    XP streamt das Bild auch völlig ohne Ruckeln.


    Zitat


    Um auszuschließen das es ein Kernel-Problem ist, würde ich mal das Mahlzeit-ISO testen.


    Gut, dann muss ich erstmal wieder eine Platte einbauen. Ist etwas
    tricky, weil ich kein CD-Rom anschließen kann, aber das kriege ich hin.


    Ich frage mich ob es wohl weniger Last wäre, wenn ich statt vdr mit streamdev-client, aaxine auf dem client und libxineoutput auf dem server
    benutzen würde?


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat

    Original von gda
    Übrigens benutze ich im Moment Kernel 2.6.19.3


    Ich habe mit den Kerneln 2.6.19.x (da habe ich allerdings nicht alle probiert) und 2.6.20.x mit der gleichen Konstellation wie du (Streamdev-Client mit DXR3) nur schlechte Erfahrungen gemacht-> Permanentes Ruckeln. Zurück zu 2.6.18 und die Welt war wieder in Ordnung...


    Gruß,
    Holger

  • Zitat

    Zurück zu 2.6.18 und die Welt war wieder in Ordnung...


    Das ist doch mal eine eindeutige Aussage, es gibt also noch Hoffnung.
    Allerdings hatte ich darüber im Dr. Seltsam-Kernel-Thread schon gelesen und
    es hatte ein bisschen was von Voodoo.
    Trotzdem baue ich mir als nächstes erstmal einen Kernel 2.6.18.


    Blöd nur, dass ich den streamdev-plugin auch noch patchen muss damit er
    mich zappen lässt.


    Danke
    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat

    Original von schmirl


    Wäre ein Anhaltspunkt ob Dein System wider erwartens tatsächlich überfordert ist. Aber mit der Info von HolgerR erübrigt sich das vermutlich.


    Das hoffe ich zumindest. Bei mir war der Kernel der einzige Auslöser des Problems. Aber man kann sich ja nicht sein, dass es wirklich das identische Problem ist....


    Gruß,
    Holger


    PS: Der Client sollte dank der DXR3 in der Tat nicht überlastet sein; auch wenn ich selber noch nie einen AMD K6-333 eingesetzt habe...

  • Zitat

    PS: Der Client sollte dank der DXR3 in der Tat nicht überlastet sein; auch wenn ich selber noch nie einen AMD K6-333 eingesetzt habe...


    Sondern? Was war der langsamste Prozessor?


    Ich frage mich ob ein Kernel mit CONFIG_MK6 übersetzt, noch ein bisschen
    was zusätzlich bringt. Welche DXR3-Treiber-Version setzt du ein? Der Thread,
    der mit der DXR3 arbeitet, erzeugt ja die höchste Last.


    Ich kann ja den 2.6.18 Kernel von Dr. Seltsam nicht direkt benutzen,
    weil der nicht von NFS bootet. Außerdem ist der so groß, der Prozessor
    braucht unheimlich lange um ihn zu entkomprimieren. Ich habe viel
    rausgeschmissen. Ich baue ihn deshalb frisch, ohne
    irgendwelche patches, aus vanillla sources. Lediglich Lirc- und Dxr3-Treiber
    kommen dazu.


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat

    Original von gda
    Sondern? Was war der langsamste Prozessor?


    So "tief" bin ich bisher noch nicht runter. Der kleinste Prozessor, mit dem ich die DXR3 als VDR-Ausgabedevice verwendet habe war ein PIII mit 800 Mhz. Damals, als diese Karten auf den Markt kamen (und ich meine gekauft habe) waren solche Taktraten aber noch in weiter Ferne; mein damaliger Rechner war deutlich langsamer.


    Übrigens:
    Im alten Factsheet wird als Mindestvoraussetzung ein Pentium (I) mit 133 Mhz oder vergleichbar genannt. Das bezieht sich zwar auf die Windows-Software, aber als Richtwert bestimmt nicht verkehrt.


    Gruß,
    Holger

  • Kernel 2.6.18 bringts auch nicht :(

    Code
    ~# uname -a
    Linux linvdr 2.6.18.8 #1 PREEMPT Fri Mar 9 11:08:28 CET 2007 i586 unknown


    Interessant ist, dass der transfer thread [1212] und der receiver [1213] die höchste Last
    erzeugen. Die DXR3-Threads kommen zusammen nicht mal auf 20%.


    Ich war so naiv zu glauben, dass hier nur die Daten übers LAN gepumpt werden. Hat
    jemand eine Idee warum diese Threads soviel CPU brauchen?



    Code
    Mar  9 16:39:30 linvdr user.debug vdr: [1206] DXR3 audio output thread started (pid=1206, tid=1206)
    Mar  9 16:39:30 linvdr user.debug vdr: [1207] DXR3 video output thread started (pid=1207, tid=1207)
    Mar  9 16:39:30 linvdr user.debug vdr: [1208] streamdev-client: sections assembler thread started (pid=1208, tid=1208)
    Mar  9 16:39:30 linvdr user.debug vdr: [1209] section handler thread started (pid=1209, tid=1209)
    Mar  9 16:39:30 linvdr user.debug vdr: [1210] LIRC remote control thread started (pid=1210, tid=1210)
    Mar  9 16:39:30 linvdr user.debug vdr: [1211] KBD remote control thread started (pid=1211, tid=1211)
    Mar  9 16:39:30 linvdr user.debug vdr: [1212] transfer thread started (pid=1212, tid=1212)
    Mar  9 16:39:30 linvdr user.debug vdr: [1213] receiver on device 6 thread started (pid=1213, tid=1213)
    Mar  9 16:39:30 linvdr user.debug vdr: [1214] TS buffer on device 6 thread started (pid=1214, tid=1214)


    Gruß
    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Wenn sich sonst keiner mehr meldet... Scheinbar keine Kernel-/Hardware-Spezies unterwegs hier. Vielleicht änderst Du mal den Titel des Threads in Richtung "K6 zu langsam für VDR" um die richtigen anzusprechen. Mit der DXR3 haben die zwei schlimmsten Threads ja nicht direkt zu tun. Und poste mal Deine Kernel-Config - vielleicht fehlt ja nur irgendeine entscheidende Kleinigkeit.


    Folgende Strohhalme hätte ich noch:
    Welche Hz-Zahl hast Du denn im Kernel-Setup gewählt? Bei 1000 könnte ich mir vorstellen, dass das einen langsamen Rechner unnötig belastet => 100 auswählen.


    Vielleicht bremst auch ein Interrupt-Konflikt Dein System aus.


    Viel Glück!

  • Zitat

    Welche Hz-Zahl hast Du denn im Kernel-Setup gewählt? Bei 1000 könnte ich mir vorstellen, dass das einen langsamen Rechner unnötig belastet => 100 auswählen.


    Könnte natürlich sein, aber ich habe im Moment CONFIG_HZ_250=y. Ich bin nicht so sicher
    ob das so viel bringen wird, aber ich kann es mal versuchen.


    Zitat

    Vielleicht bremst auch ein Interrupt-Konflikt Dein System aus.


    Na ja, dann ist kaum was zu machen, Slot wechseln ist schwierig bei nur einem Slot.
    Im Moment, kann ich schlecht testen, musste das Gerät erstmal wieder abbauen,
    der WAF war natürlich zu niedrig. Einen Kernel werde ich aber nochmal bauen.


    Hier meine Kernel-Config:




    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat


    Könnte natürlich sein, aber ich habe im Moment CONFIG_HZ_250=y. Ich bin nicht so sicher ob das so viel bringen wird, aber ich kann es mal versuchen.


    Von 250 auf 100 wird nicht die Welt sein. K6-Support ließe sich im Kernel noch dazuschalten, wird aber wohl auch nicht viel ändern - aber wenn Du eh noch mal neu kompilierst... Ansonsten ist mir in Deiner Kernel-Config nix böses aufgefallen, aber das heißt noch lange nichts :gap.


    Zitat


    Na ja, dann ist kaum was zu machen, Slot wechseln ist schwierig bei nur einem Slot.


    Aber Du kannst im BIOS diverse Komponenten deaktivieren die Du eh nicht brauchst (z.B. Audio, Interrupt für Grafikkarte, ggf. USB, ...). Vielleicht lässt sich im BIOS auch bestimmen welchen Interrupt der Slot bekommt.

  • was für eine Netzwerkkarte hast denn du da drin?


    Wenn es ein Realtek 8139 ist kann es daran liegen.


    Realtek ist ne Billigmarke und benötigt viel CPU-Kraft. Dagegen hat eine 3Com- oder Intelkarte einiges Mehr an Schnickschnack und entlastet den CPU erheblich.


    Datendurchsatz bei 100MBit
    Realtek 2-3 MB
    3Com 7-9 MB


    (Kein Witz selbst so gemessen)

    Wohnzimmer: NUC10I3 - Logitech z-5500 - Panasonic 55" TV - Hauppauge Dual DVB-C Stick - Ubuntu 22.04 LTS - yavdr ansible
    Schlafzimmer: NUC10I3 - LG 42" TV - Hauppauge Dual DVB-C Stick - Ubuntu 22.04 LTS - yavdr ansible

    Streamingserver: -im Aufbau-
    diverse Test Clients: -Raspberry Pi + openelec, i3 mit Geforce1030

  • ollo

    Code
    Du könntest mal den neuen AudioRepacker abschalten, der verursacht wohl mehr Last


    Okay, ich sehe mir mal an was denn der AudioRepacker ist und was er tut.


    Zitat

    2. Du spielst mal die Patches von Con Kolivas ein und läßt den VDR per schedtool mit Realtime Priorität laufen


    Kann ich natürlich versuchen, aber diese Art von Patches sorgen doch meistens nur dafür, dass bestimmte Prozesse Vorrang
    vor anderen bekommen, nur laufen ja gar nicht so viele andere Prozesse die bremsen könnten.


    don-baba

    Zitat

    Wenn es ein Realtek 8139 ist kann es daran liegen.


    Realtek ist ne Billigmarke und benötigt viel CPU-Kraft. Dagegen hat eine 3Com- oder Intelkarte einiges Mehr an Schnickschnack und entlastet den CPU erheblich.


    Ich glaube dir aufs Wort. Ich hatte selber schon Befürchtungen in dieser
    Richtung, denn leider ist es eine Realtek 8139. Nur, was soll ich machen?
    Der Igel-j hat nur einen Slot und da steckt die DXR3 drin, also bin ich
    auf die onboard nic angewiesen. Ein USB-Ethernet-Adapter ist auch keine
    Alternative mit USB 1.1.


    Wird eigentlich die CPU-Zeit, die der Kernel im Karten-Treiber verbringt,
    dem Userspace-Prozess zugeschlagen? Wenn nicht dann müsste doch
    noch was zu machen sein um von den 40% CPU-Zeit runterzukommen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat

    Wenn es ein Realtek 8139 ist kann es daran liegen.


    Ah - daher bei Deinem top die hohe System-CPU-Last. Das kommt von der Realtek!

    Code
    CPU states:  66.1% user,  30.6% system,   0.0% nice,   3.3% idle


    Starte doch mal den HTTP-Port auf Deinem Streamdev-Server und hol Dir einen Stream im TS-Format auf den Client (z.B. mit wget, nc, lynx, ...) ohne dass VDR läuft. Schau Dir dazu die CPU-Belastung an. Daran sollte sich erkennen lassen, wie groß der Einfluß der Realtek-Karte ist und wieviel Luft das System noch hat.

Jetzt mitmachen!

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