Octopus Net im Zusammenspiel mit TVHeadend

  • Das Dell Dingen sollte eigentlich viel können, habe es mir extra deswegen gekauft :)
    sehr gut, dass du die Anleitung hast, ich schick dir mal nen screenshot von den Settings. Ich weiss nicht wie ich bei QOS das entsprechend priorisieren soll.
    Ich habe ohne Link Aggregation Ausfälle wenn ich vollen Traffic an den Server sende und gleichzeitig vom Octopus einen Videostream zum Server sende.(kommen sich dann ohne QOS in die Quere und es laggt fürchterlich) Nur Linkaggregation behebt das Problem da ich dann mehr Bandbreite habe. Super wäre es wenn ich das zusätzlich über QOS lösen könnte.

  • Nee, sorry, ich kenne das Gerät nicht und Knochenwerfen ist nicht so mein Ding.

    Du wirst Dich schon selber durch die Anleitung beißen müssen und rumexperimentieren.

    Ich konnte nur nicht glauben, dass die Kiste das nicht können sollte. Und, wie Dein eigener Screenshot beweist, ist dem auch nicht der Fall.

  • Kannst du mir wenigstens einen Tipp geben nach was ich suchen soll damit eine Priorisierung der Octopus Streams möglich ist?
    Ich habe mir ja die Konfiguration schon angeschaut. Ich kann nur Bandbreiten limitieren (hab ich versucht, das klappt). Ich kann den Switch Ports Klassen anlegen, Richtlinien vergeben aber explizit dafür sorgen das der Octopus UDP Stream höchste Priorität hat, habe ich nicht gefunden.
    Aber wie gesagt das meiste ist auf Switchport Ebene und nix mit Hadern bzw Paketen.... :(

  • Das ist nicht so ganz einfach. Dein Dingen kann tatsächlich ALLES, das macht es sehr kompliziert.

    Trenn Dich erstmal von Deinem fundamentalen Denkfehler:
    * Du kannst nichts priorisieren, Du kannst nur begrenzen!

    Grundsätzlich hast Du je nach Gerätetyp entweder 4 oder 8 Queues, denen kannst Du Bandbreiten zuweisen.
    Du musst die unteren Queues beschränken, damit "Luft" für die höheren Klassen bleibt.
    In der Grundkonfiguration werden alle gleich behandelt, deshalb hat das Feature keine Funktion.
    Also, krieg erstmal raus WELCHEN Typ Du da hast, ermittle aus der Anleitung WIEVIEL Queues unterschieden werden und fang dann an, zu Beschränken.

    (ich rechne mal mit 4 Queues, denn Du wirst ja wohl kaum das Super-Duper-Teil gekauft haben...)

    * setz erstmal den Defaultwert für "untagged" Packets runter auf Stufe 2
    * alle Ports auf "strict" stellen (damit erzwingst Du die Überprüfung jedes Paketes)
    * Stufe 1-> max 10Mbit/s
    * Stufe 2-> max 300Mbit/s
    * Stufe 3-> max 500Mbit/s
    * Stufe 4-> unlimited

    Damit könnte man dann schon mal anfangen zu testen. Video sollte ohne Unterbrechungen laufen, dafür ist der Filezugriff auf den Server echt lahm...
    Anschliessend kannst Du die Werte ja langsam erhöhen, und wieder prüfen, obs noch geht.
    So kannst Du Dich ranpirschen.

    Das Ganze kann eine langwierige Angelegenheit werden, da es voll abhängt von den vorhandenen Geräten und was diese gerade so tun... Ab und zu wirds dann noch Ausreisser geben, und es darf wieder nachgearbeitet werden. Irgendwann hast Du ein Setup, wo Video stabil ist und der Rest nicht allzu lahm wird.

  • Ich werde die Anleitung mal durcharbeiten, mal sehen wie weit ich komme. Das mit der Bandbreitenbegrenzung wird aber etwas kniffelig sein.

    Wenn ich jedoch so drüber nachdenke und mal um die Ecke denke, würde es nicht noch besser funktionieren, wenn ich einfach eine kleine Intel Kiste mit TVH (NUC) an den Octopus anschließe und dann den Octopus mit dem Switch verbinde? Dann könnten doch niemals Pakete in die Quere kommen, da zwischen Octopus, NUC und Clients kein Traffic voll auslasten kann?
    Nachteil wäre ein zusätzliches Gerät.
    Mein Ziel ist es einfach die Netzlast zwischen Octopus und den Clients absolut zu minimieren, dann könnte ich mir die QOS Einstellungen sparen?

  • Dann könnten doch niemals Pakete in die Quere kommen, da zwischen Octopus, NUC und Clients kein Traffic voll auslasten kann

    doch du gehst ja dann mit dem Switch wiederum an den Router und von dort zum Rest... und wenn du dann auf dem Nuc einen Film vom Server guckst hast ja auch wieder traffic.

    Versuchs mal wie ich Router --> Octopus und alle Clienten und Server an den Switch der OctoNet anschliessen (sofern möglich)

  • Der Switch hat doch aber mehr Ressourcen als nur 1Gigabit.
    Wichtig ist doch nur die Verbindung Octopus->NUC->Switch->Client

    Schaue ich dann einen Film auf einem andren Client würde es keine Probleme geben da die Verbindung Server->Switch->Client nicht die Verbindung zum Octopus stört.
    Selbst wenn ich auf einem Client TV und Film gleichzeitig hätte (nicht praxisrelevant) würde es meine Verbindung nicht voll auslasten.

  • Hallo zusammen,

    also ich lese hier schon etwas länger mit. :)
    Ich hatte bis vor 4 Monaten nen dedizierten TV-Server (Win10) und Argus-TV als backend, DD-DVBC-Hardware. Ich spielte aber schon über 1 Jahr mit der octopusNet rum.
    Als mein ESXI-Server "kränkelte" suchte ich nach Alternativen, ich wollte es einfach "einfacher" haben/ ich werde alt :( . Leichter gesagt als getan :)
    Mein TV-Server starb schließlich, plötzlich und unerwartet, vor dem ESXI :(

    Spielt hier nicht wirklich ne Rolle, aber ich habe seit 2 Monaten 'n QNAP-NAS im Einsatz und alle Dienste laufen (direkt oder als VM) darauf.

    Ich habe aktuell keine wirklichen Probleme mit der Stabilität im Zusammenspiel mit der octopusNet, allenfalls ist mein Signal vielleicht etwas schwach. Aber selbst dass stört nicht.

    Dass Nutzerverhalten und der Weg zu den Clients/ und was auf denen noch alles läuft - spielt ne entscheidende Rolle.
    Wir nehmen so ziemlich alles, was wir mögen, auf und sehen es zeitversetzt an. Aktuell sind es 4 Tuner in der Octo, Clients im Wohnzimmer, Büro und auch Garten.

    Ich hatte auch viele Bedenken vor der Umstellung auf die octo wegen der Netzwerklast, allerdings bislang anscheinend unbegründet (zumindest mal noch *daumendrück*).

    Mein Setup (Router spielt hier erstmal keine Rolle):

    OctopusNet --> (1Gbit) --> Switch_Keller --> (PortTrunk 3x1 Gbit) --> NAS

    vom NAS: --> (PortTrunk 3x1 Gbit)--> Switch_Keller
    -->(dediziert 1 Gbit) -->Switch Wohnzimmer --> WohnzimmerClients (htpc, xbox, avr etc.)
    -->(dediziert 1 Gbit) -->Switch Büro --> Arbeitsplatz, Drucker, WLAN, etc

    Der WLAN-AP im Büro wird für den Garten per Repeater (WLAN-ac) erweitert.

    Der Router hängt am 4. LAN-Port des NAS, per ipfire.

    Zugegebenermaßen sehen wir gleichzeitig max. im Büro & Wohnzimmer - oder auch nur im Garten - fern, dies wird durch die separaten Netzwerkanbindungen vom Switch_Keller zu Wohnzimmer/ Büro getrennt.

    Im Moment habe ich nicht das Gefühl dass mein neues Setup dem eines eigenen dediziertem TV-Servers nachsteht (ausgenommen fehlendes MTD).

    @d00dl3: wieviel Clients bedienst Du denn gleichzeitig?


    ciao
    luetty

  • Hallo luetty,

    die Anzahl der Clients spielen eine eher untergeordnete Rolle. Viel entscheidender ist es, ob noch anderer Netzwerktraffic dem Traffic des Octopus "in die Quere kommt".
    z.B. sendet der Octopus an dein NAS. Gleichzeitig sendet aber auch noch eine weitere Verbindung mit voller Speed an dein NAS. Jetzt wird es ohne QOS schwierig das ganze zu priorisieren bzw. die Speed der anderen Verbindung zu drosseln.
    Ich lebe derzeit mit der Lösung von Link Aggregation. TVH läuft im Docker. Ich würde jedoch auch wieder Probleme bekommen, sobald meine 2Gbit Leitung voll ausgelastet ist. Kam bisher nicht vor und ist derzeit nicht absehbar. Richtig rund wäre dennoch ein optimiertes QOS Setup.
    Kurzum:
    solange die Verbindung Octopus -> Server -> Client nicht gestört bzw. "überlastet" wird, ist alles in Butter.
    Dein Port Trunk rettet dir wahrscheinlich erstmal die Verbindung. Wichtig ist aber hier richtiges Dynamic Link Aggregation zu nutzen. Normales Adaptive Load Balancing hilft nicht.

  • Hallo d00dl3 ,

    okay- vielleicht habe ich mich ungeschickt ausgedrückt, Sorry!. :(
    Ich nutze am Switch_Keller durchaus Dynamic Link Aggregation (802.3ad) an einem Managed Switch. Du hast natürlich Recht, sobald die Verbindung OctopusNet <-[Server] -> Client durch hohen Traffic, irgendwie, gestört wird - wird es "eng".
    Dass ganze per QoS zu priorisieren habe ich bislang nicht versucht - da in der Tat, bei mir, bislang nicht notwendig.

    Insofern war ich wohl keine Hilfe :(

    p.s. Mein TVH läuft als VM & du hast eigentlich keine 2Gbit Leitung, sondern 2x1Gbit

  • Du warst schon eine Hilfe. Es ist immer schön zu hören wie andere ihre Infrastruktur aufsetzen. Gerne mehr davon :)
    Mein TVH läuft im Docker ;) finde Docker recht genial, und verfahre auch so mit anderen Applikationen.
    Ist aber Ansichtssache. Ich könnte auch eine VM nehmen, leider gibts auf der Synology "nur" Docker als Alternative.
    Es sind in der Tat 2x1Gbit aber der Traffic verhält sich wie bei einer 2Gbit Leitung bzw. einem Kabel. Wenn ich volle 1Gbit auf den Server gebe, gibt es überhaupt keine Probleme. Daher verwendete ich den Begriff 2Gbit. Machst du 3,4fach Link Aggregation wird es entsprechend mehr. Anders ist es bei Adaptive Load Balancing, hier verhält es sich bei mir wie 2x 1Gbit, also 2 getrennte Kabel. Und es kommt auch schon bei einer 1Gbit Auslastung zu Problemen.

  • Hallo zusammen,

    ich will mich mal in die Runde einklinken.

    hab auch eine Octopus V2 NET 4xDVB-S2 und kann im großen und ganzen nix schlechtes darüber sagen.
    Meine Beweggründe waren, bei Renovierung wollt ich kein Koax mehr durchs Haus legen da ich eventuell die Position der TV´s ändern will.
    Also alternative LAN.
    Da ich am Anfang etwas bequemes wollte, ohne Server und Schnick Schnack, dachte ich ist die Octopus genau das richtige.
    Also Octopus eingebaut + RPi 3 als Client + LE drauf und mit der Octopus Client Software rumgespielt....
    Bei Zeiten stellte sich raus, DVR geht da nicht also musste was anderes her.

    aktuell installierte Lösung, welche bei mir Fehlerfrei läuft:

    Octopus Net für 4 Teilnehmer
    Die TV´s direkt am Octopus Switch.
    Als separates Backend nutze ich jetzt ein Odroid XU4 mit Ubuntu Mint welcher am normalen Switch hängt.
    Folgende Sachen laufen alles darüber:
    - TVheadend 4.1-2332
    - kompletter SMB
    - JDownloader mit Desktopoberfläche.

    Netzwerk ist mit 4 Teilnehmern (2x LAN + 2x WLAN getestet) + normales Netzwerktraffic bei mir bis jetzt noch nicht überfordert gewesen.

    An der einzigen Stelle, wo ich Pakete verliere, ist beim umschalten, aber da ist es mir egal.

    Über diese Lösung kann ich grundsätzlich nichts schlechtes sagen...
    Außer das man auf dem XU4 am Anfang, vor allem als Linux Neuling ein wenig Zeit mitbringen muss.

    Grund warum XU4 und nicht C2:
    2x USB 3 wo meine Festplatten dran hängen + stärkerer Prozessor

    Grüße Wulfi

    Backend: TVheadend auf Ubuntu 16.04 Odroid XU4
    Clients: 32" Samsung H6410 +RPi 3 LE 8
    49" Sony KD-49XD8005 + RPi 3 LE 8 + AV - Receiver Yamaha RX-V481
    Sat IP Wandler: Octopus V2 NET DVB S2 für 4 Teilnehmer

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!