Grundsatzfrage PCIe/SAT>IP im Hinblick auf Fehleranfälligkeit bei Aufnahmen für neues DVBViewer Media Server-System

[JumpySkippy]

Hallo zusammen,

 

ich möchte meinen aktuellen MediaServer mit 8 Tunern (Hardware: Supermicro X10SBA, DigitalDevices Octopus mini V2 mit 4x DigitalDevices DuoFlex S2) perspektivisch erneuern bzw. ersetzen. Ich nutze den DVBViewer Media Server ausschließlich für Aufnahmen – Streaming wird nicht genutzt. Ich strebe Aufnahmen mit 0 Aussetzern an - das wäre mein Hauptaugenmerk.

 

Das neue System sollte stromsparend sein und ich möchte gern Meinungen/Tipps einholen, was diesbezüglich am besten bzw. zuverlässigsten arbeitet:

 

• Variante 1: Digital Devices Max SX8 (4/8) Basic für den Einbau in ein stromsparendes Mainboard mit PCIe-Schnittstelle.
• Variante 2: Digital Devices Octopus NET SL SX8 mit direkter Netzwerkverbindung zu einem stromsparenden Mini-PC z.B. Intel NUC

 

Meine größten Bedenken gehen bei der Octopus NET SL SX8 in Richtung SAT>IP. Hierbei werden die Daten durch das verbindungslose UDP-Protokoll über die LAN-Vebindung an den DVBViewer Media Server gesendet, so dass mit Discontinouities bei Aufnahmen sicherlich deutlich häufiger zu rechnen ist, wie bei einer Aufnahme direkt über die PCIe-Schnittstelle?

 

Im Fall des Einsatzes der Octopus NET SL SX8 würde ich auf jeden Fall einen PC mit zwei LAN-Schnittstellen einsetzten. Könnte man in dieser Konstellation bei einer Direktverbindung Octopus NET SL SX8 <-> dedizierte LAN-Schnittstelle am DVBViewer Media Server-PC das Risiko von Discontinuities gegen Null drücken, wenn auf dieser dedizierten Strecke kein weiterer Netzwerktraffic vorhanden ist, der die Übertragung eventuell beeinträchtigt?

 

Wie verhält es sich allgemein mit den Datenraten SAT>IP im Vergleich zur Direktübertragung über die PCIe-Schnittstelle? Die reinen "Nutzdaten" sind bestimmt die gleichen? Oder wird beim SAT>IP-Protokoll etwas "eingestampft" um Bandbreite zu sparen?

 

Ich bitte daher um Eure Meinungen, ob meine Befürchtungen begründet oder unbegründet sind und bin gespannt auf Euer Pro und Kontra.

[Griga]

vor 7 Minuten schrieb JumpySkippy:

Meine größten Bedenken gehen bei der Octopus NET SL SX8 in Richtung SAT>IP. Hierbei werden die Daten durch das verbindungslose UDP-Protokoll über die LAN-Vebindung an den DVBViewer Media Server gesendet, so dass mit Discontinouities bei Aufnahmen sicherlich deutlich häufiger zu rechnen ist, wie bei einer Aufnahme direkt über die PCIe-Schnittstelle?

 

Im Prinzip ja. Octopus NET SL SX8 hat allerdings einen eigenen Switch, über den das Gerät mittels QoS die Priorisierung eigener Paketen (die vom Sat>IP-Server stammenden) veranlassen kann. Auf eine Anfrage hat mir DD per Mail bestätigt, dass dies auch passiert.

 

Es deckt sich mit eigenen Erfahrungen (mit einer Octopus NET SL M4). Diskontinuitäten scheinen zumindest sehr selten zu sein, wenn der Client direkt über den Octopus Net-Switch angeschlossen ist, nicht über einen Router, so wie es meistens geschieht. Mein Client PC (unter Linux) hat nur einen Netzwerkadapter, ist also via Router -> Octopus NET Switch auch mit dem allgemeinen Netzwerk bzw. dem Internet verbunden, was gut funktioniert. Richtig harte Tests z.B. mit gleichzeitigem Kopieren großer Dateien über das Netzwerk auf den Client PC habe ich allerdings noch nicht durchgeführt. Auf dem Linux PC läuft der DVBViewer unter Wine (siehe hier), und selbst bei hoher CPU-Last sind mir bislang keine Aussetzer begegnet.

 

