Beiträge von geronimo

Dirk
neues Server Forum als Unterforum von Software? - Versehen oder Absicht?

In dem Fred von fnu hatte ich den Eindruck, als ob mehrheitlich die Toplevel-Variante begrüßt werden würde.
Wenn Du den Server-Bereich unterhalb von Linux ansiedeln willst - dann ist das ein Punkt, mit dem ich gut leben könnte.
Für andere Betriebssysteme (gibt es die überhaupt) interessiert sich eh kein ...

Aber den Server-Bereich unterhalb von Software anzusiedeln, empfinde ich schon als unglücklich.

Vielleicht täusche ich mich ja auch, aber ich hatte den Eindruck, dass die Anzahl der Fragen zu Server bezüglich Hard- oder Software sich die Waage gehalten hätten. Somit sind alle Fragen zu Server-Hardware auch weiterhin auf das Forum Linux-Hardware bzw. eben verschiedenes/andere Hardware angewiesen.

Hm ...

Gruß Gero

Zitat von UFO

Sollte man die Umschalt-Logik nicht besser in das Ausgabeplugin verfrachten?

Das hört sich nach einem guten Plan an.

Selbst wenn man in Betracht zieht, dass z.B. bei remote xineliboutput-Clients der Netztraffic etwas ansteigt.
Ich denke, die Vorteile die eine Umschaltung "vor Ort" bringt, rechtfertigt den "geringen" overhead - Audiodaten sind ja jetzt nicht soo fett

Gruß Gero

Zitat

Hmm, gleich ein ganzes Top-Level Forum? Auch wenn hier relativ sehr viel KnowHow vorhanden ist und vorallem der Bedarf für z.B. (Device-)Virtualisierung da ist, ist doch das Hauptthema der Anlage hier das Thema VDR.

Nun, ich dachte, dass im Server-Forum mehr Fragen zur harten Währung auflaufen würden ...
... und selbst wenn man das meiste der weichen Ware unter Linux ablgegen könnte, gibt es doch etliche, die auch einen Server mit Winxx oder sonstwas betreiben wollen.
Nen ESX Server würde ich auch nicht unter Linux einstufen/suchen. Genausowenig wie unter VDR.

Zitat

Die Kategorie gibt es doch seit gestern

Ja, als Unterforum des VDR ist das so auch richtig.

Es gibt aber auch Anwender, die an Hausautomatisierung schrauben und die die Himbeere ohne VDR irgendwo als Arbeitssklave einsetzen wollen.
Das wäre für mich dann ein Server.
Auch wenn das vielleicht ein Extrem-Beispiel ist, aber schließlich kann so ein Teil Dienste anbieten, die ein anderer Rechner benutzt.
Das ist doch nicht anders, als wenn jemand ne Goflex als NAS betreibt.

Im Umfeld vom VDR kann ich mir sehr viel vorstellen. Auch wenn es direkt mit der VDR-Software als solchen nix mehr zu tun hat.

Gruß Gero

Moin,

bin endlich mal wieder daheeme und habe 5 Minuten für mich ...

Dirk
gute Idee, das Forum etwas aufzuräumen!

Zitat von fnu

"VDR Portal" / "Linux" / "Software" / "Server".

Zitat von Torsten73

Ich würde es allerdings eher im Bereich der neuen Rubrik Hardware/Server und Archivierung sehen.

Hm, also ich sehe den Bedarf für ein Server-Forum auch, allerdings sehe ich nicht, dass es als Unterforum gut aufgehoben ist.
Deshalb halte ich es für adäquat, für die Server-Fraktion ein Toplevel-Forum zu erstellen.
Dieses könnte man beispielsweise nach Wuchs, Feuchtigkeitsgrad, esotherischem Zustand und Erwachsenenstatus gliedern - will sagen, nach Mini (Raspery/Zotac/Goflex), NAS, Virtualisierung und ausgewachsene Server.
Ich denke, in Zukunft wird der Wunsch nach "Recodierung on the fly" eher zunehmen, sodass die ausgewachsenen Server mit mächtig Badaboom wieder mehr Zulauf erhalten werden.
Daneben gibt es aber auch die Vegetarier, die Zoten und HImbeeren lieben, oder die nicht ohne ihren Winkelschleifer zum Wandern gehen ...

