Wieviel maximale Aufnahmen sind möglich. Wo ist der Flaschenhals?

Irgendwie fehlen da Angaben zur verwendeten Hardware, VDR Version und Empfangs-Weg sowie Logauszüge und Meldungen von dmesg, um da bei der Frage nach dem Flaschenhals eine Vermutung äußern zu können.

Gerade der Mainboard-Chipsatz kann da im Zusammenspiel mit SATA-Controllern, Grafikkarte und DVB-Karten Probleme machen. Bekannte Übeltäter sind einige SIS- und VIA-Chipsätze, und auch bei einigen Intel-Chipsätzen gab es hier in den letzen Wochen Threads, in denen empfohlen wurde bei Problemen pci=nomsi als Boot-Argument zu übergeben.

Zitat von chrisz

Die HDD IO kann doch nicht der Grund dafür sein?

Naja, Die CPU und seine Anbindung an die Peripherie muß schon in der Lage sein die IOPS zu verarbeiten, die CPU ist primär dafür verantwortlich und da schwächeln z.B. eben alle ARM, Atom und VIA C-Schießmichtot gewaltig. Die HDD ist erst in zweiter Reihe ursächlich und markad läuft ja für jede Aufnahme auch noch los ...

Ich habe mit meiner L4M Twin S2 V5.5 & FlexS2, also 4 Tuner, schon testweise 16 Aufnahmen von 4 Transpondern parallel getätigt, alle fehlerfrei und markad lief in der Tat 16x, erster VDR meiner Signatur ...

Regards
fnu

fnu

Alles FreeTV?

Zitat von herrlado

Alles FreeTV?

Nein, da waren auch einige verschlüsselte dabei ...

Der VDR ist per SCR/Unicable® angebunden, hatte ich vergessen explizit zu erwähnen ...

Zitat von chrisz

Also mach es einen Unterschied, ob ich 4 HD Aufnahmen über 4 Tuner mache, oder 4 über einen Tuner ?

