Artefakte bei rtsp>UDP

[Griga]

Also hier funktioniert RTSP UDP über ein etwas schwachbrüstiges 54 MBit WLAN recht gut - und ich habe das über drei Monate bei der Integration von SAT>IP in TransEdit und den DVBViewer GE ausgiebig gestestet. Auch unter erheblicher Netzwerk-Last, d.h. bei Übertragung von zwei HD-Sendern, auch bidirektional (d.h. zwei PCs simultan als Server und Client), und gleichzeitigem Kopieren von Videodateien über das Netz.

 

Der Betrieb mit dem RS ist allerdings nicht ganz frei von Paketverlusten. Etwa eine Diskontinuität pro Stunde, die unabhängig von der Datenrate auftritt (und sich mit TCP vermeiden lässt). Passiert also ebenso bei einem 64 kbps Radiosender wie bei 24 MBit/s Streaming. Für die reine Wiedergabe praktisch ohne Belang. Für Aufnahmen wäre es ärgerlich, aber die soll ja ohnehin der RS auf dem Server ausführen.

 

Zu ergänzen wäre noch, dass ich von Netzwerktechnik kaum Ahnung habe - abgesehen von dem, was ich bei der SAT>IP-Implementation unter Lars' Anleitung gelernt habe. Demgemäß läuft der Betrieb hier nicht mit hochklassiger Spezial-Hardware, sondern mit 0815-Komponenten, also Billig-USB-TP-Link-WLAN-Adapter, ein etwas altertümlicher Telekom-Router, Onboard-LAN und so. Vielleicht ist es mitunter durchaus von Vorteil, nicht so gut mit Hardware und Wissen ausgestattet zu sein

 

Dass die UDP-Implementation im RS globalgalaktisch kaputt ist, stimmt also einfach nicht. Sowas wird ja auch nicht ungetestet veröffentlicht Dass es unter bestimmten (unbekannten) Bedingungen Probleme geben kann, ist jedoch durchaus denkbar. Wenn sich jetzt die versierten Spezialisten bemühen würden, diese Bedingungen zu ermitteln, anstatt der Versuchung grob vereinfachender Diagnose-Denkschemata zu erliegen, könnte eventuell ein Fortschritt daraus resultieren...

[omnium]

von 'globalgalaktisch' ist nicht die Rede...erst ab Datenraten >11Mbit/sec und das seit der ersten RTSP/UDP-Implementierung.

 

Mit dem Netstream Plugin funktionieren selbst >20 Mbit/sec fehlerfrei über UDP multicast.

 

Ich schliesse einen Fehler in meinem Netzwerk inzwischen 100%ig aus.

 

--

Edited August 1, 2013 by omnium

[Griga]

Ich schliesse einen Fehler in meinem Netzwerk inzwischen 100%ig aus.

 

Die Frage nach dem Verursacher (im Sinne von: wer ist schuld) hilft oft nicht weiter, wie mich die Entwicklerpraxis gelehrt hat. In einem Windows PC und noch mehr in einem Netzwerk treffen so viele sich gegenseitig beeinflussende Faktoren multidimensional aufeinander, dass sich ein eindeutig Schuldiger oft nicht ermitteln lässt. Wenn man darauf besteht, dass es ihn geben muss, läuft man in solchen Fällen in eine Sackgasse bzw. Denkfalle, die nicht weiterführt.

 

Die Suche nach dem Schuldigen ist ein dem Menschen innewohnender Drang, um die Kompliziertheit des Daseins auf einen einfachen Nenner zu reduzieren, wie die Psychologie weiß. Und warum du nichts auf dein heimisches Netzwerk kommen lässt, kann sie auch erklären. Doch das führt nicht zu wirklichen Lösungen.

 

Man muss eher vorurteilslos fragen: Welche Folgen resultieren aus der Kombination welcher Bedingungen? Warum funktioniert es, wenn die Bedingungen XY aufeinandertreffen, aber nicht mit YZ? Warum funktionieren mit meiner veralteten Ausrüstung 24 MBit/s UDP, aber mit deiner vermutlich besseren Hardware nicht?

 