Ich denke, es gibt bereits reichlich Diskussionen um sie entsprechend neu ordnen zu können.

Gruß Gero

Moin,

Zitat

zu ändern und entsprechend aufzurufen. VDR könnte dann beim Zappen nicht passende Kanäle überspringen.

Halte ich für den besseren Weg.

Ich komme zwar auf absehbare Zeit nicht dazu, UFOs Patch zu testten (bin mal wieder auf Tour), aber ich könnte mir vorstellen, dass die Prüfung dort viel zu häufig erfolgt und somit zu einer höheren Systemlast führt.
Ich stell mir den Treiber zumindest zustandslos vor, d.h. er müsste bei jedem Paket prüfen, ob es gültig ist oder nicht. Das halte ich für Kwatsch.

Der VDR weiß (über EPG oder Info-Datei), um was es sich bei den Daten handelt.
Wenn ich also einen Film abspiele/aufnehme, dann ändern sich die Streameigenschaften für eine oder 1,5 Stunden nicht.
Selbst wenn bei einem HD-Film die Werbung in SD kommt - wen interessierts?
Für den VDR wäre es eine Prüfung, während der Treiber aus dem Prüfen nimmer raus kommt.
Bei einem Timer-Vorlauf könnte es passieren, dass vor einer HD-Aufnahme noch eine SD-Sendung läuft.
Bei der Frage nach HasDekoder müsste also nícht der aktuelle Stream, sondern der zu erwartende verwendet werden.

Selbst für einen unabhängigen Streaming-Server ist es ein leichtes, Media-Info zu verwenden, um die Information einmalig zu bestimmen.
Deshalb halte ich die API-Änderung für einen richtigeren Weg.
Der wirklich richtige wäre, den SD-FF-Player aus der Device-Schleife zu entfernen und in einen eigenen Thread packen - so wie die Recorder.

... und ich behaupte mal, dass jede Anwendung, die in der Lage ist, einen Stream aus einem DVB-Multiplex heraus zu filtern, auch die Service- und EPG-Informationen auslesen und auswerten könnte. Deshalb halte ich das Argument mit den anderen Anwendungen für wenig zugkräftig.

Gero

Zitat

Es gibt seit geraumer Zeit den Full-TS-Mod!

Völlig richtig.
Nur bin ich nicht in der Lage, den selbst durchzuführen. Seinerzeit habe ich mich erkundigt, was es kostet, wenn ich es machen lasse ...
Die Kosten ware in der Größenordnung einer Budgetkarte - und letztere bot mir mehr Flexibilität, also entschied ich mich für die Budgetkarte.
Dass der VDR mit SD-FF + Budgetkarte schlechter funktioniert, als mit SD-FF alleine, das war für mich nicht absehbar.

Nachdem der Schnitt endlich angegangen wurde und es die Make-Orgie gab, dachte ich, diese Baustelle wäre auch verbesserungswürdig.
Wenn ich mit der Meinung alleine dastehe - ok. Ich habe ja bereits meine Konsequenzen gezogen.

Gero

Moin

Zitat

Falls mir jemand ein sicheres Kriterium zum Erkennen der MPEG-Version nennt, welches noch mit vertretbarem Aufwand abzufragen ist, baue ich das in den Treiber ein.

Auch wenn ich Dein Angebot toll finde, bin ich der Meinung, dass das der falsche Weg ist.
Der VDR weiß doch bereits vor dem Anzeigen (z.B. aus den epg-Daten), was das für Daten sind. Dies also ständig neu zu eruieren ist aufwändig und überflüssig.

... und wenn das Limit fix ist, wie steffen_b schrieb, dann könnte der vdr sogar ermitteln, welche Sender fehlerfrei von einer SD aufgenommen werden könnten, bzw. über die Bandbreite abschätzen, ob es besser wäre, die Anzeige zu unterbinden, um eine anstehende/laufende Aufnahme nicht zu gefährden.
Aber auch das sind Anwendungsentscheidungen, die im Treiber nix zu suchen haben (der stellt ja schon die Möglichkeit der Abfrage bereit).

Gero

Moin moin,

yo, mein backend ist ein reines PCI-System.

Zitat

