VDR, CPU Last bei Aufnahmen reduzieren?

Hallo,

wäre es möglich, die CPU Last des VDR bei Aufnahmen zu reduzieren?

z.B. indem der Index erst nach der Aufnahme generiert wird?

Oder Code / Compiler -Optimierungen?

Wozu braucht der VDR denn die CPU beim Aufnehmen?

Grund der Frage: Mein sheevaplug mit VDR 2.4 hat folgende CPU Lasten:

Quote

Keine Aufnahme: VDR bei 10 %

1 SD Aufnahme: VDR bei 30 % (schwankend, auch mal 40%)

2 SD Aufnahmen : VDR bei 50 %

1 HD Aufnahme: VDR bei 45 %

2 HD Aufnahmen: VDR bei 75 %

Da kommen noch 20% für mediasrv hinzu, damit ist der sheevaplug überlastet .

Display More

~ Markus

Also, TOP sieht so aus:

Quote

top - 10:24:42 up 22 days, 13:10, 1 user, load average: 3.75, 1.58, 0.90

Tasks: 109 total, 1 running, 108 sleeping, 0 stopped, 0 zombie

%Cpu(s): 32.0 us, 62.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 5.5 si, 0.0 st

KiB Mem : 513964 total, 4060 free, 283536 used, 226368 buff/cache

KiB Swap: 499708 total, 495276 free, 4432 used. 205672 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

15796 vdr 20 0 459260 236060 14464 S 71.7 45.9 125:15.28 vdr

508 root 20 0 112016 13504 8248 S 20.6 2.6 6667:01 mediasrv

31082 markus 20 0 8180 3244 2736 R 1.5 0.6 0:00.85 top

Display More

0.0 wa sieht eigentlich gut aus.

Und ja, die Festplatten hängen an dem USB, an dem auch die Empfänger hängen.

Aber: Wenn der USB das Bottleneck ist, warum geht dann die CPU Last vom VDR hoch?

~ Markus

Ich schreibe jetzt mal testweise die Daten auf einen anderen Server. Damit gehen über USB nur noch die 2 DVB Sticks. Die Last sieht etwas besser aus:

Quote

top - 11:04:58 up 22 days, 13:50, 2 users, load average: 5.28, 4.22, 2.89

Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie

%Cpu(s): 36.6 us, 45.8 sy, 0.9 ni, 3.7 id, 0.0 wa, 0.0 hi, 13.0 si, 0.0 st

KiB Mem : 513964 total, 16172 free, 307512 used, 190280 buff/cache

KiB Swap: 499708 total, 495408 free, 4300 used. 181708 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

31386 vdr 20 0 459720 260916 19528 S 69.4 50.8 6:48.67 vdr

508 root 20 0 112016 14168 8424 S 26.3 2.8 6674:58 mediasrv

Display More

Trotzdem bin ich mit 69.4 (vdr) + 26.3 (mediasrv) an der oberen Grenze

Hallo,

Ich habe epgsearch und live. Denke jetzt mal nicht, dass die mehr Last während einer Aufnahme verursachen als ohne Aufnahme.

~ Markus

Hi,

ich habe mal einen Patch geschrieben. Damit schreibt VDR die PMT nur noch einmal (am Anfang), außerdem wird index nicht generiert. Außerdem können die TS Dateien nicht mehr gesplittet werden.

Dafür kann ich jetzt 2 HD Aufnahmen gleichzeitig machen, ohne Pufferüberlauf .

Den index generiere ich jetzt, wenn die Aufzeichnung beendet ist.

~ Markus

Hallo,

Ich habe jetzt noch einen 2. Patch, der die Puffer vergrößert.

Damit kann ich 4 HD Aufzeichnungen von 2 verschiedenen Transpondern machen (ich habe 2 USB DVB-S Sticks).

Auch, wenn ich gleichzeitig noch VDR kompiliere, epgsearch einen Suchlauf macht, ... bekomme ich 4 fehlerfreie HD Aufnahmen .

Und jetzt der Nachteil: VDR kann die Aufnahmen nur von vorne abspielen. Springen in der Aufnahme funktioniert, aber beim Resume bleibt das Bild schwarz. Geschnittene Aufnahmen, bei denen der Anfang rausgeschnitten wurde, gehen auch nicht .

Liegt wohl daran, dass die PMT nur am Anfang jeder Datei ist. Kodi hat damit keine Probleme, da geht auch resume .

~ Markus

Hi,

noch 2 weitere Patches:

add_patpam_cut.diff fügt beim Schneiden die fehlende PMT in die geschnittene Aufnahme ein.

play_patpmt_start.diff sorgt dafür, dass VDR zum Abspielen von Aufnahmen nur am Anfang der Aufnahme die PMT braucht.

~ Markus

Der Performanceunterschied besteht nicht im Schreiben der PAT/PMT.

Sondern darin, dass der Stream nicht analysiert werden muss sondern einfach auf die Festplatte gedumpt wird.

Ob das für RPI Systeme noch relevant ist, kann ich nicht sagen. Und natürlich ist jedem freigestellt, ein schnelleres System zu kaufen. Ist aber für einen VDR Server nicht notwendig.

~Markus

Also, natürlich kann das jeder so machen, wie er möchte.

Spannend finde ich jedenfalls, dass mögliche Probleme beim gleichzeitigen Aufzeichnen vieler Sendungen nicht durch fehlende I/O Performance verursacht werden (zumindest nicht, wenn die Festplatte an einem 10 Jahre alten USB hängt, an dem auch zwei DVB-Sticks hängen), sondern durch mangelnde CPU Leistung.

Von wegen nicht-konformen mpeg Stream: Der Original VDR beendet sich bei einem nicht-konformen mpeg Stream mit dem VDSB. Dann können die Treiber neu geladen werden, und VDR versucht, mit der Aufzeichnung weiterzumachen. Der von mir gepätchte VDR beendet sich mit dem VDSB nur noch, wenn gar keine Daten mehr kommen. In der Praxis macht das für mich keinen Unterschied, seit ich meine alten FF Karten rausgeschmissen habe, hatte ich keinen VDSB Fehler mehr.

~ Markus