Soweit ich weiß wird da jeweils der komplette Transponder von der Karte durchgereicht, pro Tuner dürfte sich das so in der Größenordnung von 40 - 60 Mbps bewegen (laut http://de.kingofsat.net/hdtv-19.2E.php)

Interessant ist ja nicht die sequentielle Schreibrate des RAID-Verbunds, sondern was man erreichen kann, wenn da viele parallele Plattenzugriffe erfolgen.

Hast du schon mal pci=nomsi als Boot-Parameter versucht? Das könnte die Situation im dem Interrupt-Handling evtl. etwas entzerren.

Zitat von chrisz

Ok, dementsprechend 4 pro Tuner. Es gab keine Ring Bufferoverflow Meldungen im Syslog vom VDR?

Ja, genau, vier Aufnahmen von einem Transponder pro Tuner, alles über einen PCI-E 1x Slot, geht ja nicht anders. Keinerlei Meldungen oder Probleme, gut der VDR hat einen etwas höheren Load als sonst, war aber noch weit weg von 100% ...

Man muß schon auch mal sehen, was hat so ein Transponder in Summe heute an Datenrate, 25-30Mbit/s, das ganze mal 4 ergibt 100-120Mbit/s, also 8-10MB/s, eine lächerlich geringe Datenmenge, wenn man bedenkt was moderne Computer heute können. Aber die Zahl I/O Operationen ist dagegen relativ hoch, viele kleine Blöcke die verarbeitet werden müssen, das fordert alle beteiligten Prozessoren doch schon ...

Zitat von chrisz

Spezielle erhöhung des Buffers gemacht ?

Nö, nix, ...

Aber ich persönlich mache mir die Mühe einen VDR parallel zu einem alten neu aufzubauen und sehr lange zu testen, bevor der Haupt-VDR wird. In dem Zuge werden dann schon auch die ein oder andere HW Änderung noch gemacht, bis alles nach meinen Vorstellungen läuft. Wenn er dann Haupt-VDR ist, kenne ich das Ding bereits "auswendig" ...

Regards
fnu

Zitat von seahawk1986

Soweit ich weiß wird da jeweils der komplette Transponder von der Karte durchgereicht, pro Tuner dürfte sich das so in der Größenordnung von 40 - 60 Mbps bewegen (laut http://de.kingofsat.net/hdtv-19.2E.php)

Nur wenn die Karte keine Hardware PID filter hat. Das kann ich mir fast nicht vorstellen. Vom Board und der sonstigen Verwendung habe ich jetzt nix gelesen. Ein MB was buggy ist oder Streamdev, welches nicht schnell genug Daten abnimmt könnte einen negativen Einfluss haben.

Zitat von chrisz

Denke ich mir eben auch. Deswegen wundert es mich, dass ich keine 8 HD Aufnahmen zeitgleich schaffe...

Naja, den Rest mit der im Verhältnis recht hohen IO Raten hast Du wohl aber überlesen.

Ich erklärs mal an einem einfach Beispiel, Du machst eine Sicherung mit einem Backup Tool, das Deine Daten sammelt in Happen packt und an den Empfänger adressiert. Das sind dann nur ein paar 100 IOPS, aber einem großen Datendurchsatz, sagen wir 100MB/s via GB/s Ethernet oder gegen ein Festplatte. Die CPU hat hier relativ wenig zu tun, die Busse sind aber einigermaßen ausgelastet. Auf der anderen Seite beziehst Du Deinen EPG von extern, der wird in eine sqlite Datei o.ä. abgespeichert und mittels dem EPG Handler in den VDR angespeist. Während der EPG Pflege wirst Du einen Durchsatz von wenigen 100KB/s sehen, aber dafür aber 1000 IOPS oder mehr, in dem Fall hat die CPU viel zu tun, die Busse sind quasi unbelastet. Im top/htop sieht man das nicht, weil das an sich keine Computing Powerbelastung ist, aber z.B. "atop" zeigt sowas an, das Verhältnis Datendurchsatz zu IOPS.

Was will ich damit sagen, eine geringer Datendurchsatz muß nicht geringe Systembelastung heißen, im Gegenteil, bei 8 Aufnahmen fallen für jede einzelne IO Operation an die parallel abgearbeitet werden müssen, obwohl der Datendurchsatz eher gering ist. Und hier ist nicht nur die Haupt-CPU involviert, sondern eben auch die des SATA Controllers und der Festplatte, bei PATA läuft alles über die Haupt-CPU. Max. Durchsatz ist kein Qualitätskriterium, sondern die Zahl der IOPS die verarbeitet werden können.

Obwohl Deine HW recht potent aussieht, gibt es da noch die für mich unbekannte, Softraid. Die die mich kennen, wissen was ich davon halte, aber neben den ganze normalen IO Operationen eines VDRs übernimmt die CPU hier zusätzlich noch die Rolle des RAID Controllers.

Kannst Du mal die komplette HW listen? OS? 32-bit oder eine 64-bit Installation? Was ist das Filesystem wo die Aufnahmen landen? Hast Du andere HW wo Du mal testen könntest?

Regards
fnu

Ergänzung: Wenn's die IOPS sind, wäre eine SSD ein naheliegender Lösungsansatz.

Hi chrisz,

der Effekt gibt schon zu denken!

Als erstes würde ich Dir empfehlen, den Speicher aufzurüsten.
2 Gig für SW-Raid kommt mir sehr wenig vor.
... und dann betreibst Du noch ne Ramdisk

Dann würde ich Bonnie auch eher in die Tonne kicken. Ist zu synthetisch.
Im VDR-Umfeld sind andere Daten gefragt und Aufnehmen auf ein Raid5 - eher fragwürdig.
Denn was Bonnie und Co als Transfer-Rate ausgeben ist keine Dauerrate.
Das Verhalten von Raid5 lässt sich auch gut mit mc visualisieren.
Wenn Du dort eine größere Datei kopierst, startet mc mit gigantischer Transferrate. Die pendelt sich langsam auf Normalniveau ein, um dann völlig auf 0 zu gehen.
Das ganze Spiel wiederholt sich zyklisch - d.h. ein Raid-Verbund hat immer ne Denkpause, wenn die Puffer geleert werden.
Damit muss natürlich auch der schreibenden Prozess umgehen können.

Ich teste die Transfer-Rate so:
- Testdatei > 10 Gig erstellen (wenn möglich für jeden Test eine separate Datei)
- unterschiedliche Testverzeichnisse erstellen
- die Testdatei in ein Testverzeichnis kopieren mit "time cp Datei Verzeichnis"
- aus den Zeitangaben und der Dateigröße kann man dann die "echte" Transfer-Rate berechnen.

Wenn Du rausfinden willst, wo der Flaschenhals ist, dann nimmst Du mehrere Sessions und lässt in jeder eine Kopieraktion ablaufen.
In einer weiteren Session startest Du dann Lese-Aktionen.
Das geht am einfachsten, indem Du Dir die absoluten Pfade von div. Textdateien in eine Datei kopierst (pro Textdatei eine Zeile)
dann in der Lese-Session ein "time cat $( < Datei-mit-Pfaden-zu-Textdateien )"

Wenn Du die Leseaktion startest, dürften die Schreibaktionen gehörig einbrechen.

Bei mir ist es so, wenn ich ne volle Wechselplatte auf den Server kopiere, dann sind das 500 Gig von einzelner Platte auf ein Software-Raid Level 5.
Wenn ich das mit "time cp -a Platte Raid" mache, komme ich nie auf die Transfer-Raten, die mir die üblichen Benchmarks ausspucken.
... und lass Dich nicht drausbringen - Software-Raid ist eine sehr gute Entscheidung - auch wenn man einen 3ware-Raidcontroller hat

Gruß Gero

Zitat von Ein Eike

Ergänzung: Wenn's die IOPS sind, wäre eine SSD ein naheliegender Lösungsansatz.

Ja, guter Mann, korrekter Ansatz ...

Aber ich denke nicht das Massenspeicher IOPS sein Problem ist. Meine o.a. 16 parallelen Aufnahmen schreibe ich auf eine WD10EADS, also eine ganz normale WD Green mit 512KB Sektoren ...

Und da habe ich noch ein ganz tolle Anekdote dazu. Ich kann diese Massen an Aufnahmen tätigen inkl. ein oder zwei verschlüsselter Transponder. Aber seit irgendeinem Update in der Vergangenheit darf ich auf dem VDR unter keinen Umständen eine Aufnahme schneiden während ein oder mehrere Aufnahme getätigt werden. Diese sind dann fehlerhaft, in dem Zeitbereich wo ich die Aufnahme geschnitten hatte. Leider habe ich keine Lösung dafür gefunden, bzw. doch, ich hab mein Nutzerverhalten angepasst ...

Regards
fnu

Zitat von chrisz

Mich hätten mal vergleichswerte wie von fnu genannt interessiert.

Ja, das würde mich auch mal interessieren.

Die Tests hatte ich in der Zeit gemacht mit Unicable-Patch und später als als SCR in den VDR gefunden hatte, um die Stabilität der SCR Anbindung zu belegen, gab ja immer Zweifler und Schlecht-Reder. Die ersten Tests hatte ich noch mit 3x TT S2-1600 gemacht, in einem Gigabyte M720-US3 und Sempron 140 (SingleCore), da hatte ich nur 3x4 Aufnahmen getestet ...

Aber interessanterweise habe ich bisher noch gar keine anderen Berichte dazu gehört, weder von SCR Nutzern, noch von Multiswitch-Nutzern. Hatte ja gedacht unsere Berliner Zelle ebenfalls mit vielen DVB Karten meldet sich mal mit Berichten. Werde aber nachher mal eben 2x4 Aufnahmen auf meinem zukünftigen Haupt-VDR definieren, ohne SCR an den Legacy Anschlüssen, mit einer V5.6 ...

chrisz

Was ist denn nun mit Deiner detailierten System-Liste? Evtl. hat ja jemand das gleiche Mainboard und hat eine Idee, wo man was verbessern könnte.

Denk dran, Durchsatz ist nicht Dein Problem und Benchmarkwerte kein Qualitätskriterium ... irgendwo im Zusammenspiel, PCI-E Karte, Mainboard, Treiber liegt das Problem.

seahawk1986 hatte weiter oben mal empfohlen mal "pci=nomsi" zu setzen, was hast Du sonst an Kernel-Schalter übergeben?

Regards
fnu

chrisz

Gar nicht so einfach 8 parallel HD Aufnahmen bei der aktuellen Transponderbelegung, aber wie versprochen 2x4 Aufnahmen von HD Sendern mit dem 2. VDR aus meiner Signatur ohne SCR @ L4M Twin S2 V5.6:

250-40 9:1:2013-01-16:1710:1830:50:14:Test~Brisant:250-41 9:10:2013-01-16:1730:1830:50:14:Test~Hafenwelten (3/5):250-42 9:25:2013-01-16:1700:1830:50:14:Test~Kaffee oder Tee:250-43 9:80:2013-01-16:1700:1830:50:14:Test~Kaffee oder Tee:250-44 9:9:2013-01-16:1703:1830:50:14:Test~Moderne Wunder:250-45 9:33:2013-01-16:1747:1830:50:14:Test~Die Simpsons:250-46 9:34:2013-01-16:1725:1830:50:14:Test~heute leben:250 47 9:116:2013-01-16:1703:1830:50:14:Test~Moderne Wunder:

svdrpsend plug devstatus devstat220 vdr2 SVDRP VideoDiskRecorder 1.7.27; Wed Jan 16 18:05:46 2013; UTF-8900-DVB-Geräteliste:900-  --- Gerät 1 ---:900-    Mit 16.01. 17:10 Test~Brisant900-    Mit 16.01. 17:30 Test~Hafenwelten (3/5)900-    Mit 16.01. 17:00 Test~Kaffee oder Tee900-    Mit 16.01. 17:00 Test~Kaffee oder Tee900-900-  --- Gerät 2 ---:900-    Mit 16.01. 17:03 Test~Moderne Wunder900-    Mit 16.01. 17:47 Test~Die Simpsons900-    Mit 16.01. 17:25 Test~heute leben900-    Mit 16.01. 17:03 Test~Moderne Wunder900-900-  --- Gerät 3 (Gerät hat Dekoder, Primärgerät) ---:900-    keine laufenden Aufnahmen900221 vdr2 closing connection

Beim angehängten Screenshot sieht man das die Aufnahmen nicht "das Problem" für den Kleinen sind, sondern die 8x markad die parallel los liefen ... ... hält sich aber in Grenzen ist nur sekundenweise so stark ausgelastet ...

Keinerlei Bufferoverflow oder -underrun Meldungen im syslog ...

Regards
fnu

Zitat von chrisz

Hattest du in den 1 1/2 Stunden irgendwelche buffer meldungen im Syslog ?

Jan 16 18:20:20 vdr2 vdr: [2135] buffer usage: 70% (tid=2133)
Jan 16 18:20:20 vdr2 vdr: [2135] buffer usage: 60% (tid=2133)

So was hatte ich vereinzelt im Umfeld von markad Meldungen in den 30-40min. Wenn ich es live beobachten würde, kommen diese Meldungen IMHO genau dann, wenn der VDR wie im o.a. Screenshot bei Hochlast ist, weil 3, 4, 5 Markad Prozesse parallel los-scannen ...

Aber da sage ich mal Celeron G440 ... FTW ...

Regards
fnu