Konkret könnte man im DVBSDDEVICE-Plugin in den Paketen nach MPEG2 Picture-Headers suchen und falls eine Weile keine kommen die Pakete bis zum nächsten Header verwerfen.

Wenn das dann auch noch asynchron passieren würde, wäre das ein sehr guten Plan.
Danke Dir!

Daneben könnte man auch die Verbindung zur Anzeige optional machen.
Wenn ich den Transfer der DVB-Pakete richtig verstanden habe, sollte es jetzt schon funktionieren, dass der VDR aufnehmen kann, ohne dass ein Wiedergabe-device verbunden ist.
Man(n) könnte also eine Funktion vorsehen, die mit einer Taste auf der Fernbedienung verbunden werden kann, die ein Frontend verbindet, bzw. trennt.
Wenn man dann noch die Option hätte, konfigurieren zu können, ob der VDR als Backend (default ohne Anzeige) oder Frontend (default mit Anzeige) betrieben werden soll, wäre das schon ein Riesenschritt vorwärts

Gero

P.S. Inzwischen habe ich das acpi-wakeup von e-tobi für tvheadend portiert und somit fast die Funktionalität des vdr

Zitat

Und wir wissen immer noch nicht, ob dieses Problem in Version 1.7.36 noch auftritt oder nicht...

Wenn alle SW-Systeme mit dieser Einstellung eingeführt würden, würde es Deutschland schon lange nimmer geben, weil alle Akw's "aus Versehen" explodiert wären.

Ich "programmier" beruflich zwar nur mit Word und Excel, habe aber im Zuge von QS auch Code-Reviews durchzuführen.
Wenn ich entdecke, dass was theoretisch falsch ist, dann lasse ich es ganz bestimmt nicht auf den Test drauf ankommen, ob der Fall in der Praxis provoziert werden kann.
Keiner meiner Kunden hätte für ein solches Vorgehen Verständnis.
Ich bin weder Politiker noch Marktschreier, habe nur eine andere Sichtweise auf Qualität - und somit bin ich überzeugt, dass das, was theoretisch falsch ist, praktisch niemals richtig sein kann.

Gero

Zitat

Moment, die eigentliche Verarbeitung der Daten findet ja im Treiber (bzw. der Firmware) für die SD-FF-Karte statt.

Na klasse!
Hauptsache Du must nix tun

Du weißt aber schon, dass Dateioperationen ein vielfaches der Zeit einer Speicheroperation brauchen?

Zitat

Du wirst lachen, so war es früher mal. Aber auch dieser Puffer ist ab und zu übergelaufen, wenn die Karte "gesponnen" hat.
Nicht jedes Problem läßt sich dadurch beheben, daß man einfach nur Speicher "draufschmeisst".

Hey Klaus - auch wenn Du mich für einen geistigen Tiefflieger hälst, ganz so einfach bin ich dann doch nicht gestrickt
... und ich habe bestimmt nicht verlangt, dass Du die Stelle verschlimmbessern sollst.

Ein Ringpuffer - so wie ich ihn verstehe - kann immer beschrieben werden und blockiert die schreibende Seite nie!
Wenn der lesende Prozess nicht hinterher kommt, na gut - Pech gehabt. Dann gibt es eben Paketverlust - aber nur für den, der nicht in die Pötte kommt.
In ffplay - für mich die Vorlage schlechthin - wird es auch so gemacht.
Lesen und Dekodieren sind voneinander unabhängige Threads und erst direkt vor der Anzeige wird entschieden, ob ein Frame nach draußen oder nach /dev/null geschickt wird.

Ich würde den Treiber auf jeden Fall als "blackbox" einstufen, den ich nicht beeinflussen kann.
Wenn ich also weiß, dass der Treiber manchmal stocken kann, muss ich in der Anwendung dafür Sorge tragen, dass dies Stocken niemand beeinträchtigt.

Zitat

Das müsste sich vielleicht mal jemand im Treiber bzw. der Firmware anschauen, aber ich vermute stark, daß das heutzutage niemanden mehr interessiert...

und wenn schon.
Im Gegensatz zu Dir gehe ich davon aus, dass externe Störungen "normal" sind.
Jetzt ist es die SD-FF und demnächst ist es irgend jemand anderes. Spielt es eine Rolle? - Ich denke eher nicht.
Wenn ich z.B. ein Ausgabe-Device per WLan anbinde, könnte das gleiche Problem wieder auftauchen.