Letztlich habe ich mit einem Programmierer von Digital Devices per Mail über die Problematik von UDP-Paketverlusten diskutiert - die Firma bastelt zur Zeit an einem SAT>IP Server. Ich konnte nicht viel dazu beitragen, außer dem Hinweis, dass diese Problematik vom RS bekannt ist. Das Resultat war, dass man sich bei Digital Devices um QoS Gedanken gemacht hat - Quality of Service, Paketplanung - und damit eine Verbesserung bei hoher Netzwerklast herbeiführen konnte. Ganz folgen konnte ich dem nicht. Ich weiß nur, dass es sowas auch irgendwo in den Eigenschaften einer Netzwerkverbindung unter Windows gibt. Bei mir ist da jedenfalls ein Haken. Wer sich besser damit auskennt, möge diesen Gedanken aufgreifen und weiterführen...

[omnium]

Die Frage nach dem Verursacher...

 

..aber mit deiner vermutlich besseren Hardware nicht?

sorry, I know how to f*** und glaube eher, daß Du in einer 'Denkfalle' steckst.

Ich konnte nicht viel dazu beitragen, außer dem Hinweis, dass diese Problematik vom RS bekannt ist

aha, Digital Devices wird kaum einen SAT>IP Server mit dem RS/Windows aufbauen und die 'Problematik' wahrscheinlich nicht bemerken wenn sie nicht mehr als 60 Mbit/sec mit UDP/IP streamen bzw. Gigabit nutzen.

.

sorry, ich habe keine Lust mehr hier für den Bug/fehlerfreies Netzwerk zu argumentieren.

 

--

Edited August 1, 2013 by omnium

[Tjod]

Ich hatte schon einiges zusammen geschrieben was man Teste könnte.

 

Aber hier scheint kein Interessent am finden einer Lösung zu bestehen sondern nur daran einen schuldigen zu finden.

 

Ich klinke mich hier endgültig aus.

 

Nur eins noch, der von mir vorgeschlagene Test mit iperf gibt nur einen Hinweis auf die Maximale Datenrate mit UDP.

Der Client schickt die Daten mit den eingestellten Datenrate z.B. 100 MBit raus und man sieht dan wie viel ankommt. Die Differenz sind Datenverluste.

 

Wenn bräuchte man einen Aufbau wo der Generator die Pakete zählt die er herausschickt und der Empfänger zählt was ankommt. Und dann guckt man bei welcher Datenrate die Differenz auf eine lange Zeit gesehen 0 ist.

 

Wie die Pakete vom RS aussehen kann man sich ja leicht mit Wireshark angucken. Und das dann als vorlege für den Paketgenerator nehmen.

[Griga]

Der Client schickt die Daten mit den eingestellten Datenrate z.B. 100 MBit raus und man sieht dan wie viel ankommt. Die Differenz sind Datenverluste.

 

Zu dem Zweck habe ich mit dem TransEdit Analyzer auf dem Client einen ganzen Transponder vom RS angefordert - mit dem DVBViewer geht das nicht, aber in TransEdit ist die Option "Open whole transponder" für virtuelle RTSP-Geräte zugänglich. Mein WLAN schafft natürlich keinen 40 MBit-Transponder. Bei UDP kamen etwa 27 MBit/s an (also die halbe Brutto-WLAN-Datenrate). Mit TCP waren es 2 MBit/s weniger. Missing Packets gab es mit TCP erst nach einiger Verzögerung, aber dann wesentlich dramatischer als bei UDP.

 

Aber hier scheint kein Interessent am finden einer Lösung zu bestehen sondern nur daran einen schuldigen zu finden.

 

User, die darauf eingerastet sind, kommen erfahrungsgemäß nicht mehr davon los (Denkfalle, siehe oben). Früher oder später wird sich jemand finden, der das Problem reproduzieren kann, ausreichend Ahnung & Erfahrung hat und sich der Sache mit detektivischem Interesse zuwendet.