Was ebenfalls für die These spricht: Bislang hat sich hier noch niemand über Diskontinuitäten beschwert, der eine Fritzbox Cable als Sat>IP-Server verwendet - auch die hat ja ihren eigenen Switch unter voller Kontrolle. Ob sich das auf alle Netzwerkverhältnisse verallgemeinern lässt, weiß ich jedoch nicht. Ein Restrisiko bleibt immer.

 

Wenn der Server und Client (mit zwei Netzwerkadaptern) direkt verbunden sind, also die einzigen Teilnehmer in einem separaten dedizierten Netzwerk, in dem sich nur Sat>IP abspielt, dürfte das Risiko von Aussetzern = 0 sein.

 

vor 36 Minuten schrieb JumpySkippy:

Wie verhält es sich allgemein mit den Datenraten SAT>IP im Vergleich zur Direktübertragung über die PCIe-Schnittstelle? Die reinen "Nutzdaten" sind bestimmt die gleichen?

 

Nein. Via PCIe (und auch USB) liefern DVB-Karten mit BDA-Treiber im allgemeinen den Datenstrom des ganzen Transponders, also alle auf der Frequenz vorhandenen Sender auf einmal - das können bei Astra-Transpondern mit hoher Symbolrate an die 60 MBit/s sein, auf anderen Satelliten mehr. Die Anwendung sucht sich mittels PID-Filterung heraus, was sie braucht.

 

Bei Sat>IP filtert bereits der Server gemäß den Angaben des Clients. Der Server sendet also nur das, was der Client haben will. Bei einem ARD HD-Sender sind das vielleicht 14 MBit/s, wenn es hoch kommt - im Einzelfall hängt es davon ab, was auf dem Sender gerade läuft. Fußball braucht viel Bitrate, Zeichentrick viel weniger. Werden gleichzeitig weitere Sender aufgenommen oder wiedergegeben, erhöht sich die Bitrate entsprechend.

 

Ein Sat>IP Client kann vom Server auch den ganzen Transponder anfordern, aber das machen DVBViewer & Media Server standardmäßig nicht. Für einen Härtetest mit hoher Bitrate nimmt man am besten den TransEdit Analyzer. Der will immer den ganzen Transpondervom Server  haben.

 

[DetlefM]

Ich habe nur Erfahrungen mit einem selbstgebauten PC vs.  einem HP ThinClient. Der ThinClient war sparsamer aber hatte Aussetzer. Der PC hat keine. Beide waren normal im Netzwerk.

[Trill Ian]

Grundsätzlich ist es immer besser, den Octopus in einem getrennten LAN, in dem ansonsten NIX los ist, laufen zu lassen. Kostet ja heute nicht mehr die Welt.

Das Problem ist dabei allerdings, dass der Octopus in der Grundversion unbedingt einen DHCP Server braucht, um in die Pötte zu kommen.

Zum Glück kann man seit 2.x nun die Adressen statisch vergeben, aber immer noch muß man ihn dazu anfangs ins "normale" Netz aufnehmen, die Netzwerkparameter (für das separate Netz) vorkonfigurieren und dann umstecken.

Dabei ist zu beachten, dass bei diesem Aufbau keine Update funktionieren (es sei denn man bringt dem Aufnahmeserver bei, als Gateway zu funktionieren) und DD aus unerfindlichen Gründen vergessen hat, einen Zeitserver einstellen zu können (geht nur über DHCP). Der Oktopus hat also keine vernünftige Uhrzeit (was im Normalfalle aber nix macht, denn die Aufnahmen steuer ja der PC)

Alternativ kann man als Aufnahmeserver eine Kiste nehmen und darauf eine Windows Server Version (bis 2019) installieren. Da kann man dann auch einen DHCP Server laufen lassen, der den Oktopus mit validen Daten versorgt.

Discontinuities=0

Selbst beim Streamen vom Mediaserver, denn das macht er dann ja im anderen LAN.

 