Wenn der VDR davon ausgeht, dass es bei der Übertragungskette zu Problemen kommen kann und Sender und Empfänger der Pakete entkoppelt, dann werden es immer lokale Probleme bleiben, die keine Kollateralschäden verursachen.
Was mich stört ist einfach die Tatsache, dass ein Problem bei der Wiedergabe zu defekten Aufnahmen führen kann. Das kann und darf nicht sein.
Wenn Dir das zu theoretisch ist, dann lass es eben.

Zitat

Naja, das Plugin muss sich natürlich schon merken, welche Kanäle es für welches Device sperren/zulassen soll, ich hab nicht gesagt, dass es automatisch und nur mit der channels.conf geht...

Ja, so könnte es schon gehen.
Nur halte ich das für die schlechteste aller Möglichkeiten.
Die Eigenschaften der Kanäle sollten an einer Stelle gepflegt werden.
Vielleicht ist dort ja nach 2.0 was möglich. Mann soll die Hoffnung nie aufgeben.

Zitat

werde ich mich an dieser Diskussion nicht mehr beteiligen - reine Zeitverschwendung!

Wenn der VDR mit dem Klaus nimmer gepflegt werden kann, sollte man vielleicht über einen Fork nachdenken.
Es macht keinen Spaß mehr, sich für Produktqualität einzusetzen.

Gero

Moin moin,

Zitat

Das ließe sich über ein Plugin und die DeviceHooks realisieren, denke ich.

Das waage ich mal zu bezweifeln.
Schließlich muss die Information ja auch irgendwo gehalten/abgelegt werden und das gibt die bisherige Channels-Struktur nicht her (. Es gab ja schon mehrfach den Wunsch, die Channelsstruktur aufzubohren).
Aber ich lasse mich gerne vom Gegenteil überzeugen

Zitat

Und so sollten alle Ausgabedevices arbeiten!

Hm, vielleicht verstehe ich ja wieder mal was nicht, aber meiner Ansicht nach arbeitet das SdFfDevice nicht so - und das ist ja vom VDR-Core, also von Dir.
Die cTransfer-Klasse soll doch eine Abstraktion zwischen Sender und Anzeiger sein.
Meiner Ansicht nach wäre das der richtige Platz, um einen Ringpuffer zu verwalten (so wie es im Recorder passiert).
Es gibt doch für jeden Wiedergabe-Weg eine cTransfer-Instanz, somit wären auch die entsprechenden Puffer redundant.
Eigentlich™ gibt es keinen Grund, warum jeder Player einen Ringpuffer anlegen müsste.
Selbst wenn die Puffer unterschiedlich groß sein sollten, könnte das in der cTransfer-Klasse gekapselt werden.
Die Recorder sind ja schon Threads, dann fehlt nur noch die Aufteilung von cTransfer in eine Thread/Puffer-Klasse, bei der Receive() den Puffer füllt und PlayTS in einem eigenständigen Thread läuft, welcher aus dem Puffer liest und die Player-Wiedergabe-Methode aufruft.

Naja - wie auch immer.
Beim SD-FF-Device erfolgt die Wiedergabe synchron in der device-Schleife des Empängers, denn das PlayTS ruft beim SD-FF-Device die Methode WriteAllOrNothing auf, welche höchtswahrscheinlich die Probleme verursacht. Habe jetzt nicht verfolgt, für was der erste Parameter beim SD-FF-Device steht, aber ein Puffer würde wahrscheinlich nicht per Dateioperationen gefüllt werden. Oder?
Hier fehlt also die Entkoppelung zwischen Empfänger und Wiedergabe.

Gero

Zitat

Auch wenn es vielleicht vergebliche Liebesmüh' ist ...

Danke für die Blumen

Zitat

der Transfer-Mode "hängt" nicht 10 Sekunden in der Schleife

Ok, ich habe übersehen, dass Du den sleep gegen einen Timer ausgetauscht hast.
Damit dürfte es jetzt in der Tat etwas besser laufen.

