Jetzt mal eine ganz andere Idee (auch wenn es nicht so klingt - ja das ist ernst gemeint), die Octo bei Ebay rein und für das Geld eine ordentliche kaufen und vom Restgeld einmal volltanken ?
Octopus Net im Zusammenspiel mit TVHeadend
-
pacoma -
5. Juni 2016 um 08:51 -
Erledigt
-
-
Ein paar Gedanken zu dem Thema von mir:
Mal an DD bzgl. der aktuellen Fehlerumgehung / aktuelln Feststellungen zu dem Problem herangegangen? Evtl. haben die doch noch eine Idee oder sehen einen Workaround oder gar eine Firmwareverbesserung aus den bisherigen Erkenntnissen?
Evtl. ist es ein Problem seitens TVH? Mit anderer TV Software scheint es ganz gut zu laufen - z.B. seitens DVBLogic ließt man nicht viel Negatives, im Gegenteile - dort läuft es sehr gut, selbst mit CI Anbindung / Erweiterung.
Hardware Veränderung hilfreich? Habt ihr zufällig die gleiche / ähnliche Netzwerkkarte verbaut - mit anderer Hardware für den Server mal durchtesten und die Empfehlungen von mam folge Leisten. Ich bin zwar Netzwerktechnisch nicht so fit wie er, aber kann das Ganze nachvollziehen was er berichtet.
Also OctopusNet mit Ihrem Switch oder einem hochwertigen Switch direkt an den TVH Server (dieser benötigt 2 Netzwerkkarten) und die 2. Karte an den "normalen" Switch / Router wo die Clients hängen. Und evtl. wirklich über ein OS Wechsel nachdenken / Umdenken was die Server - Client Struktur angeht. -
-
Evtl. ist es ein Problem seitens TVH?
nein, tritt meines Wissens überall auf - wäre auch mehr als logisch weil die Pakete ja auf Hardware Ebene fallen gelassen werden - bei Tvh kann man es aber sehr leicht erkennen (hat extras Status dafür) + Kodi ist relativ empfindlich auf solche Störungen - DVBViewer schluckt das besser weg bzw da fällt es nicht so auf vor allem bei kleineren Fehlern im Stream bemerkt man nicht viel. Wenn das Netzwerk nur "Schlecht genug" ist wird es auch am DVBViewer nicht mehr zum angucken. Derzeitiger Status ist das billigste HW das hinbekommt, Premium Made in Germany leider nicht.
-
-
Danke, aber ich sehe gerade du hast den Thread in keinem Fall gelesen...
Tjua na dann, viel erfolg!
-
Das war der Grund für mich, warum ich die MaxS8 wieder aus dem OctopusNet Gehäuse ausgebaut habe und jetzt direkt im TV-Server betreibe.
Gut, ich musste durch eine Stahlbetondecke ein Loch bohren für das Satkabel um es zum Server legen zu können. Dank JESS-LNB war es aber zum Glück nur ein Loch/Kabel.Keine sichtbaren Fehler mehr im Stream und den Aufnahmen.
-
-
Ich habe den Octopus mittlerweile absolut stabil am laufen.
Erstmal habe ich mir einen richtigen Managed Switch gekauft und dann meinen Server per Link Aggregation angeschlossen.
Somit habe ich quasi 2x Gigabit. Das ich diese zum Server während der Octopus Verbindung zeitgleich voll auslaste ist sehr unwahrscheinlich. Ohne Link Aggregation und voller Netzlast gab es Probleme. Auch ohne den Managed Switch hatte ich auch ohne volle Netzlast Paketverluste mit dem Octopus.
TCP wäre mir auch lieber, aber da braucht man erstmal nicht drauf zu hoffen. -
-
Ich hab nen 16/18port von der dell x series genommen. Haben alles an features was so ein level 2 switch braucht und super preis leistungsverhältnis.
Klick
Die dlink smartmanaged switches können soweit ich das sehe kein link aggregation. Gerade für meinen server eine Sache die ich nicht mehr missen möchte.
Smartmanaged switches können das leider meist nicht, dafür sind diese auch günstiger.
Achja zu den ports:
Ich habe die 2 ports meines servers über link aggregation gebündelt. Es gehen auch mehr, müsste ich aber noch ne karte einbauen. 2gigabit reichen erstmal für einen reibungslosen betrieb zuhause. -
Ich habe den Octopus mittlerweile absolut stabil am laufen.
das klang super, was danach kam hat das aber irgendwie recht sarkastisch klingen lassen
-
-
ne man kriegt den schon absolut stabil zum laufen. Nur müssen die Netzwerkbedingungen absolut perfekt konfiguriert sein sein. Ein unmanaged Switch oder volle Netzlast ohne QOS und schon bekommt man Probleme. Das ist ähnlich wie bei VOIP, sobald das Netz voll ausgelastet ist, muss festgelegt wo die Prioritäten liegen.
-
-
Hat er indirekt. Ich versuche es mal zu erklären:
Der Octopus zum Switch ist nur eine Verbindung. Das ist aber nicht das Problem. Durch den Switch wird er ja mit dem Server verbunden. Und diese Verbindung ist gedoppelt.
Ich gebe ja keinen weiteren Traffic auf die Verbindung des Octopuses sondern auf die vom Server und diese würde dann wieder die Verbindung zum Octopus stören. Wäre diese nicht gedoppelt, würde im schlimmsten Fall bei voller Gigabit Auslastung das die Übertragung vom Ocotpus zum Server stören. Habe ich schon getestet und führt zu Paketverlusten.
Das wäre immer der Fall wenn ich etwas zum Server sende, was der Octopus ja auch tut. Daher entsteht das Problem immer bei der Verbindung zum Server bzw. dessen Empfang.
Ich hätte weiterhin daher nur ein Problem wenn ich durch andere Geräte volle 2Gbit zum Server sende. Kommt jedoch bei mir quasi nie vor.
Dieses Problem könnte auch mit TCP entstehen, da man ja keine Pakete nachfordern bzw. am SatIp Server puffern kann.
Bei UDP ist jedoch ein guter Switch absolut notwendig, da du selbst bei unter Vollast Kollisionen und Paketverluste bekommst.Richtig genial wäre wenn ich den RTP/UDP Stream über QOS priorisieren könnte, diese Möglichkeit habe ich jedoch selbst bei meinem managed Switch nicht gefunden. Da hat der DD Support schon recht aber keine Ahnung wie ich das machen soll. Vllt kann dies ein sau teures Cisco Gerät...
Viel wichtiger ist jedoch erstmal ein hochwertiger Switch, der bei normaler Last keine RTP/UDP Pakete droppt.Ich hoffe man kann es verstehen. Ein Bild malen wäre jedoch anschaulicher.
-
-
Ich habe nur am Switch selbst keine prio einstellungen auf port basis gefunden. Vllt benötigt man einen Level 3 switch welcher eher einem Router entspricht? Eine priorisierung wäre die perfekte Lösung, nicht nur beim octopus.
-
Ich habe nur am Switch selbst keine prio einstellungen auf port basis gefunden. Vllt benötigt man einen Level 3 switch welcher eher einem Router entspricht? Eine priorisierung wäre die perfekte Lösung, nicht nur beim octopus.
L2-Switche kennen keine "Ports". Sie können nur auf den Qos Header des Ethernetpaketes reagieren (und das kann man auch sicherlich im Switch irgendwo konfigurieren).
Der Erzeuger des Paketes muss dort also eine Priorität eintragen, im Switch kann man den Werten dann meist "low", "medium" und "high" als interne Bearbeitungspriorität zuordnen.
(Problem hierbei ist allerdings meistens, dass jeder meint, "high" sei gerade richtig für ihn, deshalb funktioniert das System oft nicht).Hier mal ein Beispiel:
Defaultmässig stehen also alle (physikalischen, nicht TCP oder UPD) Ports auf "Medium". Dieser Wert wird benutzt, wenn die ankommenden Pakete KEINE Qos Informationen enthalten (Normalfall). Setzt eine Applikation diesen Wert selber (muss der TVHead also im Programm erledigen), so finden sie hier Beachtung (wenn "WRR" aktiviert wäre, bei "Strict Queuing" ignoriert der Switch den Inhalt und setzt immer den Portwert ein).
Zusätzliches Problem dabei: Switche ÄNDERN die Werte bei der Weitergabe! Wenn, wie hier im Beispiel gezeigt, alles auf Medium gezwungen wird, so enthält auch das zugestellte Paket den Wert Medium, unabhängig davon, was vorher drinstand!
Also bei der Weiterleitung zwischen mehreren Switchen reicht ein schwarzes Schaf, um die sorgsam konfigurierten Einstellungen wieder platt zu machen!
(Das ist auch der Grund, warum Qos meist nicht funktioniert und der Admin in den Tisch beisst. So ein 15€ Switch-chen kann einem den ganzen Spass verderben. Eigentlich sollten "dumme" Switche NICHTS tun, manche Chinesen sind aber der Auffassung, es wäre doch cool, wenigsten immer Medium reinzuschreiben, auch wenn es intern gar nicht ausgewertet wird...) -
-
Vielen dank für die tolle Beschreibung. Wie würdest du das Ganze dann handeln? Der octopus wird sicher keinen prio header mitgeben. Zudem wie du schon sagst, werden andere sagen sie sind immer high und dann ist die ganze priorisierung für den hugo. Würde dann denn ein Level 3 switch mehr sinn machen? Ich würde gerne manuell sagen das zb alles von port xy high prio ist. Zb sat ip port und tvh. Port 80 dann low prio usw. Ich suche eine Möglichkeit das sauber zu steuern. Derzeit läuft es zwar perfekt aber ich denke man muss es noch besser hinkriegen.
Besten Dank schonmal -
Der octopus wird sicher keinen prio header mitgeben.
Doch, doch, genau DAS macht er (und sein Switch) total richtig.
Üblicherweise sind es andere Komponenten, die dann den Spielverderber geben (z.B. billige Router mit eingebautem Switch usw.)DD stellt es sich idealerweise so vor, dass die Octopus Kiste genau IN DER MITTE des Hauslans ist, also alles an ihrem Switch angeschlossen.
Das passt aber meist nicht mit der Kabelwirklichkeit überein und sowieso sind 4 Ports heute nicht mehr so das Maß aller Dinge.
Ach ja, Deine mutige Idee mit der Portaggegation ist hübsch, funktioniert aber nur in 50% der Fälle
Bei der Portbündelung wird die Portauswahl erzeugt über das (2 Ports) oder die (3-4 Ports) letzten Bits der MAC Adresse der Klienten an diesem Port. Wenn also Dein Oktopus und einer Deiner Klienten hinten dasselbe Bit haben, so kommen sie sich trotzdem wieder in die Quere. Die meisten Leute glauben, da würde eine echte Lastverteilung 1,2,1,2 usw. pro Verbindung erreicht, richtig sonnige Gemüter träumen sogar von 2,3 oder gar 4Mbit/s, aber das ist alle Humbug.
(Das LAN würde auch dabei dauernd zusammenbrechen, denn bei jedem Wechsel müsste immer der komplette Spanning Tree mit übertragen werden, damit wären die Pausen länger, als die Übertragung der wirklichen Datenpakete).
Du hast also bislang einfach Glück gehabt
-
-
Hmm! Also sollte ich besser meinen server über den Octopus Switch laufen lassen? Ich weiss nämlich nicht wie ich sonst meinen switch konfigurieren soll, dass in 100% der Fälle nix in die Quere kommt. Der Octopus switch scheint irgendwas wirklich richtig zu machen, da ich hier auch nie errors hatte als mein server direkt angeschlossen war.
Vom server zu den clients wäre die Verbindung dann jedoch wieder Server->OctopusSwitch-> normaler switch -> clients.
Nur da gehts dann per tvh und wohl per tcp zu den clients, also wie bei einer internen Karte -
Ja genau, das sollte dann schon mal gut funktionieren. Verhindert natürlich nicht, dass der Server "von der anderen Seite" aus zugeschossen wird, aber zumindest bleibt Platz für die Videopakete, so dass die Aufnahmen störungsfrei sein sollten, LiveTV aber Probleme haben kann. Den Stand hab ich auch hier, aber ich nehm zu 99,5% auf und schaue kaum live, somit störts mich nicht.
Irgendwie kann ich mir nicht vorstellen, dass Dein Dell-Dinges das nicht können soll. Ab der 100€ Klasse ist das eigentlich überall Standard.
Ich find allerdings nirgends ne Anleitung zu Deinem Teil, also kann ich da nicht wirklich was zu sagen.
"Halbgute" Switche sollten die Infos zumindest heile durchlassen, wenn auch nicht selber darauf reagieren.Update: hab die Anleitung gefunden. Kapitel 14: Quality of Service... Wo ist Dein Problem???
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!