streamdev als Ersatz für Koax-Kabel

Zitat von schmirl

Wenn Server und VDR-Client an den Switch-Ports A und B hängen, können Rechner an Ports C und D problemlos Daten austauschen ohne dass es die Kommunikation zwischen A und B stört. Insbesondere bei billigen Switches mag es sicherlich eine Obergrenze geben, wieviele Gigabit der Switch maximal übermitteln kann, aber die sollte bei mehreren Gigabit liegen. In diesem Szenario brauchst Du den Switch also nicht weiter beachten.

Wenn C und D mit dem Server auf A intensiv Daten austauschen während A und B streamen sieht es dagegen anders aus. Die Priorisierung kann hier aber entweder im Switch oder eben mit tc im Server passieren.

Stimmt, nachdem wir ja Switches verwenden und keine Hubs...
Gestern lief das ganze einwandfrei über mehrere Stunden. Egal ob man gezappt hat oder länger eine Sendung geschaut hat, es lief immer ohne Probleme.
Ausserdem ist mir aufgefallen das der PC schneller hochfährt und früher ein TV-Bild anzeigt.

Mit dem Thema QoS bin ich auch schon ein Stück weiter.
Hab hier eine Seite gefunden die einfach erklärt wie man mit tc umgeht: http://mirrors.bieringer.de/Linux+IPv6-HOWTO-de/x2496.html

Daraus ist dann das entstanden:

sudo tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 1000Mbit
sudo tc class add dev eth0 parent 1: classid 1:1 cbq rate   100Mbit allot 1500 bounded
sudo tc filter add dev eth0 parent 1: protocol ip   u32 match ip  protocol 6 0xff match ip dport 2004 0xffff flowid 1:1

Das reserviert 100 MBit/s für den Port 2004 auf dem Server.
Hab es mit iperf getestet und bin auf 94,xx MBit/s gekommen. Danach hab ich mit meinem PC eine große Datei vom Server runterkopiert und gleichzeitig mit iperf gemessen und bin wieder auf 94,xx MBit/s gekommen.
Ich hab beim kopieren auch schön gesehen wie die Transferleistung runter ging und nach dem iperf Test wieder rauf.

Bin mir nur noch nicht sicher ob ich die tc Befehle irgendwo noch eintragen muss damit es auch einen Neustart überlebt oder ob das automatisch gespeichert wird.

Außerdem hab ich meinen zweiten Client auf streamdev umgestellt (ebenso DVB-C Karte raus). Läuft wie auf meinem anderen Client sehr gut.
Mal schauen was die Zeit bringt...

EDIT:
Gerade noch einen Test mit einem Client schauen und Datei vom Server auf PC runterkopieren: TV-Bild läuft ohne aussetzer, zappen geht auch sehr schnell und der Kopiervorgang läuft mit 96,xx MByte/s

Zitat von schmirl

Über Port 2004 übermittelt streamdev lediglich die Befehle. Der eigentliche Stream wird über dynamisch ausgehandelte Ports übertragen. Eventuell genügt es Dir, anstelle des Ports einfach auf die Client-IP zu filtern. Ansonsten müsstest Du auf das DSCP/ToS-Feld gehen. Folgender Filter sollte passen:

Code

sudo tc filter add dev eth0 parent 1: protocol ip u32 match ip protocol 6 0xff match ip tos 0x88 0xfc flowid 1:1

[EDIT]Streamdev nutzt 0x88, nicht 0xb8[/EDIT]

Danke, das würde ja bedeuten das die Bandbreite trotz dem Kopiervorgang noch ausreichend war... Oder wertet der Kernel vielleicht die DSCP-Informationen aus den streamdev-Paketen aus?
Sicher, 96Mbyte/s sind 768MBit/s. Da ist noch etwas Luft bis 1GBit/s.
Dann wären meine Sorgen ja total unbegründet. bei über 200MBit/s Reserve könnte man noch einige Clients versorgen....

Hier nochmal ein kurzes Update:
Bin mit der streamdev Lösung sehr zufrieden, bei meinem Client im Wohnzimmer hatte ich seit dem dist-upgrade überhaupt kein Problem mehr.
Beim Client im Schlafzimmer hatte ich das Problem das nach etwa einer Minute das Bild stehen geblieben ist und für ca. 30 Sekunden kein umschalten möglich war.
Hab mir dann die Logs am Server und Client angesehen und nach etwas googlen fand ich den Thread:
PANIC: watchdog timer expired
Problem ist das egpsync-Plugin das in meinem Fall den VDR am Server zum neustart zwingt. Hab jetzt wie vorgeschlagen bei epgsync auf Kanalweise synchronisieren umgestellt und jetzt läuft es.
Bin immer noch begeistert davon, vor allem die flotten Umschaltzeiten sind cool. Kann mich noch an meine Versuche mit Windows und DVBViewer erinnern. Wenn das zappen unter 3 Sekunden lief war das schon super. So wie es mit dem VDR und streamdev läuft erkenne ich keinen wesentlichen unterschied zu der früher eingebauten DVB-Karte.

Zitat von Mreimer

Braucht es denn epgsync? Schau dir mal die Man-Page von streamdev genauer an. Streamdev sollte fähig sein, dein DVB-Signal so zu streamen, dass dein Client-VDR über ganz normale VDR-Funktionen zum EPG kommt.

Wenn ich im streamdev Filter Streaming aktiviert habe ist da zappen langsamer bzw. das zappen selbst geht schon schnell aber das bild bleibt nach ca. einer Sekunde kurz hängen.
Ausserdem hab ich mit epgsync für alle Sender gleich ein EPG ohne das ich draufgezappt habe. Das ist vorallem für das zappilot Plugin praktisch.
Allerdings hab ich seit einigen Tagen ein neues Problem, teilweise stehen Sendungen doppelt oder sogar dreifach im EPG. Bei manchen ist die Start-Zeit identisch, bei manchen um ein paar Minuten unterschiedlich. Es ist aber nicht bei allen Sendern. Noch hab ich keine Ahnung woran das liegen könnte...