Ich verstehe trotzdem nicht, warum die Frontends nicht wie ein Recorder aufgebaut sind?
Der Recorder ist ein Thread mit eigener Queue und Receive übermittelt nur ein Paket. Also schnell und genau so, wie man es erwarten würde.
Warum muss der VDR-core sich mit Transfer-Problemen rumschlagen?
Ich sehe darin weder eine Vereinfachung noch eine Verbesserung.
Wenn ich johns richtig verstanden habe, arbeitet sein Frontend eher wie ein Recorder - also richtig nach meiner Einschätzung.

Zitat

Und wenn du VDR nicht mehr verwenden magst ...

Das kam nur durch Deine Äußerung, dass Du die Abhängigkeiten nicht ändern willst.

Es ist jetzt über ein Jahr her, dass ich mir ne zweite Budget-Karte zugelegt habe.
Damals wollte ich die Timer-Konflikte entspannen. Statt dessen haben die Probleme zugenommen.
Ich habe auf Probleme hingwiesen, logs übermittelt - aber in dem Jahr ist (bezogen auf meine Probleme) nix passiert.
Sowohl Aufnahmen mit Länge 0, Timer-Konflikte, die ich nicht nachvollziehen kann und defekte Aufnahmen.
Dass die unterschiedlichen Eigenschaften von Sender und Karte nicht richtig berücksichtigt werden, war mir schon immer ein Dorn im Auge.
... aber Ok, das betrifft ja nur die Minderheit mit unterschiedlichen Karten

Ich mag Dich und auch den VDR und ich bringe mich auch gerne ein.
... aber ich mag nicht, dass Du Dich allen Errungenschaften moderner SW-Entwicklung verweigerst und dass Du divenhaft alle Standards ignorierst.
Ich unterstütze selbstverständlich Deine Freiheit, zu tun und zu denken, was Du willst -
nur denke ich, dass der vdr schon lange kein Spielzeug eines Einzelkämpfers mehr ist, sondern ein ausgewachsenes Produkt mit einer großen Anwenderschar.
Produktpflege gehört nach meinem Verständnis anders eingetacktet, als Du es handhabst. Das gilt für gerade anstehende Arbeiten genauso, wie für geplante Änderungen.
Ich zähle nicht zu den Leuten, die unter Teamarbeit verstehen: toll ein anderer machst.
Insofern liegt es an Dir, wenn ich den vdr nimmer verwende.

Gero

Zitat

geronimo ich verstehe dein Problem nicht.

Lach - da ich den vdr nimmer verwende, habe ich damit auch kein Problem mehr

Trotzdem ist mir das Teil ans Herz gewachsen, sodass ich ungern einen Fehler unkommentiert lassen würde.
Jetzt kann es natürlich trotzdem sein, dass ich der Fehler bin.

Falls nicht, sollte der Patch nomml überdacht werden.

Es geht mir um diese Schleife:

cDevice::Action(void)
{
     while (Running()) {
           if (GetTSPacket(b)) {
              if (b) {
                 //
                    ...
                 // Distribute the packet to all attached receivers:
                 Lock();
                 for (int i = 0; i < MAXRECEIVERS; i++) {
                     if (receiver[i] && receiver[i]->WantsPid(Pid)) {
                        if (DetachReceivers) {
                           // ...
                           }
                        else
                           receiver[i]->Receive(b, TS_SIZE);
                        }
                     }
                 Unlock();
                 }
              }
           else
              break;
           }
}

Nach meinem Verständnis wird in Zeile 4 ein Paket ermittelt, welches dann pro Device an alle interessierten Empfänger verteilt wird.
Zeile 12 schlägt nur bei verschlüsselten Sendern zu, sodass für Aufnahmen und Live-TV die Zeile 16 ausgeführt wird.
Selbst wenn ein Recorder ein Thread ist, wird die Funktion Receive von Zeile 16 synchron im Thread vom Device ausgeführt.
Das gleiche trifft natürlich auch für ein Frontend im Transfer-Modus zu (eine SD-FF mit --output-only scheint wohl immer im Transfermodus zu sein).
Naja, wie auch immer ...

Das Problem, das ich sehe ist, wenn jetzt in Transfer::Receive 10 Sekunden geschlafen wird, dann bedeutet das, dass das Device 10 Sekunden lang in dieser Schleife hängt und nix anderes tun kann. Das bedeutet für mich, dass der Paketverlust vor GetTSPacket von Zeile 4 passiert, also vermutlich zwischen Treiber und vdr.