Dieses Qos Feature ist normalerweise eine nette Absichtserklärung. Es funktioniert nur, in absolut minimalen LANS. Alle Geräte müssen an dem einen Switch angeschlossen werden. Und da sowohl Octopus, als auch Fritzbox nur 4 Ports haben, ist das nur was für absolute Bonsai Installationen.

[JumpySkippy]

Danke für die vielen ausführlichen Antworten und Input!

 

Ich könnte theoretisch auch gleich eine Octopus NET SL SX8 nehmen und im Fall, dass es wirklich schlecht funktioniert bzw. Aussetzer auftreten, die Digital Devices Max SX8 ausbauen (denn diese ist laut DD im Gehäuse verbaut) und auf "herkömmliche" Weise im PCIe-Steckplatz eines PCs verwenden. Ist preislich natürlich höher angesiedelt und einen PC für dem DVBViewer Media Server benötige ich in beiden Konstellationen.

 

Habt Ihr eventuell noch Empfehlungen für einen stromsparsamen Mini-PC (möglichst gleich mit 2 LAN-Ports), der trotzdem genug Power hat, um die Datenströme von bis zu 8 Tunern gleichzeitig  zuverlässig auf SSD schreiben kann?

[Griga]

vor 1 Stunde schrieb Trill Ian:

Dieses Qos Feature ist normalerweise eine nette Absichtserklärung. Es funktioniert nur, in absolut minimalen LANS. Alle Geräte müssen an dem einen Switch angeschlossen werden.

 

Nicht unbedingt. Alle Sat>IP Clients, die aufnehmen, sollten an dem (Octopus-)Switch angeschlossen sein. Octopus Net selbst kann wiederum am Router angeschlossen sein (hier eine Fritzbox) und reicht dann Internet & Co an die Clients durch, wobei der Sat>IP-Traffic priorisiert wird. Soweit meine Erfahrung (ohne Anspruch auf Allgemeingültigkeit)...

 

[Trill Ian]

vor einer Stunde schrieb Griga:

n dem (Octopus-)Switch angeschlossen sein. Octopus Net selbst kann wie

Jaja, das ist ja, was ich mit "Spielzeug" Netz meine...

KANN gutgehen, MUSS aber nicht.

Und wenn er wirklich auf der sicheren Seite sein will, führt kein Weg an einer Netztrennung vorbei.

 

[Griga]

Ich würde mir erst mal die ganzen Konfigurationsverbiegungen für ein separates Netzwerk ersparen, sowohl den Sat>IP-Client als auch den Router an den Octopus Net Switch anschließen und schauen, wie es läuft, aber mir eine zweite Netzwerkkarte als Option offenhalten. Der Client PC sollte also die Möglichkeit bieten, so etwas nachzurüsten.

 

Eine Rolle könnte auch der verwendete Netzwerkadapter bzw. sein Treiber spielen. Es gab hier schon Fälle, in denen eine PCIe-Netzwerkkarte als Ersatz für den Onboard-Adapter Probleme gelöst hat.

 

[tizian1998]

Moin,

 

passt zwar nicht ganz zu Deiner geplanten Konfig, hilft Dir aber eventuell bei Deiner Entscheidung:

Ich habe einen Windows Server auf einem HPE ProLiant ML10 v2 mit dem Media Server laufen und greife über mein nicht separiertes Netzwerk auf zwei Digibt R1 zu. Die beiden hängen via Unicable an meiner Satschüssel und ich greife über den Mediaserver acht Tuner ab, zudem streame ich das TV Programm an diversen Nvidia Shields mit Kodi.

Hab am Anfang mal einen "Lasttest" mit fünf gleichzeitigen Aufnahmen gemacht, was problemlos funktioniert

Am Server habe ich die (Fest-)Platten nicht mal im RAID-Verbund laufen, da ich an Kapazität nachrüsten wollte, was zum benötigten Zeitpunkt günstig ist. Für das JBOD nutze ich Drivepool, um zusätzlich, zu einem kompletten Backup, noch die Möglichkeit habe, auf die Schnelle eine Platte tauschen zu können, ohne das komplette Backup zurückspielen zu müssen.

Vermutlich sind noch mehr Aufnahmen lediglich durch die Plattenperformance begrenzt, netzwerktechnisch ist da noch Luft....

 

Gruß

Kai