[omnium]

Ich hatte schon einiges zusammen geschrieben was man Teste könnte. Aber hier scheint kein Interessent am finden einer Lösung zu bestehen sondern nur daran einen schuldigen zu finden...

..imo nicht Deine erste Fehlinterpretation und ich klinke mich hier auch aus und 'warte' auf die wunderbare Selbstheilung mit einem kommenden/eigenständigen? RS.

 

Bei UDP kamen etwa 27 MBit/s an

aha..http://www.DVBViewer.tv/forum/topic/52888-artefakte-bei-rtspudp/?p=391483

4: die UDP Packet size ist laut Wireshark beim RS zZt. 1370 Bytes. Damit ist die LAN UDP-Bandbreite laut iperf auf ca. 28 Mbit/sec begrenzt, der RS schafft nur ~11 Mbit/sec mit UDP.

..also etwa gleiches Ergebnis mit unterschiedlichen Schlussfolgerungen. Bitte schliesse von den Messergebnissen mit dem TransEdit Analyzer nicht auf den RS/überprüfe Deine Schlussfolgerungen noch einmal/mach noch einmal einen realen Test (vielleicht auf Arte HD) mit dem RS>>LAN>>RTSP UDP/IP DVBViewer Client und beobachte den Zusammenhang zwischen Artefakten und einer Datenrate ab ca. 11 Mbit/sec.

.

 

fehlerlos mit parallel laufendem 1x UDP Multicast + 2x upnp + 1x DVBViewer rtsp TCP/IP Client...alle über Lan vom RS/DVBViewer...oder noch extremer beim zweiten Bild...alles fehlerlos, ruckelfrei und ohne Artefakte...mein Netz ist in Ordnung!

.

Tschüss...womit Eure Welt wieder in Ordnung sein dürfte.

 

--

Edited August 2, 2013 by omnium

[Griga]

die UDP Packet size ist laut Wireshark beim RS zZt. 1370 Bytes. Damit ist die LAN UDP-Bandbreite laut iperf auf ca. 28 Mbit/sec begrenzt, der RS schafft nur ~11 Mbit/sec mit UDP.

 

Und wieso schafft es der RS dann hier, einen kompletten 49 MBit Transponder (Astra 11914 H) ohne UDP-Paketverluste von PC 2 nach PC 3 zu übertragen? Die beiden PCs sind via LAN-Kabel mit besagtem ehrwürdigen Telekom-Router verbunden, d.h. es ist kein WLAN im Spiel.

 

Erst bei 57,5 MBit/s (Astra 12168 V) zeigt der TransEdit Analyzer als RTSP UDP Client fehlende Pakete an. Es kommen effektiv nur 51 MBit/s beim Client an.

 

Der Drang, die eigenen Erfahrungen zu verallgemeinern, scheint unwiderstehlich zu sein...

[CiNcH]

Ich hatte auch UDP-Probleme. Ich hänge mal ein paar Quotes von mir an:

SAT>IP Server > Cisco Gbit Switch > Fritz!Box > Client

SAT>IP Server und Cisco Switch verständigten sich über 1000BASE, Cisco Switch und Fritz!Box über 100BASE. Der Stream war komplett unbrauchbar. Als ich dann die Verbindung zwischen SAT>IP Server und Cisco Switch auf 100BASE zwang, sah das Ergebnis schon deutlich besser aus, aber noch nicht 100% perfekt. Des Rätsels Lösung war dann die Aktivierung von Layer 2 Flow Control im Cisco Switch. Dann lief auch mit 1000BASE alles sauber.

Da sind wohl irgendwelche Puffer vollgelaufen, woraufhin es zu Datenverlust gekommen ist...

Ich konnte mittels iperf ein Problem identifizieren:

Server-PC:

Client-Notebook:

iperf.exe -c 10.0.0.18 -u -b 50M

------------------------------------------------------------
Client connecting to 10.0.0.18, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.55 port 54334 connected with 10.0.0.18 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 58.5 MBytes 49.0 Mbits/sec
[ 3] Sent 41703 datagrams