Aus dem Grunde finde ich es falsch.
Wenn meine These falsch ist, dann verstehe ich nicht, wie ein zickendes Frontend überhaupt Aufnahmen beeinträchtigen kann (auch wenn kein emergency-exit zuschlägt kommt es ja mit vdr vor 1.7.36 zu Aufnahmefehlern, was nicht der Fall sein könnte, wenn die Empfänger wirklich unabhängig wären).

Gero

P.S. Im Log von Test 1 kann man sehr schön sehen, wie erst der Puffer überläuft und dann die Transfer-Probleme entstehen (Zeile 340ff)
Allein schon daran kann man ablesen, dass der Puffer-Überlauf nicht mit den Logausgaben der Fehler zusammen hängt.
5 MB Puffer mag für so Miniteile wie Himbeere und Co viel klingen, für ein Backend-VDR mit mehreren Karten ist 5 MB eine Lachnummer.
Vielleicht macht es Sinn, dies via Parameter konfigurierbar zu machen?

Zitat

Ich werde das auch in die 1.7.36 so einbauen, die ich in Kürze freigeben möchte. Der Diff hier nur der Vollständigkeit halber.

Ich habe den Patch mal kurz überflogen und - sofern ich die Ecke richtig verstanden habe - ist das eher ein Eigentor.

In der device-Schleife wird für jedes Paket über alle möglichen Empfänger iteriert. Dies passiert in einem Thread, also synchron.
Wenn ein Empfänger dann - warum auch immer - nicht schnell genug die Kontrolle an das device zurück gibt, gehen Pakete verloren.
Wenn jetzt also im Empfänger 10 Sekunden geschlafen wird, sind alle Aufnahmen von diesem Device defekt.

Ich denke, das macht die Situation noch viel schlimmer als vor dem ersten Patch.

Ich denke, eine Verbesserung würde sich ergeben, wenn "retriesExceeded = false" nur bei einem Senderwechsel ausgeführt würde.
Ist einmal der Überlauf eingetreten, kann man davon ausgehen, dass das zeitnah wieder passiert.
Schlafen ist die falsche Antwort, weil es andere Empfänger behindert.
Die Pakete früher zu ignorieren wäre eine adäquatere Antwort.

Gero

Zitat

Jetzt könnte es natürlich sein, daß allein schon diese Belastung zu einem Problem wird.

Definitiv nicht!

Der Test-Durchlauf 2 läuft unter identischen Bedingungen und hat keine Fehler in den Aufnahmen.
... aber durchaus Fehler und sleeps im Log.

Zitat

Versuch doch bitte mal, alle (wirklich *alle*) Log-Meldungen in cTransfer::Receive() auszukommentieren.

... und dann habe ich den gleichen Zustand wie vorher: defekte Aufnahmen ohne zu wissen, wo's klemmt.
Wenn man die Logs etwas genauer betrachtet, erschließt sich einem die Problemursache ohne groß nachdenken zu müssen.

Zitat

Hast du auch mal ohne markad probiert?

Nö - theoretische/syntetische Tests interessieren mich nicht.
Ich habe das getestet, was bei mir in der Praxis vorkommt.
Dabei habe ich sowohl einen Positiv- alsauch einen Negativ-Test durchgeführt und dokumentiert.
Wir sind doch nicht in Berlin, wo jeder dem anderen die Schuld in die Schuhe schiebt

Unter Einsatz von etwas Hirnschmalz wäre es also möglich, den (sinnlosen) emergency exit komplett zu vermeiden.
Um das hinzubekommen, muss ich nicht absurde Tests machen, sondern jemand anders muss die Änderung wollen.
Ich war ja sogar bereit, an einer Änderung mitzuwirken.
... aber wer nicht will, der hat schon.

Für mich ist das Thema gegessen.
Wenn die device-Schleife geändert wird (und natürlich die Empfänger in separaten Threads laufen) und einzelne Kanäle einer Karte gesperrt werden können, dann bin ich zu weiteren Tests bereit. Bis dahin hat sich das Thema vdr für mich erledigt.

Gero

Zitat

