Derrick Posted June 2, 2014 Posted June 2, 2014 Ich denke nicht, dass QoS angefasst wurde, falls es da vom RS überhaupt was zu beeinflussen gibt. Allerdings gibt es unterschiede zwischen UDP und TCP. UDP datagramme können schon mal verloren gehen. Deshalb habe ich dir auch geraten, tests mit UDP und TCP zu machen. Änderungen auf dem gebiet hat es allerdings schon gegeben. Da kann @Griga sicher noch was beitragen
Griga Posted June 2, 2014 Posted June 2, 2014 ich gehe mal davon aus, dass der RTSP Teil vom DVBViewer/RS/TransEdit NICHT irgendwelche QoS Richtlinien setzt? Richtig. Aber OctopusNet macht etwas in Richtung QoS (oder sollte es machen), soweit ich weiß. Jedenfalls hat ein Digital Devices-Entwickler das bei einer Diskussion über eventuelle Paketverluste erwähnt. Unklar ist noch, ob es durch Switches im LAN ebenso wie im WLAN oder Internet unter bestimten Bedingungen zu vertauschten Datenpaketen kommen kann, d.h. die Pakete treffen im Client in einer anderen Reihenfolge als abgesendet ein. Der DVBViewer Pro 3.5.1 enthält neuerdings Gegenmaßnahmen, d.h. er bringt die Pakete nach dem Empfang gegebenenfalls in die richtige Reihenfolge. Im Recording Service und in TransEdit 4.0.x ist die Verbesserung noch nicht implementiert (kommt im nächsten Release), d.h. beide würden bei vertauschten RTP-Paketen massiv fehlende Pakete registrieren. Deshalb hatte ich danach gefragt, ob das Problem auch auftritt, wenn der DVBViewer den Stream direkt vom OctopusNet erhält.
MaM Posted June 2, 2014 Author Posted June 2, 2014 Unklar ist noch, ob es durch Switches im LAN ebenso wie im WLAN oder Internet unter bestimten Bedingungen zu vertauschten Datenpaketen kommen kann, d.h. die Pakete treffen im Client in einer anderen Reihenfolge als abgesendet ein. Deshalb hatte ich danach gefragt, ob das Problem auch auftritt, wenn der DVBViewer den Stream direkt vom OctopusNet erhält. >Richtig. Aber OctopusNet macht etwas in Richtung QoS (oder sollte es machen), soweit ich weiß. Jedenfalls hat ein Digital Devices-Entwickler das bei einer Diskussion über >eventuelle Paketverluste erwähnt. Ja, genau DEN Eindruck hatte ich monatelang, lief alles so glatt, da mußte jemand was dran gemacht haben. Das Dingen war zwar sehr teuer, aber Stabilität geht mir über alles und da guckt man nicht auf die Euronen. Nur muß unlängst irgendwas kapputgegangen sein, und dieser Teil funktioniert nicht mehr :-( >Unklar ist noch, ob es durch Switches im LAN ebenso wie im WLAN oder Internet unter bestimten Bedingungen zu vertauschten Datenpaketen kommen kann, d.h. die Pakete >treffen im Client in einer anderen Reihenfolge als abgesendet ein. Wenn es gute Switche sind, sollten sie das tun, es ist ihr Job gemäß QoS Regeln umzusortieren. Allerdings ändert sich dabei nicht die Reihenfolge, sondern nur die Verteilung der einzelnen Sessions im Stream (nicht der vom Dach, sondern der im LAN :-) ). >Der DVBViewer Pro 3.5.1 enthält neuerdings Gegenmaßnahmen, d.h. er bringt die Pakete nach dem Empfang gegebenenfalls in die richtige Reihenfolge. Im Recording >Service und in TransEdit 4.0.x ist die Verbesserung noch nicht implementiert (kommt im nächsten Release), d.h. beide würden bei vertauschten RTP-Paketen massiv >fehlende Pakete registrieren. Ja, hab ich gelesen, ich glaube allerdings nicht daran, dass das irgendwas hilft, bzw. überhaupt zum Einsatz kommt. >Deshalb hatte ich danach gefragt, ob das Problem auch auftritt, wenn der DVBViewer den Stream direkt vom OctopusNet erhält. Musse nur richtig erklären, dann macht MAMi auch brav alles. Nur der Eine sagt "nur TransEdit ist aussagekräftig", und der Andere will es so rum.... Ich weis doch nicht, wer der Boss ist und wem ich Gehorsam schulde Außerdem hab ich ja gleich einen drüberbekommen, als ich die Tests auf ne Workstation verlagern wollte... Aber ohne Monitor ist das Betrachten eines TV Bildes auf dem Server etwas schwierig, per Remote Desktop geht es zwar irgendwie, aber das zuckt dermassen, da weis man nicht, ob es eine Störung ist, oder nur die Bildkomprimierung der LAN Übertragung. Also, eben mal wie gewünscht mit DVBViewer5.3.1 direkt auf den Oktopussy: geht erstmal. * QoS Richtlinie deaktiviert, Filetransfer angeworfen: DAS GRAUEN PUR! (wir reden hier nicht von Störungen, sondern ein heiles Bild & Ton ist die Ausnahme solange der Transfer läuft) * QoS Richtlinie wieder aktiviert, noch n Transfer angeworfen: NICHTS! Sauberstes Bild & Ton! (und der Transfer läuft trotzdem wie geschmiert) Ist also ein Unterschied wie Tag und Nacht und die Effekte sind sofort sichtbar! Also muß ich wohl darauf schließen, dass das OctoNet irgendwie kaputtgegangen ist (wohl der interne Switch, der nicht mehr so funktioniert, wie früher). Meine manuelle Richtlinie ersetzt nun die von denen hart verdrahtete und propagierte... Andererseits... So dramatisch, wie man das hier direkt "erleben" kann sollte euch vielleicht dazu veranlassen, in diese Richtung eventuell auch was in den DVBViewer & Co zu programmieren. Es ist ja nun absolut unschädlich, wenn auf der Kiste, wo das Programm installiert ist, RTP Pakete bevorzugt werden. Könnte bei anderen Devices durchaus auch hilfreich sein (ich sollte mal wieder eins von den "abgelehnten" neu kommen lassen und in diese Richtung testen... wenn dann die Dropouts auch verschwunden sind, kann man viel Geld sparen...)
MaxB Posted June 2, 2014 Posted June 2, 2014 Netzwerk sind jeweils 4*1Gbit/s Realtek Karten in einem PCIe 4x Slot. jeweils 3 sind gebündelt, die vierte ist immer der Managementzugang. Man kommt natürlich trotz Bündel nie über die 110Mb/s, da jede Verbindung immer nur auf ein und demselben Port abläuft. Intern haben die Kisten dann jeweils noch nen 10Gbit/s Pseudoswitch für die VMs. Teste mal Intel Netzwerkkarten, mit Realtek bin ich auf meinen Systemen endgültig durch, denn Realtek war in meinen Netzwerken gerne für unerklärliche Diskontinuitäten verantwortlich, besonders bei parallel laufenden Dingen. Seit der Umstellung auf Intel klappt das Netzwerk zu 100% sauber...
MaM Posted June 3, 2014 Author Posted June 3, 2014 Teste mal Intel Netzwerkkarten, mit Realtek bin ich auf meinen Systemen endgültig durch, denn Realtek war in meinen Netzwerken gerne für unerklärliche Diskontinuitäten verantwortlich, besonders bei parallel laufenden Dingen. Seit der Umstellung auf Intel klappt das Netzwerk zu 100% sauber... Na ja, so macht jeder seine eigenen Erfahrungen, ich bin mit Intel durch, habe hier noch ein paar abschreckende Beispiele rumliegen, teuer und nicht funktionsfähig (z.B. doppel Gb Karten, die nicht erlauben, dass man beide Ports in denselben Switch steckt zwecks Trunking). Nein danke, hier gibt es keine Intel Hardware mehr... schon seit einigen Jahren.
blasgl Posted June 3, 2014 Posted June 3, 2014 (edited) Hallo, ich hatte es schon mal vor langer Zeit gepostet, aber ich bringe meine Erfahrungen in diesen Thread wieder ein. Mein Netzwerk sieht so aus: Recording Server -> Switch 1 -> Router-Switch -> Switch 2 -> HTPC Meine Erkenntnisse: 1. Wenn ich das RTSP-Gerät im HTPC mit UDP konfiguriere, habe ich besonders bei HD-Sender regelmässige Aussetzer. Die werden im DVB Filter als Discontinuities gekennzeichnet. 2. Wenn ich den HTPC direkt mit dem Router-Switch verbinde, d.h. "ohne Switch 2", ist das Bild bei UDP sauber. 3. Alle andere RTSP-Geräte im Netzt, die nicht am Switch 2 hängen, funktionieren bei UDP tadellos. 4. Momentan muss ich am HTPC mit TCP fahren, sonst gibt es Pixelsalat. Edited June 3, 2014 by blasgl
Griga Posted June 3, 2014 Posted June 3, 2014 4. Momentan muss ich am HTPC mit TCP fahren, sonst gibt es Pixelsalat. Gilt das auch für den DVBViewer Pro 5.3.1?
MaM Posted June 3, 2014 Author Posted June 3, 2014 (edited) >1. Wenn ich das RTSP-Gerät im HTPC mit UDP konfiguriere, habe ich besonders bei HD-Sender regelmässige Aussetzer. Die werden im DVB Filter als Discontinuities gekennzeichnet. >2. Wenn ich den HTPC direkt mit dem Router-Switch verbinde, d.h. "ohne Switch 2", ist das Bild bei UDP sauber. >3. Alle andere RTSP-Geräte im Netzt, die nicht am Switch 2 hängen, funktionieren bei UDP tadellos. >4. Momentan muss ich am HTPC mit TCP fahren, sonst gibt es Pixelsalat. Na ja, DAS Problem ist ja nun einfach zu lösen .. Du mußt wissen, Switch ist nicht gleich Switch. Die teureren ("managed") kann man per Webinface entsprechend konfigurieren, dort muß man ersmal das QoS Feature einschalten. Bei den "unmanaged" Switchen ist das Ganze mehr oder weniger Lottoglück. Manche beachten die Markierung und handeln dementsprechend Manche lassen die markierten Pakete heile durch, reagieren aber nicht selber (keine Priorisierung) Manche löschen die Markierung der Pakete (großes Datenchaos hinter dem Switch, die Auswirkungen kennst Du ja aus eigener Erfahrung) Hast Du einen der beiden letzten Typen erwischt: PECH, da hilft nur Austausch. Wobei der mittlere Typ noch relativ harmlos ist, Stufe III Dir aber auf jeden Fall den Nachmittag versaut. Die wirklich schlechte Nachricht is aber: den Dingern kann man das Verhalten von aussen nicht ansehen (und reingucken kann man auch nicht :-( )! Da gibts dann nur "Lernen durch Schmerzen"... Da inzwischen selbst managed Switche in bezahlbare Bereiche vorgestoßen sind, sollte man die paar Euronen mehr investieren. Was man selber einstellen kann, kann man auch nachvollziehen... Gib 50-100€ für nen neuen Switch 2 aus, dann klappts auch mit den HD Sendern... Ach ja, noch unbedingt beachten: Das ganze gilt natürlich für die gesamte Kette! Schon ein falsches Glied sorgt gleich für den kompletten Ausfall aller anderen Teile dahinter. (Achtung! Meist ist den Switchen in den Routern auch nicht zu trauen, ich würde die immer nur mit einem Port an einen "richtigen" Switch hängen, und die restlichen Ports nicht verwenden) Edited June 3, 2014 by MaM
MaxB Posted June 3, 2014 Posted June 3, 2014 Das es billige (GBit) Switche und Netzwerkkarten gibt, die bei UDP den Traffic "zerstören" kann ich zu 100% bestätigen, ich habe hier auch ein 8 Port GBe-Switch mit solch einem Problem herumliegen. Aber es muss definitiv kein managed Switch angeschafft werden, ich würde, falls die Anzahl der Ports vom ersten (funktionierenden) Switch ausreicht einfach einen zweiten dieses Modells anschaffen, den der scheint ja UDP sauber zu unterstützen.
Derrick Posted June 3, 2014 Posted June 3, 2014 ..wenn TCP störungsfrei ist, gbt es doch eine einfache ausweichlösung.
MaM Posted June 3, 2014 Author Posted June 3, 2014 (edited) Das es billige (GBit) Switche und Netzwerkkarten gibt, die bei UDP den Traffic "zerstören" kann ich zu 100% bestätigen, ich habe hier auch ein 8 Port GBe-Switch mit solch einem Problem herumliegen. Aber es muss definitiv kein managed Switch angeschafft werden, ich würde, falls die Anzahl der Ports vom ersten (funktionierenden) Switch ausreicht einfach einen zweiten dieses Modells anschaffen, den der scheint ja UDP sauber zu unterstützen. Na Teile der Aussagen sind mir doch ein wenig zu hart. UDP "zerstört" nichts, und kein Switch ist verpflichtet QoS zu unterstützen, da es gar nicht in der ursprünglichen Norm drinsteht, sondern irgendwann mal als optionales Feature nachdefiniert wurde. TCP/IP ist vom Design her ein "best Effort" Netzwerk, es bemüht sich also, Pakete von A nach B zuzustellen, aber es gibt keine Gewähr dafür, dass sie auch ankommen. UDP ist die einfache Version, hier wird einfach gesendet, und gehofft. TCP arbeitet mit zusätzlichen Prüfsummen und Quittungen, bleiben Pakete aus, werden sie erneut angefordert, die auflaufenden Daten werden solange gespeichert, bis das fehlende Paket nachgereicht wurde und dann werden alle in der richtigen Reihenfolge ausgeliefert. Bei UDP gilt eben: weg ist weg! (offensichtlich versucht Griga gerade bei UDP im Prinzip das Puffer/Wiederholungsverhalten von TCP nachzurüsten, löblich, aber ich habe da wenig Hoffnung, denn alle Geräte, die TCP/IP reden wissen: kein Stress bei UDP, einfach wegschmeissen bevor ich ins Grübeln komme. Deshalb wird es kaum zu "in falscher Reihenfolge eintreffend" kommen, sondern 99,9% der UDP Störungen sind eben: PAKET IST WEG!) Verlorengegangene UDP Pakete können natürlich wirklich durch Störungen der Leitungen stammen, meist fallen sie jedoch den Switchen zum Opfer, die sie wegschmeissen, da die Verbindung bereits anderweitig "voll" ist und der Puffer Platz für "wichtige" Pakete braucht. Das war die Idee, sich QoS auszudenken, denn bei Ethernet gibt es kein "wichtig" oder "unwichtig". Mit QoS wurde das nun nachgerüsten, ein bestimmtes Feld im Header des Ethernetpaketes bestimmt die Wichtigkeit. Die legt natürlich der Absender fest, und so kam es, dass nicht lange nach Einführung alles "wichtig" war und der Stau wieder von vorne losging. Deshalb "managed" Switche, da hat der Admin die Möglichkeit festzulegen, was er als wichtig betrachtet und was nicht. Kein Switch ist gezwungen, dieses Feld zu beachten, oder zumindest es unverändert weiterzuleiten. Im Gegenteil, es ist durchaus üblich, dass in größeren LANs die Switche die Werte modifizieren (z.B. "in Haus A sind Pakete von X vorrangig, in Haus B die von Y", X und Y senden beide mit hoher Priorität, die beiden Switche, die die Häuser verbinden senken die Prio des anderen bei der Übertragung ab). Bei Videostreams ging man davon aus, dass sie "unwichtig" sind. Wenn es ab und zu mal flackert, stört das kaum jemanden beim Fernsehgucken (lol, UNS natürlich schon! Aber Geschmäcker sind halt verschieden). Außerdem ist es wichtig, dass der Sender auf keinen Fall von seinen Klienten "geärgert" werden kann. Sein Job ist das aktuelle Programm zu senden und nicht auf die heulenden Klienten Rücksicht zu nehmen. Deshalb wird hier UDP genommen (und auch NUR UDP! auch wenn hier die Leute aus verständlichen Gründen TCP eingebaut haben). Gerade, wenn mehrere Klienten gleichzeitig bedient werden sollen, birgt TCP ganz böse Gefahren, wenn ein Klient aus irgendwelchen Gründen ins Schleudern kommt (z.B einfach ausgeschaltet, oder Verbindung getrennt), dann müht sich der Server mit Wiederholungen solange ab, bis ein Timeout abgelaufen ist. Zwischendurch laufen dann die Puffer voll und das betrifft dann ALLE anderen Klienten... Also besser UDP Ach ja, noch so als Ergänzung: TCP hat natürlich die gleiche Fehlerrate, wie UDP da es ja über dieselben Geräte und Leitungen geht. Durch die Wiederholungen werden die Fehler kaschiert, aber die Verbindung doch deutlich langsamer und es treten "Pump"effekte auf. (und noch besser: IPV6, denn da ist QoS und Multicast usw gleich von vorneherein für alle eingebaut und genormt!) Edited June 3, 2014 by MaM
MaM Posted June 3, 2014 Author Posted June 3, 2014 ..wenn TCP störungsfrei ist, gbt es doch eine einfache ausweichlösung. Les meine andere lange Anwort bzg TCP und UDP. Bei TCP würde es zu Bild/Ton Stottern kommen. Allerdings wäre das bei Aufnahmen egal und in sofern eine gute Lösung. Nur beim Gucken hilft es Dir gar nix und die meisten Geräte verhalten sich normgerecht und bieten nur UDP an.
Derrick Posted June 3, 2014 Posted June 3, 2014 (edited) Blödsinn. Für die geringe streamrate bleibt immer genug übrig und den rest erledigen die puffer. Hättst es ja mal probieren können.. ..übrigens wurde nur durch zufall entdeckt, dass RTSP im DVBViewer bis vor kurzem einen schwerwiegenden mangel hatte, der bisher nur in der Pro 5.3.1 gefixt ist. Der RS genauso wie transedit wartet allerdings darauf noch Edited June 3, 2014 by Griga Versionsnummer von 5.2.1 auf 5.3.1 korrigiert
Griga Posted June 3, 2014 Posted June 3, 2014 der bisher nur in der 5.3.1 gefixt ist. Und im DVBViewer GE 3.5.1. Im RS und in TransEdit ist es auch bereits behoben, weil sie den selben relevanten Code verwenden. Es gibt halt nur noch kein Release, das die Korrektur enthält.
MaM Posted June 3, 2014 Author Posted June 3, 2014 (edited) @Derrick: Hmm, ich glaub, Du brauchst mal wieder ein Bildchen, damit Du verstehst, dass Du mit dem TCP Tip total auf dem Holzweg bist: Jetzt klar ? ok, hier die verbale Lösung: OctoNet bietet gar kein TCP an! Da ist also nix zu testen, sorry! Edited June 3, 2014 by MaM
Derrick Posted June 3, 2014 Posted June 3, 2014 ..naja RS meine ich natürlich. Octosonstwas sucks sowieso und wenn der RS gefixt ist, ist es eh egal..
MaM Posted June 3, 2014 Author Posted June 3, 2014 ..naja RS meine ich natürlich. Octosonstwas sucks sowieso und wenn der RS gefixt ist, ist es eh egal.. Diese wenig produktive Gesinnung ist nun wirklich nicht zielführend. Irgendwie scheinst Du beleidigt, weill hier niemand von Deinem geliebten RS lesen will, oder kommt mir das nur so vor ? Aber lasst mal den neuen RS rüberwachsen, ich sag dann schon, obs was geändert hat.
MaxB Posted June 3, 2014 Posted June 3, 2014 Na Teile der Aussagen sind mir doch ein wenig zu hart. UDP "zerstört" nichts, und kein Switch ist verpflichtet QoS zu unterstützen, da es gar nicht in der ursprünglichen Norm drinsteht, sondern irgendwann mal als optionales Feature nachdefiniert wurde. Tja, so macht halt jeder seine persönlichen Erfahrungen Den von mir erwähnten Tenda GBit-Switch kannst Du perfekt als UDP-Firewall einsetzen, der lässt nicht ein einziges UDP-Paket durch. Falls Du es nicht glauben magst können wir gerne einen Besichtigungstermin vor Ort machen... Der Switch ist unmanaged und kommt irgendwo aus China...
MaM Posted June 3, 2014 Author Posted June 3, 2014 >Den von mir erwähnten Tenda GBit-Switch kannst Du perfekt als UDP-Firewall einsetzen, der lässt nicht ein einziges UDP-Paket durch Hmm, komisch. Son "dummer" Switch arbeitet auf Netzwerk Layer 2, also "Ethernet". Er hat keine Ahnung, was da in dem Ethernetpaket drin ist, kennt also weder TCP noch UDP (Layer 3). Allerdings enthält die Beschreibung und das Bildchen schon mal gleich abschreckende Features bereit: a] "SOHO" = "es kann nur einen geben", dieser Switch ist nicht dafür geeignet mit anderen kombiniert zu werden b] alle Ports hinten nur in Plastik -> keine ordenliche Abschirmung -> vorprogrammierte Probleme auf längeren Leitungen. Damit kannst Du vielleicht ein paar Rechner innerhalb eines Raumes verbinden, aber sobald es etwas mehr zur Sache geht, ist Asche. Wenn man halbwegs billig, aber trotzdem sehr solide, haben will, empfehle ich die Fa. Allnet, das Zeug hat mich noch nie enttäuscht.
MaxB Posted June 3, 2014 Posted June 3, 2014 Es geht nicht um den aktuellen Tenda Switch, sondern um einen Switch aus 2006/2007... Ich bin definitiv nicht der einzige, der mit dem Ding UDP-Probleme hat(te)... Aber egal, ich habe hier, wie Du bei meinen bisherigen Tests ja auch erkennen konntest ein absolut stabiles Netzwerk laufen, ich würde sogar behaupten für ein paar Stunden stabiler als Dein Netzwerk Bei Switchen setze ich auf DLink und 3com, habe sowohl managed als auch unmanaged im Einsatz, aber genug der Besserwisserei, ich halte mich jetzt mal wieder ein wenig zurück.
blasgl Posted June 3, 2014 Posted June 3, 2014 @Griga Beim DVBViewer 5.3.1 ist immer noch so. UDP=regelmässige Discontis; TCP=OK. Bei jeder neuen Version mache ich einen Test. @MaM um mal konkret zu werden. Mit damaligen Einkaufspreisen. Switch 1= unmanaged Linksys SE2500 --> 29€ Router/Switch=FritzBox 7320 --> Gratis Switch 2= managed D-Link DIR-826L/E N600 --> 78€ Und es ist 100% sicher, dass der D-Link nicht nur das teuerste, sondern auch das "falsche Glied" in der Kette ist. Ich muss mal schauen, ob QoS wirklich einen Unterschied macht. Und wegen dem Problemchen werde ich keinen Cent ausgeben, wenn es sich mit TCP lösen lässt. Schade nur um die extra 2% CPU-Last
VinoRosso Posted June 3, 2014 Posted June 3, 2014 @Griga Beim DVBViewer 5.3.1 ist immer noch so. UDP=regelmässige Discontis; TCP=OK. Bei jeder neuen Version mache ich einen Test. Hab seit 5.3.1 von TCP auf UDP umgestellt und bisher läuft das einwandfrei im Gegensatz zu vorher, da war UDP nicht benutzbar. Ich mach auch immer nen Test ;-)
blasgl Posted June 3, 2014 Posted June 3, 2014 Ich glaube wirklich, dass mein D-Link switch eine Macke in der UDP-Verarbeitung hat. Manchmal läuft alles einige Minuten lang ohne Probleme, manchmal gibt es nur noch Pixelsalat und die Zahl der Discontis steigt kontinuierlich an. Aber was fast immer der Fall ist: im DVB Source Filter kommen alle 30-40 Sekunden 3 neue Discontis dazu und die dazugehörigen Bildstörungen. Wie Schluckauf halt...
MaM Posted June 3, 2014 Author Posted June 3, 2014 >Und es ist 100% sicher, dass der D-Link nicht nur das teuerste, sondern auch das "falsche Glied" in der Kette ist.>Ich muss mal schauen, ob QoS wirklich einen Unterschied macht. Wie der Name "managed" schon suggeriert, das Teil will erstmal getreten werden. Defaultmässig sind alle Features AUS, deshalb verhält er sich, wie das böseste und dümmste Gerät in meiner Liste. Also, einschalten und gucken... danach meckern.
MaM Posted June 3, 2014 Author Posted June 3, 2014 Aber was fast immer der Fall ist: im DVB Source Filter kommen alle 30-40 Sekunden 3 neue Discontis dazu und die dazugehörigen Bildstörungen. Wie Schluckauf halt... "Schluckauf" ist noch die beste Beschreibung für "Buffer Overflow" finde ich. Der Puffer läuft voll (durch andere Transfers), der Switch bekommt Luftnot und tut, was ihm das Protokoll sagt: "SCHMEISS WECH, DEN DRECK!". Bei TCP wiederholt der Sender irgendwann, UDP Pakete sind und bleiben weg. Das ist also ein total normales Verhalten, das Du beschreibst. Und zwar das Verhalten OHNE QoS und OHNE Flow Control (auch die bitte beim Switch unbedingt einschalten!).
blasgl Posted June 3, 2014 Posted June 3, 2014 Der D-Link macht das, wofür er gekauft würde. Also kann man nicht richtig meckern. Ich muss nur noch schauen, dass ich die QoS richtig konfiguriere. Die D-Link Benutzeroberfläche macht mich krank
blasgl Posted June 3, 2014 Posted June 3, 2014 OHNE Flow Control (auch die bitte beim Switch unbedingt einschalten!). super, wo ist den datt nun? keine Sorge, ich finde das schon.
MaM Posted June 3, 2014 Author Posted June 3, 2014 super, wo ist den datt nun? keine Sorge, ich finde das schon. Such irgendwo in der Nähe der Port Konfiguration, ist meist nur ein Häkchen, will aber erstmal gesetzt werden. (so langsam geht mir hier der Speicherplatz für Anhänge aus...) Bei den Computern findste das in den Eigenschaften der Netzwerkkarte, unter "erweitert". Dort ist es aber normalerweise immer eingeschaltet per Default (und deshalb geht es auch so wunderbar in die Hose, da die Defaults der Geräte zu 100% konträr sind...)
dbraner Posted June 3, 2014 Posted June 3, 2014 @Griga Beim DVBViewer 5.3.1 ist immer noch so. UDP=regelmässige Discontis; TCP=OK. Bei jeder neuen Version mache ich einen Test. @MaM um mal konkret zu werden. Mit damaligen Einkaufspreisen. Switch 1= unmanaged Linksys SE2500 --> 29€ Router/Switch=FritzBox 7320 --> Gratis Switch 2= managed D-Link DIR-826L/E N600 --> 78€ Und es ist 100% sicher, dass der D-Link nicht nur das teuerste, sondern auch das "falsche Glied" in der Kette ist. Ich muss mal schauen, ob QoS wirklich einen Unterschied macht. Und wegen dem Problemchen werde ich keinen Cent ausgeben, wenn es sich mit TCP lösen lässt. Schade nur um die extra 2% CPU-Last Der neue DVBViewer bringt lediglich UDP Pakete in die richtige Reihenfolge, sofern diese von einem Switch oder der Netzwerkkarte oder ... vertauscht wurde. Er kann natürlich keine verlorenen / gedroppten Pakete nochmals anfordern. Dafür gibt es TCP. Dein Problem deutet also darauf hin, dass Pakete bei UDP verloren gehen. Ursache kann sein, dass in Deinem LAN "viel los" ist und daher ein Device oder eine Karte UDP Pakete verwirft. Bleib bei TCP und alles ist gut.
blasgl Posted June 3, 2014 Posted June 3, 2014 (edited) Danke an alle für die Ratschläge. @dbraner Im LAN ist nicht wirklich viel los, normalerweise nur die Übertragung vom RS zum HTPC. Tests mit einer Parallelübertragung, die das Gigabit LAN auslasten ändern nichts an den Discontis, weder zum Positiven noch zum Negativen. Und sobald der UDP Verkehr nicht durchs D-Link Switch muss, ist alles Paletti. Bei TCP bleibe ich Edited June 3, 2014 by blasgl
Derrick Posted June 3, 2014 Posted June 3, 2014 ..sehe ich auch so, obwohl es für SAT->IP wohl keine lösung ist, da (wie das octonet zeigt) nur UDP läuft. Solange server und DVBViewer UDP nicht bevorzugt durchwinken, sollte man also darauf achten, welche netzwerkkomponenten man anschafft.
Griga Posted June 3, 2014 Posted June 3, 2014 Solange server und DVBViewer UDP nicht bevorzugt durchwinken, Ich hatte schon mal in Richtung QoS recherchiert, aber dabei keinen Ansatzpunkt gefunden, mit dem man auf der Ebene tätig werden kann. Doch wie das manchmal so ist - man versucht es eine Weile später erneut, und beim zweiten Anlauf klappt es sofort: http://msdn.microsoft.com/en-us/magazine/cc301862.aspx Ich weiß inzwischen natürlich auch besser, nach welchen Begriffen ich suchen muss. Nächstes Problem: Zeit finden, um den Artikel zu studieren - einmal durchlesen reicht vermutlich nicht.
dbraner Posted June 4, 2014 Posted June 4, 2014 Solange zwischen DVBViewer Client und Recordingservice kein Switch oder Router sitzt, dürfte die QoS Geschichte funktionieren. Das dürfte aber eher die Ausnahme sein. Und dann ist man eben darauf angewiesen, dass die Netzkomponenten priorisierten Verkehr korrekt behandeln. Das würde ich bei billigen (nicht managebaren Switchen) erst mal anzweifeln, zumal man bei den einfachen Geräten keinerlei Möglichkeit hat einzugreifen oder Fehler zu analysieren. Schaden sollte es aber nicht das zu implementieren.
MaM Posted June 4, 2014 Author Posted June 4, 2014 Das dürfte aber eher die Ausnahme sein. Und dann ist man eben darauf angewiesen, dass die Netzkomponenten priorisierten Verkehr korrekt behandeln. Das würde ich bei billigen (nicht managebaren Switchen) erst mal anzweifeln, zumal man bei den einfachen Geräten keinerlei Möglichkeit hat einzugreifen oder Fehler zu analysieren. Schaden sollte es aber nicht das zu implementieren. >Solange zwischen DVBViewer Client und Recordingservice kein Switch oder Router sitzt, dürfte die QoS Geschichte funktionieren. Lol, das würde bedeuten, dass die beiden "back to back" einfach direkt miteinander verbunden sind. Dann brauchst Du auch kein QoS, da ja niemand "von aussen" stören kann. >Und dann ist man eben darauf angewiesen, dass die Netzkomponenten priorisierten Verkehr korrekt behandeln Jein. Im Idealfalle tuen sie das und optimieren dadurch das gesamte LAN. Es reicht aber auch schon zur Verbesserung, wenn sie die Pakete nur ungehindert und unverändert durchlassen, also rein passiv arbeiten. Die QoS Einstellungen der beiden Endpunkte sorgen dann auch schon für einen positiven Effekt. >Das würde ich bei billigen (nicht managebaren Switchen) erst mal anzweifeln Nö, erstaunlicherweise gibt es recht viele "transparente" in der Gruppe. Allerdings ist es wirklich Glaubens- und Leidenssache, das rauszufinden. Die meisten Hersteller machen dazu keine Angaben, aber einige schon. Also genau lesen und bei Werbeaussagen wie "SOHO" (small Office / home Office) die Finger weglassen, denn bei denen kann man davon ausgehen, dass sie eigentlich NIX unterstützen, noch nichtmals den korrekten Strom und Spannungspegel der LAN Schnittstelle. Wer da Kabel dran hängt, die länger als 10m sind, sollte fest mit seinem Gott verbunden sein und blindes Vertrauen haben. >zumal man bei den einfachen Geräten keinerlei Möglichkeit hat einzugreifen oder Fehler zu analysieren Auch hier wieder ein klares JEIN! Klar, diese Brotdosen sagen Dir nix, aber Du kannst recht simpel Messungen an Deinem PC vornehmen. Dazu mußt Du allerdings von Deinem Hersteller der Netzwerkkarte einen speziellen Treiber runterladen und installieren, alle Treiber, die Windows so mitbringt, können das nicht. Dann siehst Du dort z.B. die Empfangstatistik, die auch Fehlerzähler enthält (hier Realtek, aber gibts auch von Intel und anderen):
dbraner Posted June 4, 2014 Posted June 4, 2014 Ich habe mit dem Thema ja auch keine schlechten Erfahrungen gemacht. Ich habe weder Ruckeln noch Aussetzer beim Zugriff DVBViewer auf den Server mit dem Recservice. Dazwischen liegen zwei "dumme und billige" GBit Switche, die nicht mal vom gleichen Hersteller sind. Ich verwende allerdings TCP, kein UDP für den DVBViewer/RS und die SAT-Karten sind direkt im Server verbaut. Das läuft auch Stabil, wenn über andere Clients parallel zum Fernsehen große Datenmengen ausgetauscht werden. Übliche Szenarien sind: Aufnahme läuft, gleichzeitig wird per DVBViewer "gefernseht" und gleichzeitig schaufle ich irgendwelche Foto- und Videodateien zwischen Server und PC hin und her. Alles problemlos.
MaM Posted June 4, 2014 Author Posted June 4, 2014 (edited) Ich habe mit dem Thema ja auch keine schlechten Erfahrungen gemacht. Ich habe weder Ruckeln noch Aussetzer beim Zugriff DVBViewer Na ja, Dein Aufbau hat ja gar nix mit meinem, und dem daraus entstehenden Problem zu tun. Was hier viele nicht verstanden haben: Hier hat der DVBServer keine "lokalen" Karten, sondern bezieht seine Daten aus dem LAN. DABEI passieren die Fehler. Ob er die hinterher auch wieder an irgendwelche Klienten im LAN senden kann, ist mir völlig egal, ich will nur, dass die Daten heile in den Server reinkommen. Also, bei mir ist der RS (ausnahmesweise) Klient eines anderen Servers... (jaja, verkehrte Welt...) Aber, ich hab mir überlegt, ich werde auch den "unteren Weg" gehen. die RS Kiste hat noch eine deaktiverte LAN Karte, da verfrachte ich das OctoNet dann eben in die Garage und verbinde es direkt mit dem RS in einem getrennten LAN. Zum Glück hat die Schüssel in der Garage auch noch vier Anschlüsse frei... [Hey Admin: wie kann ich mein "globales Attachmentlimit" beseitigen? zuviele Screenshots und nu mag er mich nicht mehr...] Edited June 4, 2014 by MaM
Derrick Posted June 4, 2014 Posted June 4, 2014 Ein aufbau wie ihn @dbraner beschreibt dürfte noch der normalfall sein. Grosse lokale netze und 24/7 server sind bislang eher die ausnahme. Viele beiträge beschäftigen sich schliesslich mit dem stromverbrauch (schlafen/auwecken). Ausserdem sind aufwendige architeturen grenzwertig, was lizenfragen betrifft Allerdings ändert sich das jetzt anscheinend grundlegend mit der einführung von Sat>IP. Das handbuch der "Octopus Net Series" habe ich mal überflogen. Dort wird QoS zwar erwähnt und ausdrücklich der interne switch empfohlen, aber sonst ist da nicht viel zu finden. Es finden sich natürlich auch bilder vom oem_dvbviewer_client. Wie wir jetzt wissen, ist da aber nix zum thema drin
mague Posted June 4, 2014 Posted June 4, 2014 sondern bezieht seine Daten aus dem LAN. DABEI passieren die Fehler. Ob er die hinterher auch wieder an irgendwelche Klienten im LAN senden kann, ist mir völlig egal, ich will nur, dass die Daten heile in den Server reinkommen. Schonmal versucht zu entkoppeln ? Ein Netzwerkinterface fuer Octo und eines für den Rest der Welt ?!
MaM Posted June 4, 2014 Author Posted June 4, 2014 Schonmal versucht zu entkoppeln ? Ein Netzwerkinterface fuer Octo und eines für den Rest der Welt ?! Na ja, wenn Du meinen Ausführungen oben gelauscht hättest.... da sind VIER Gb Karten drin, drei gebündelt, eine einsam für den Admin. Das Bündel könnte ich zwar aufschnüren und eine Karte davon extra für Octofant abstellen, aber das würde nun auch nicht viel helfen, da im Moment der RS in der Garage und der OctoSchlagmichtot unterm Dach juchee sind, und das auch noch in verschiedenen Häusern. Zwangsläufig würden die Daten also weiterhin über gemeinsame Kabel laufen (aber auch die Verbindungen HausZuHaus sind mindestens 2*1Gb gebündelt...) Aber ich werde die Teile bald so verbinden, da ist noch ne unbenutzte Schüssel auf der Garage, da könnte man Octifant anschließen und dann direkt in eine abgestellte Karte des RS hinein (klingt gut, ist aber wieder mit viel Aufwand verbunden, weil der Octipode seeeehr normgerecht gestrickt ist, er besteht darauf, seine IP Config von einem DHCP Server zu bekommen, ich muß also dann extra noch einen für diesen Strang aufsetzen...) Aber seit die QoS Richtlinie drin ist, waren bei über 60 Aufnahmen nur einmal 3 Disconiuties drin. Und irgendwie glaube ich, die haben andere Ursachen, es gibt schon ewige Zeiten lang Stress mit Aufnahmen von ZDF HD, und der DD 5.1 Spur von Spielfilmen. Selbst bei Wiederholungen der Filme am nächsten Tag sind diese "Fehler" wieder an gleicher Stelle vorhanden, da vermute ich eher den Sender als Ursache. Also, so, wie es im Moment ist, kann es bleiben. Allerdings darf man dem Server, auf dem der RS läuft, nicht extra "quälen", sonst kommt er wirklich aus dem Tritt. Was sonst so im LAN abgeht stört ihn aber nicht mehr, das ist gut so :-)
Recommended Posts