[ 3] Server Report:
[ 3] 0.0-10.0 sec 58.5 MBytes 49.0 Mbits/sec 1.307 ms 0/41702 (0%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

---

Die andere Richtung macht mehr Probleme...

Client-Notebook:

iperf.exe -s -u

Server-PC:

iperf.exe -c 10.0.0.55 -u -b 50M

------------------------------------------------------------

Client connecting to 10.0.0.55, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.0.18 port 53177 connected with 10.0.0.55 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 59.6 MBytes 50.0 Mbits/sec
[ 3] Sent 42548 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 59.6 MBytes 50.0 Mbits/sec 0.337 ms 48/42547 (0.11%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

Bei 10mbps:

iperf.exe -c 10.0.0.55 -u -b 10M

------------------------------------------------------------

Client connecting to 10.0.0.55, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.18 port 53179 connected with 10.0.0.55 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.9 MBytes 10.0 Mbits/sec
[ 3] Sent 8505 datagrams

[ 3] Server Report:
[ 3] 0.0-10.0 sec 11.9 MBytes 10.0 Mbits/sec 0.151 ms 0/ 8504 (0%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

Bei 10mbps ist es aber scheinbar wieder sauber. Müsste ich mal über einen längeren Zeitraum hinweg anschauen. Welche Richtung ist die relevante? Entgegen der Logik wohl die zweite!? Da empfängt laut Log der Server die Daten...

Man sollte mal beide Richtungen mittels iperf ausmessen.

[omnium]

Und wieso schafft es der RS dann hier, einen kompletten 49 MBit Transponder (Astra 11914 H) ohne UDP-Paketverluste von PC 2 nach PC 3 zu übertragen?

das ist ja die Frage..

 

über TCP/IP

 

über UDP/IP

 

Warum ist die Analyse unterschiedlich (abgesehen von den Paketverlusten)...wieso zB. keine 'NIT PID' über UDP?

 

@CiNcH

danke für die iperf logs...so sieht das mir auch aus..etwa die gleichen Werte/packet loss bei den Einstellungen.

[nuts]

@CiNcH

danke für die iperf logs...so sieht das mir auch aus..etwa die gleichen Werte/packet loss bei den Einstellungen.

Also liegts doch am Netzwerk ...

[omnium]

Also liegts doch am Netzwerk ...

und wieso ändert ein Crosskabel/andere Rechner nix?

 

--

Edited August 2, 2013 by omnium

[Griga]

wieso zB. keine 'NIT PID' über UDP?

 

Pakete mit PID 16 kommen ja an, wie die PID-Liste zeigt. Aber der Stream hat solche Lücken, dass es für eine Auswertung nicht reicht. Eine NIT Section besteht i.a. aus mehreren TS-Paketen, und wenn nur eins davon fehlt, kann man die Section nicht mehr lesen.

 

Bei mir sieht es mit UDP wie bei dir mit TCP aus. Und zwar über einen längeren Zeitraum. 45 Minuten habe ich es laufen lassen, keine fehlenden Pakete - jedenfalls nicht, solange ich den Server in Ruhe lasse. Den PC habe ich geschenkt bekommen - ein alter Vista-Ready von der Stange, für dessen Komponenten keine aktuellen Treiber erhältlich sind. Das Onboard-LAN läuft mit irgendeinem Legacy-Treiber, den Windows 7 für passend hielt, und die Sache geht bei höherer CPU-Last gerne mal etwas in die Knie D.h. ich darf bei dem 49 MBit/s UDP-Transfer nicht gleichzeitig auf dem Server HDTV wiedergeben.

 

Aber wie auch immer - UDP sieht bei dir wirklich dramatisch schlecht aus. Ungefähr so, wie wenn ich versuche, den ganzen Transponder über WLAN zu streamen. Und TransEdit bestätigt, dass bei dir mit UDP nicht mehr als 13 MBit/s drin sind. Ich wüsste gerne, was einen derartigen Unterschied zu meinen Ergebnissen bewirken kann. Wenn sich herausstellt, dass man im RS etwas dagegen tun kann, wird es natürlich gemacht werden. Aber davor steht die Frage: Was ist die Ursache? Was kommt da so ungünstig zusammen?

[CiNcH]

Dein ZyXel unterstützt auch dieses Flow Control. Ist das im Switch aktiviert?

 

 

Flow Control Allows Fast and Reliable Connections

 

The IEEE 802.3x standard-based flow control allows both the ES-105 and ES-108 to prevent traffic congestion by incoming attached devices to stop transmission. When the switches detect that the buffer of each port is nearly full, attached devices are requested to wait until new data can be accepted. Flow control allows 200 mbps full duplex connections between servers and switches with minimum data transfer loss.

 

 

Das war bei meinem Cisco Switch des Rätsels Lösung...

[omnium]

Dein ZyXel unterstützt auch dieses Flow Control. Ist das im Switch aktiviert?

weiss ich nicht, der ES-108P ist nicht managed. Bei meinem managed Zyxel ES-2008-SC30 war/ist es aktiviert.

 

--

[nuts]

Diese Einstellung gibt es imho auch bei den meisten Netzwerkadaptern.

Dort mal reingesehen? Aktiviert? Deaktiviert?

[omnium]

...ich dreh mich nicht mehr im Kreis und bin mit meinem Latein am Ende. Einstellungen/Hard&Software habe ich schon mehrfach überprüft/ausgetauscht...das ist alles in Ordnung. Und nochmal: je nach UDP packet size schaffe ich ja laut iperf 30-60 Mbit/sec (prinzipiell also in Ordnung oder sollten es mehr sein?) und die Probleme gibt es _nur_ mit dem RS>>LAN>>rtsp UDP Client...und anscheinend nur bei Fizzler/miguel01/Frank Sommer/mir/??? was ich immer noch nicht/kaum akzeptieren kann.

 

@CiNcH

wie ist Deine UDP-Performance jetzt? Übertragungsrate/packet loss? Wieviel müssten bei einem 100 Mbit Lan gehen? Sind die bei mir gemessenen Werte (30-60 Mbit/sec je nach UDP packet size) nicht in Ordnung?

 

<edit>

miguel01/Frank Sommer hinzugefügt.

</edit>

--

Edited August 3, 2013 by omnium

[Griga]

Diese Einstellung gibt es imho auch bei den meisten Netzwerkadaptern.

 

Wenn es an einer solchen Einstellung läge, bliebe immer noch die Frage, warum es mit dem Netstreaming Plugin trotzdem funktioniert. Der RS muss also irgendwie zu dem Problem beitragen, auch wenn er es nicht alleine verursacht. Aber wodurch? In dem Fall erweist sich Lars wirklich als unersetzlich Bis jemand anders den Code analysiert und relevante Unterschiede ermittelt hat, das kann dauern...

[nuts]

Na zumindest bei @cinch war es des Rätzels Lösung, aber das hilft jetzt ja auch nicht weiter.

Mit "Fließkontrolle" am Server/Client aktivieren/deaktivieren konnte ich das Problem bei mir auch nicht provozieren.

 

Vielleicht reagiert der RS auf einen selbst ermittelten, angeblichen (?) Engpass und versucht möglichst intelligent Pakete wegzulassen? Oder gibt sowas das Sat>IP Protokoll sogar vor?

Ich weiss es nicht und habe auch keine Idee wie man das Problem systematisch eingrenzen könnte.

Lars fehlt bei solchen Themen einfach unglaublich ...

 

An dem Punkt war ich mit @omnium per PM schon vor einer Woche und was mich dann ärgert sind solche Aussagen:

Sorry, aber das _glaube_ ich Euch nicht mehr, egal was Ihr hier beteuert/berichtet.

Ich finde das respektlos gegenüber den Entwicklern und den Testern.

Das wäre doch nie mit solchen Problemen veröffentlicht worden ...

[omnium]

Ich finde das respektlos..

..und Du machst wieder Stimmung und stellst abenteuerliche Theorien auf.

 

zum Abschluss noch ein Screenshot..

 

 

..4xUDP plus 2xTCP über Lan bei hohen Datenraten..fehlerlos!

 

Tschüss!

 

--

Edited August 2, 2013 by omnium

[Frank Sommer]

Das ist meine Statistik von soeben (Arte HD):

Wo stellt man eigentlich im aktuellen DVBViewer von UDP auf TCP um?

Die Discontinuities erscheinen bei mir als Bitfehler bzw. Blockfehler aber nicht so dramatisch wie im 2. Post.

 

[omnium]

..und das üble an dem Fehlerbild: fast jeder Supporter/Ahnungsträger hier im Forum, schickt Dich deshalb aufs Dach/empfiehlt Dir eine Cine/???...SCNR.

 

--

[Frank Sommer]

Ich habe noch weitere Tests durchgeführt: Unicast>RS Service via LAN, Ergebnis: nach 30 Minuten Null Aussetzer.

Gestern Abend waren es via UDP>RS 140 Fehler innert 30 Minuen, oder so, wobei bei einem früheren Test die ersten Fehler erst nach 5 Minuten auftraten (via WLAN). Ganz allgemein hatte ich den Eindruck, daß die Fehler bei mir in kurzen Blöcken auftreten und dann für mehrere Minuten wieder keine. Mir ist das bisher gar nicht aufgefallen, wohl deshalb weil die Fehler sich bei mir im DVBViewer nur in minimalen Aussetzern bemerkbar machen. Ich dachte aber, daß ich "früher" bei UDP>RS auch Null Fehler hatte.

Wenn sich also noch mehr Leute finden würden, die mal quantitative Werte beisteuern und nicht nur schreiben: "viele Aussetzer" könnte man mal anfangen das Problem einzugrenzen - an einem Fehler an meiner Verkabelung glaube ich nämlich auch nicht.

 

Falls ich weitere Tests durchführen soll, bitte ich um Nachricht.Obwohl mich die Attitüde der Administratoren und Entwickler hier schon vor langer Zeit dazu bewogen hat, hier nur sporadisch reinzuschauen.

Edited August 3, 2013 by Frank Sommer

[Derrick]

Drahtlos oder drahtgebunden?

WLAN ist fuer solche tests mit HD ungeeignet.

[Frank Sommer]

Drahtlos oder drahtgebunden?

WLAN ist fuer solche tests mit HD ungeeignet.

Wir wissen wie man reproduzierbar testet. Steht oben drin. Die relevanten (hier dokumentierten) Tests sind via Kabel.

 

Edit: Mein obiger Test von 00:07 war auch via LAN (kein WLAN dazwischen!)

Edited August 3, 2013 by Frank Sommer

[Derrick]

...naja, zu beginn schriebst du 802.a also erscheint mir die frage logisch. Support.zips scheinen auch out zu sein.

[Frank Sommer]

...naja, zu beginn schriebst du 802.a also erscheint mir die frage logisch. Support.zips scheinen auch out zu sein.

Ich fange erst an Logdateien zu sammeln wenn ich sehe daß sich genügend Leute einbringen. Bisher ist das eher auf dem Level von Brainstorming.

Edited August 3, 2013 by Frank Sommer

[omnium]

relevant, ist der Zusammenhang zwischen Artefakten/Diskontinuties/Buffer overflow ab dem übeschreiten einer max Bitrate (bei mir 11Mbit/sec)...im Log findest Du/Ihr dazu nix. Beobachtet die Bitrate und das Auftreten von Artefakten/Störungen...der Zusammenhang ist nicht zu übersehen.

 

--

Edited August 3, 2013 by omnium

[Derrick]

..bevor du damit amfaengst, sollten standardkonfigurationen definiert werden, was die netzwerktopologie betrifft. Insbesomdere router und switches sollten zunaechst aus demu lan entfernt werden. Ein unterschied zwischen RS und plugin ist naemlich, dass der RS bidirektional arbeitet. Dem plugin ist flow control unbekannt

[omnium]

Insbesomdere router und switches sollten zunaechst aus demu lan entfernt werden..

sorry, was für ein Quatsch/idiotische und _praxisfremde_ Hürde. Wenn sich herausstellt, daß das (rtsp UDP Client) nur mit profi Switches/Spezialeinstellungen fehlerfrei funktioniert, taugt der Standard/RS nix.

 

--

[Derrick]

IMHO fuer die ursachenforschung unerlaesslich. Fehler gezaehlt hast du doch bereits genug..

[omnium]

aha...und wer keinen Bock hat, auf diese erhebliche und _praxisfremde_ Test-Hürde, muss darauf gefasst sein, von Dir/Euch/Supportern die Message zu bekommen, daß sein Switch/Konfiguration/Netzwerk nix taugt/suboptimal ist/Äpfel mit Birnen vergleicht/keine Ahnung hat/respektlos ist/in einer Denkfalle steckt/????

 

Es nützt hier im Forum bisher auch nix diese 'neue' Test-Hürde (die ich mir zur 'Ursachenforschung' _selbst_ auferlegt habe _bevor_ ich hier gepostet habe...'I know how to f***') zu überwinden und mehrfach zu berichteten daß es auch mit einem Crosskabel auftritt...das wird von Dir/Euch/Supportern/Ahnungsträger/Spin Doctors/???? ignoriert und es gilt (zumindest gefühlt) das Dogma: Der RS/DVBViewer ist fehlerlos!

 

--

Edited August 3, 2013 by omnium

[Griga]

Noch mal dazu:

Ich habe mich an das Netstream Plugin erinnert und einen weiteren Versuch gestartet.

..und wie ihr sehen könnt gibt es damit _keine_ Probleme trotz UDP und hoher Datenrate!

 

Betreibst du es mit der Einstellung Multicast und Buffercount = 7?

 

Wie gross ist die UDP Packet Size beim RS?

 

Meine SAT>IP-Clients erwarten 1356 Bytes = 7 TS-Pakete x 188 Bytes + 40 Bytes Header. Der Wert entspricht der genannten Einstellung im Netstreaming Plugin (deshalb meine Frage) und wurde bewusst gewählt, um IP-Fragmentierung zu vermeiden. Siehe dazu auch hier. Gibt es in der Hinsicht bei dir Besonderheiten oder eine spezielle Konfiguration? Irgendeine Internet/Netzwerk-Optimierung? Jumbo Frames? Stichwort MTU. Angenommen, es würden statt der Standard 1500-Byte-Ethernet-Pakete viel größere versendet, dann wäre die RS-Paketgröße fehlangepasst, was tatsächlich die maximale Datenrate drastisch beschränken könnte.

 

Außerdem habe ich recherchiert, was man tun müsste, um eine Begrenzung der UDP-Datenrate, so wie sie sich in diesem Fall zeigt, künstlich herbeizuführen. Gar nicht so einfach Windows bietet jedoch eine Möglichkeit: Richtlinienbasiertes QoS. Damit kann man festlegen, dass Anwendung X mit Protokoll Y maximal Datenrate Z verwenden darf. Allerdings braucht man dazu einen Richtlinieneditor, den z.B. die Windows Server-Varianten mitbringen, oder man muss in der Registry herummurksen. Kaum anzunehmen, dass dort die Ursache liegt.

[omnium]

Betreibst du es mit der Einstellung Multicast und Buffercount = 7?

ja

 

--

[Griga]

Das ist die Vorgabe in den Einstellungen. Aber ob sie auch standardmäßig so verwendet werden? Laut dem von mir verlinkten Thema arbeitete das Plugin zuvor mit wesentlich größeren Paketen, die womöglich aus Kompatibilitätsgründen beibehalten werden, solange man nicht eingreift.

 

Bestätige bitte zur Sicherheit die Plugin-Einstellungen mit OK, falls noch nicht geschehen, starte dann den DVBViewer neu, und schaue, ob sich was ändert.

[omnium]

Bestätige bitte zur Sicherheit die Plugin-Einstellungen..

das ist bei mir so eingestellt (7) und auch mit 'ok' bestätigt...andere Werte (1/20) haben/hatten bei mir keinen Einfluss..das Teil funktioniert einfach.

 

Zur Erinnerung..

4: die UDP Packet size ist laut Wireshark beim RS zZt. 1370 Bytes. Damit ist die LAN UDP-Bandbreite laut iperf auf ca. 28 Mbit/sec begrenzt, der RS schafft nur ~11 Mbit/sec mit UDP.

..bei mir wären 60 Mbit/sec möglich bei einer günstigeren UDP packet size.

--

Edited August 3, 2013 by omnium

[Griga]

Damit ist die LAN UDP-Bandbreite laut iperf auf ca. 28 Mbit/sec begrenzt,.

bei mir wären 60 Mbit/sec möglich bei einer günstigeren UDP packet size.

 

Die Paketgröße ist im Hinblick auf IP-Fragmentierung unter normalen Bedingungen optimal. Was bei größeren Paketen passieren kann, geht aus dem von mir verlinkten Thema hervor. Eine Begrenzung auf 28 MBit/s kann ich nicht bestätigen, da bei mir via LAN mit UDP wie gesagt 49 MBit/s fehlerfrei transportiert werden.

 

Welche DVB-Hardware verwendet der RS, und welche steht insgesamt zur Verfügung? Solche Rückfragen erspart übrigens eine support.zip...

[omnium]

Welche DVB-Hardware verwendet der RS, und welche steht insgesamt zur Verfügung? Solche Rückfragen erspart übrigens eine support.zip...

..sorry, ich drehe mich nicht mehr im Kreis und habe keinen Bock auf Hardwarestriptease wenn es nicht relevant ist. Was soll die DVB-Hardware damit zu tun haben?

.

Kannst Du Dich noch an diese http://www.DVBViewer.tv/forum/topic/51391-DVBViewer-50-unicast-discontinuities/ Diskussion erinnern? Lies sie bitte noch mal durch...bis zum Schluss...vielleicht geht Dir ja dann ein Licht auf in Bezug zum RS...ich kann nichts mehr dazu beitragen und werde keine Theorien mehr aufstellen/mir eine Cine/Black Gold/??? oder/und einen Wundeswitch kaufen/weitere Experimente machen/????.

 

--

Edited August 3, 2013 by omnium

[CiNcH]

 

..sorry, ich drehe mich nicht mehr im Kreis und habe keinen Bock auf Hardwarestriptease wenn es nicht relevant ist. Was soll die DVB-Hardware damit zu tun haben?

 

Wenn ich mich recht an eine Diskussion mit Lars erinnere, schickt der RS die Daten so ins Netz, wie sie vom Treiber der DVB-Hardware kommen. Sprich, wenn der Treiber mehr puffert, wird auch der RS die Daten burstartiger verschicken. Ich hatte ihn dazumal schon gefragt, ob es nicht Sinn macht, die Datenpakete mehr über die Zeit hinweg zu verteilen. Da ich mein Problem mit dem Switch aber gelöst hatte, habe ich auch nicht weiter nachgebohrt. Inwiefern das NetStream da anders arbeitet, weiß ich nicht. Evlt. einen Kondensator durch die Plugin-Schnittstelle? Oder der Switch behandelt Multicast einfach nur anders!? Soweit ich weiß ist letzteres auch sehr typisch. Leider bin ich aber auch kein Netzwerkspezialist.

 

Du bewegst dich hier echt auf einem sehr niedrigen Niveau. Muss das wirklich sein?

[test]

@omnium: Du hast jetzt gefühlt zum 38ten mal gesagt, dass Du keinen Bock mehr auf Tests hast. Meinst nicht, dass jetzt mal gut ist?

Wir wissen es, Du testest nix mehr und gut.

 

Und was soll in Deiner Signatur immer dieses sinnfreie Bild?