Dann gewöhne es rsyslogd doch einfach ab die zu droppen

Ja genau
habbich inzwischen auch gefunden und getan.
Tanke für den Dip.

Hier die Ergebnisse der neuen Tests:
Beide Tests nehmen die gleiche Anzahl an Sendern (aus 2 Transpondern) auf.
Bei Durchlauf 1 ist der erste Timer ein HD-Kanal, bei Durchlauf 2 ein SD-Kanal.
Wie man schon an der Größe der logs sehen kann, ist dabei ein eklatanter Unterschied.
Der Durchlauf 2 zeigt, wie es sein könnte, wenn man(n) berücksichtigen würde, dass es Unterschiede zwischen den Karten gibt (und Zuordnungen von Sendern zu Karten unterstützen würde).
Der Durchlauf 1 zeigt, wie der VDR sämtliche Aufnahmen versaut.
Bei diesem Test habe ich die vielfältigen Iterationen des emergency exit bis auf 4 Läufe entfernt.
Ist eh immer dasselbe.
Wie man sehen kann, bringt der emergency exit überhaupt nix.

Einen ähnlichen Test habe ich natürlich auch mit tvheadend durchgeführt.
Durch die elegante Verwaltung der Sender konnte ich dort sogar die SD-FF als Empfänger zulassen und alle HD-Sender für den Empfang sperren.
Der Aufnahme-Test von 3 Transpondern ergab keine Probleme oder Ausfälle
Das einzige, was ich vom vdr vermisse ist das epgsearch-Plugin - das ist schlicht und einfach genial.

Gero

Zitat

Die Ausnahme bilden hier in der Tat die 3Ware Controller, die können kein anderen Verbund übernehmen und Platten die sich in einem 3Ware Verbund befunden haben

Ok, dann bin ich in die Falle getappt.

Habe zweimal einen 3ware-Controller gekauft und mit beiden schlechte Erfahrungen gemacht.
Der eine war ein 4-Port PCI-Controller (inzwischen Schrankware), der andere ist ein 16-Port PCIe Controller, der immer noch läuft.
Ein Array von einem zum anderen 3ware-Controller zu migrieren war nicht drin.
Der neue hat kein Array erkannt.
Meine Messungen ergaben, dass der 16-Port Controller bereits bei einem Raid5 mit 5 Platten überfordert war.
Starke Einbrüche bei den Schreibvorgängen.
Selbst mein Atom aus erster Generation lacht sich einen bei der Prüfsummenberechnung (CPU-Last vernachlässigbar).

Zu SW-Raid noch folgendes:
dass die Tuhls schlechter wären als bei HW-Raid, das mag stimmen, wenn man SW-Raid aus den Tagen vor mdadm nimmt und die mit einem aktuellen ICL-Profi-Controller vergleicht (also mal wieder Äppel mir Birnen ...). Ich finde 1k Teuronen für nen privaten Plattencontroller alles andere als billich. Aber klar - gegenüber einem ICL-Controller ist es sicher günstiger
Ack ja - SW-Raid bedeutet für mich, dass alle Platten unter Linux partitioniert wurden und dann zu einem Raid mit mdadm gebunden werden. Fake-Raid ist weder SW- noch HW-Raid, sondern nur K@cke.

fnu
Vielleicht solltest Du Deine Kenntnisse bezüglich SW-Raid und der Möglichkeiten mal aktualisieren
Die Tests lassen sich automatisieren und protokollieren ...

Inzwischen verwende ich SW-Raid seit bald 20 Jahre, HW-Raid habe ich einige Jahre ausprobiert und für mich keinen Vorteil entdecken können, dafür aber jede Menge Nachteile. Aber auch das ist - wie alles was ich schreibe - höchst subjektiv. Muss niemand so sehen.

Gruß Gero

Zitat

Ich möchte die REINE Schreibgeschwindigkeit der Platten Wissen.

Hm - und was fängst Du jetzt mit einem Wissen an, das keinen Praxisbezug hat?

Du kannst auf den gleichen Platten unterschiedliche Dateisystem draufpacken mit teilweise eklatanten Unterschieden.
Meiner Ansicht nach zählt nur die gesamte Übertragungskette.
Ich habe auch mal bei einem NAS nur die Platten getestet - die OK waren.
Dann im Netzwerk brach die Transfer-Rate komplett ein.
Irgendwann habe ich dann den Netzwerk-Kontroller gemessen und festgestellt, dass der nicht in die Puschen kam.
Also ne Intelkarte rein und alles war gut

Zitat

Da hast du nicht gelesen.

woher weißt Du ...?!?

Zitat

Schlussendlich währe es 'schön' gewesen, wenn du in diesem Thread Deine Testergebnisse mitgeteilt hättest.

Sorry, ist schon ein paar Jährchen her.
Habe die Ergebnisse gesucht, aber die sind wohl irgendwann nach /dev/null gewandert
Wenn ich mich recht entsinne, war SW-Raid in Summe über 30% schneller als HW-Raid.
Die Anbindung der Platten an 3ware-Controller oder MB machte dagegen kaum einen Unterschied.

Zitat

Wobei es für mich kein Sinn macht ein Hardwareraid gegen ein Softraid zu Benchmarken...

Ah ok, dann ist die Frage im Fred-Titel also nur rethorisch.
Hatte ich so nicht verstanden.
Dachte Du wärest an technischen Lösungen interessiert.

Gero

Zitat von SHF

Du hast da eine Menge Output-Plugins am Start, evtl. mal die unnötigen deaktivieren.
... dummydevice und dvbhddevice sind doch sicherlich unnötig?

Ok, sorry!
Das war Faulheit beim Kopieren
Habe einfach alle *.deb kopiert.

Werde nomml einen Test durchführen.

Was mich aber eher beunruhigt hat, waren Meldungen wie diese hier:

Jan 18 13:55:12 vdrhost rsyslogd-2177: imuxsock begins to drop messages from pid 3913 due to rate-limiting
Jan 18 13:55:18 vdrhost rsyslogd-2177: imuxsock lost 1008 messages from pid 3913 due to rate-limiting

Also wenn 1000 Meldungen im Log fehlen, dann bekomme ich Bauchweh!
3913 ist der VDR (Haupt-)Thread.

Gero

Hi chrisz,

für mich sieht es so aus, als vergeudest Du viel Zeit mit sinnlosen Tests

Ich würde Dir empfehlen, Dir vorher zu überlegen, was Du denn eigentlich testen willst.
... und wie Du das am Besten tun könntest.
Die meisten Tests, die Du bislang hier gepostet hast, sind die Zeit nicht wert, die es dauert einen Post abzuschicken.

Genauso hast Du auch Dein Raid mit sinnlosen Tests beschäftigt.
Ich hatte was von mehreren Sessions und cp mit unterschiedlichen Pfaden geschrieben und Du setzt einfach ne Schleife mit dd ab
Weiß nicht, ob es Dir bekannt ist, aber dd geht am Dateisystem vorbei, d.h. die Zeiten, bzw. Transfer-Raten bringen Dir nichts für Deinen Anwendungsfall
Dann hast Du auch das Lesen außen vorgelassen.
Wie fnu schon schrieb, die eigentliche Last kommt nicht vom vdr, sondern von markad und Co (die ja parallel zur Aufnahme diese lesen).

Nachdem ich Deine jüngsten Beiträge gelesen habe, denke ich, dass Du auf der Maschine mit dem 3ware-Controller kein Software-Raid betreibst, sondern ein HW-Raid.
Das verhält sich deutlich anders, als ein Software-Raid.
Auch wenn Du einen jüngeren und leistungsfähigeren Controller hast, als ich, denke ich doch, dass sich am Prinzip nicht viel geändert hat.

Ich habe folgende Tests gemacht:
Schreiben auf HW-Raid mit Dateien größer 2 Gig (natürlich mit time cp ...)
Dann habe ich das HW-Raid aufgelöst und jede Platte einzeln im 3Ware-Controller exportiert. Unter Linux dann aus diesen Platten ein Software-Raid angelegt.
Dann die gleichen Schreibtests wieder ausgeführt.
Schlussendlich habe ich die Platten noch an die Ports des Mainboard gehängt, dort ein Software-Raid angelegt und die Schreibtests nomml laufen lassen.
Danach wusste ich, welche Art der Platten-Anbindung im Zusammenhang mit dem vdr für mich Sinn macht.

Gruß Gero