Artefakte bei rtsp>UDP

[Derrick]

..verdacht oder unbegruendete theorie..

anscheinend gibt es unterschiedliche anforderungen an die hardware beo den beiden protokollen. Die, die keine probleme haben, verwenden normale PCs. Amders bei den HTPClern mit ihrer schwachbruestigen hardware. TCP/IP ist doch genauso gut

[CiNcH]

Ich habe die problematische Netzwerktopologie nun wieder hergestellt...

 

RS-Server -> 1000BASE -> Cisco SLM2008 -> 100BASE -> Fritz!Box 7270 -> WIFI N 150mbps -> Client Notebook

 

Cisco Port Konfiguration:

 

Kein Flow Control auf dem 1000BASE Port:

 

Flow Control auf dem 1000BASE Port:

[omnium]

..ich sehe da kein Problem 48,67 Mbps gegenüber 49,17 Mbps...???

 

--

Edited August 3, 2013 by omnium

[CiNcH]

Die Missing Spalte zählt hoch. Ich bin da wohl gerade am Limit. Die Datenrate scheint gegenüber früher deutlich besser geworden zu sein. Früher hatte ich auch schon ab 10mbps Probleme. Ich habe nun aber auch einen anderen Netzwerkadapter im RS-Server als früher (vorher Marvell Yukon, jetzt Intel 82579V). Der überflutet scheinbar den Cisco nicht mehr so sehr.

[Griga]

und habe keinen Bock auf Hardwarestriptease wenn es nicht relevant ist.

Schön, dass du das so kompetent beurteilen kannst. Das nimmt einem wirklich Arbeit ab

 

Ich nehme an, Omnium veranstaltet seinen Netzwerk-Zirkus mit einer DVBSky:

 

http://www.DVBViewer.tv/forum/topic/50979-dvbsky-c2800e-pcie-einstellungen/?p=381227

 

Da unsere chinesischen Freunde dazu neigen, ihre Puffer (also den Beginn der Eimerkette) im Interesse kurzer Zapping-Zeiten knapp zu halten, auch wenn dadurch Datenverluste drohen, könnte es einen Zusammenhang geben. Deshalb wäre ein Test mit alternativer DVB-Hardware von Interesse. Ich hatte meinen Versuch mit einer Digital Devices sowie einer FireDTV im Server durchgeführt, die beide nicht für Datenverluste anfällig sind. Ich muss mal Christian fragen, ob er im Code feststellen kann, ob der RS die Daten bei UDP unmittelbar im Streaming-Thread des Tuner Filters ins Netz schickt oder sie vorher auf einen anderen Thread umsetzt. Bei TCP sind vermutlich weitere Puffer und Threads im Spiel, da die Daten ja für eine Weile eine eventuelle Wiederholung bereitgehalten werden müssen.

[omnium]

 

Schön, dass du das so kompetent beurteilen kannst...

nee, aber ich kenne Eure Aversion/Geringschätzung, wenn es um die 'chinesischen Freunde' geht. BTW habe ich zZt. eine Tevii S471...also auch ein 'chinesischer Freund'.

 

Danke für Deine/Eure weitere Forschung. Selbst wenn sich da eine 'Unverträglichkeit' mit den 'chinesischen Freunden' rausstellt, kann ich mir nur schwer vorstellen, daß die 'chinesischen Freunde' einen neuen Treiber rausbringen mit dem der RS dann keine Probleme mehr hat...das sollte/muss IMO von Euch kommen...also ein geänderter/verbesserter/kompatiblerer RS.

 

@CiNcH

du hast doch einen chinesischen Freund (wenn ich mich richtig entsinne) und keine Probleme, oder?

.

Hoffentlich wird diese 'Forschungsrichtung' nicht zur 'Denkfalle'/Holzweg/????...am Ende mit eine Liste von RS kompatibler Hardware (Switches/DVB-Karten)...bitte nicht!

 

--

Edited August 4, 2013 by omnium

[CiNcH]

Im Notfall kann ich auch den Server mit Yukon NIC nochmal aufbauen. Ich gehe davon aus, dass ich dann wieder gröbere Probleme habe. Das ist allerdings mit größerem Aufwand verbunden. Aber wenn wir dadurch weitere Erkenntnisse erlangen, bin ich gerne bereit. Dann könnte ich evtl. auch ein paar FTA Transponder mit dem NetStream verschicken und schauen, wie sich das verhält.

 

Es kommt wohl auf das Zusammenspiel zwischen NIC und Switch an (Pufferung, Burstversand, Flusskontrolle). Inwieweit man da in der User-Space-Applikation generell und nachhaltig was bewirken kann, weiß ich nicht so recht. Da sind noch sehr viele Komponenten zwischen, über die man keine Kontrolle hat.

 

 

nee, aber ich kenne Eure Aversion/Geringschätzung, wenn es um die 'chinesischen Freunde' geht. BTW habe ich zZt. eine Tevii S471...also auch ein 'chinesischer Freund'.

 

Das ist die Erfahrung und das ist leider Fakt. TeVii puffert genau gleich wenig. Ich bemängle das schon seit Jahren. Da fehlt ganz eindeutig das Know-How.

[omnium]

Da fehlt ganz eindeutig das Know-How.

sorry, ich finde das überheblich...IMO kochen die alle nur mit Wasser..auch Cine/????.

 

Ich hoffe nicht daß Du/Ihr jetzt den Schuldigen (chinesische Freunde) ausgemacht habt. Hast Du Deine Experiment nicht mit Deinem 'chinesischen Freund' (DVBSky mit CI, oder?...http://www.DVBViewer.tv/forum/topic/50979-dvbsky-c2800e-pcie-einstellungen/?p=378106) gemacht?

Du könntest durch eine Antwort auf diese Frage, die Spekulationen/Gedankenspiele in diese Richtung beenden.

 

--

Edited August 4, 2013 by omnium

[CiNcH]

sorry, ich finde das überheblich...IMO kochen die alle nur mit Wasser..auch Cine/????.

 

 

Der einzige, der hier überheblich ist und uns allerlei Dinge vorwirft, bist du. Du hast von der Materie null Ahnung. Wir haben hier weit über 10 Jahre Erfahrung. Ich habe so ziemlich jedes DVB-Produkt zuhause liegen und auch Kontakte zu sämtlichen Herstellern. Ich weiß von jedem, wo die Stärken und Schwächen liegen, auch, was Kompetenzen angeht. Es geht hier nicht darum, einheimische Produkte zu bevorzugen. Ich habe sowohl zu TeVii als auch DVBSky sehr nette Kontakte. Es geht hier nicht um zwischenmenschliche Beziehungen. Die bessere Technologie soll siegen. Wenn du mit TeVii zufrieden bist, ist das in Ordnung für mich. Ich bin es nicht. Und ich habe dafür sehr fundierte Argumente, die hier aber fehl am Platz wären.

 

 

Ich hoffe nicht daß Du/Ihr jetzt den Schuldigen (chinesische Freunde) ausgemacht habt. Hast Du Deine Experiment nicht mit Deinem 'chinesischen Freund' (DVBSky mit CI, oder?) gemacht?

 

Die Pufferung ist immer noch nicht i.O. Ich schiebe das schon lange vor mir herum. Muss dieses Thema bei Gelegenheit nochmal aufgreifen. Momentan bin ich aber mit anderen Entwicklungen zugedeckt. Aber ich sehe es auch nicht so als meine Aufgabe, denen sinnvolle Puffergrößen vorzurechnen, die zudem nur im ein- bis zweistelligen Millisekundenbereich Einfluss auf die Umschaltzeiten hätten.

[omnium]

 

Der einzige, der hier überheblich ist und uns allerlei Dinge vorwirft, bist du..

alles klar...ich habe Euch/Dir _nichts_ vorgeworfen! Wenn Du/Ihr eine Diskussion auf Augenhöhe als überheblich empfindet, ist das nicht mein Problem. Deinen/Euren Skill habe ich zu keinem Zeitpunkt in Frage gestellt...stellt meinen bitte auch nicht in Frage.

Aber ich sehe es auch nicht so als meine Aufgabe, denen sinnvolle Puffergrößen vorzurechnen..

schon klar...die aufkommenden Gerüchte/Spekulationen in diese Richtung könntest Du allerdings mit einem Satz beenden. Warum Du diese einfache Frage (womit Du Deine Experimente gemacht hast) nicht beantwortest, wird Dein Geheimniss bleiben.

 

--

Edited August 4, 2013 by omnium

[Griga]

Bislang ist es ja nur ein Verdacht, dass die Pufferung in fernöstlichen Treibern bei dem hier behandelten Problem mitspielt. Ein vergleichender Test wäre wesentlich produktiver als die Inszenierung persönlicher Empfindlichkeiten.

 

Ich habe hier noch eine TBS QBOX im Schrank herumliegen, die dort trotz gutem Tuner wegen notorischer Diskontinuitäten gelandet ist (bei HDTV-Wiedergabe mit höherer CPU-Last ungenießbar). Bei Gelegenheit werde ich mal probieren, was dabei herauskommt, wenn der RS dieses Gerät verwendet...

[omnium]

Ich habe hier noch eine TBS QBOX im Schrank herumliegen, die dort trotz gutem Tuner wegen notorischer Diskontinuitäten gelandet ist (bei HDTV-Wiedergabe mit höherer CPU-Last ungenießbar). Bei Gelegenheit werde ich mal probieren, was dabei herauskommt, wenn der RS dieses Gerät verwendet...

..mit der Tevii S471 gibt es _ausschliesslich_ mit dem RS rtsp UDP Server/Client Diskontinuitäten.

 

--

Edited August 4, 2013 by omnium

[CiNcH]

Ich denke nicht, dass die unterschiedlichen Fabrikate hier eine große Rolle spielen. Der RS bekommt halt vom Treiber eine Menge von TS-Paketen und die lässt er dann mit voller Geschwindigkeit auf die Leitung. Dann macht er Pause bis der nächste Puffer kommt. Ich denke nicht, dass es eine Rolle spielt, ob da nun pro Puffer ein paar Pakete mehr oder weniger kommen. Die größere Rolle dürfte spielen, wie gut NIC und Switch puffern. Ich denke, die Lösung liegt eher darin, die Pakete besser über die Zeit zu verteilen. Ist aber nur ein Bauchgefühl..

[omnium]

'Bauchgefühl' finde ich super...meins sagt mir von Anfang an, daß es _nicht_ am Netzwerk/Netzwerkkomponenten liegen kann und nach den ganzen Tests ist es für mich Gewissheit.

 

--

[CiNcH]

Soweit ich weiß hat Lars auch mit unterschiedlichen Netzwerkbibliotheken gespielt. Ich denke, da kommen im RS und NetStream Plugin ganz unterschiedliche zum Einsatz. Die können natürlich auch nochmal buffern bzw. das tatsächliche Legen der Daten auf die Leitung beeinflussen.

[Griga]

Soweit ich weiß hat Lars auch mit unterschiedlichen Netzwerkbibliotheken gespielt.

 

Die letzte Umstellung gab es vor dem 1.26 Release. Da hat Lars die TCP Library ausgetauscht, weil es mit der vorherigen bei unseren Tests Verbindungsabbrüche gab. Er hat sich dabei etwas Sorgen gemacht, ob das Probleme im Streaming Thread geben könnte, und es mit zahlreichen Clients getestet. War aber nicht der Fall.

 

Mit dem vom Treiber bzw. BDA Graph erzeugten Streaming Thread, der die Daten anliefert, ist nicht zu spaßen. Da darf nichts zu lange dauern, weil alles unter Zeitdruck im Push-Modus arbeitet. Der Treiber schiebt die Daten rein, und wenn sie nicht schnell genug weiterverarbeitet werden, gibt es Verluste. Ein Treiber mit kleinen Datenlieferungen muss besonders schnell einen Abnehmer finden, weil sie in kurzen Abständen kommen und nicht viel aufgefangen werden kann (man stelle sich eine Eimerkette vor, in der jemand einen kleineren Eimer verwendet - er muss schneller arbeiten und schneller einen Abnehmer finden). Deshalb hatte ich überlegt, ob die DVB-Hardware an dem Effekt beteiligt sein könnte.

 

Hinsichtlich UDP hat Lars sich jedoch nie über potentielle Probleme in dem Bereich geäußert. Dazu gab es bei den ganzen Tests keinen Anlass. Ich weiß allerdings auch nicht, unter welchen Bedingungen das Senden der Daten bei UDP im Server erfolgt. Bei nächster Gelegenheit werde ich mich danach erkundigen...

[omnium]

Mit dem vom Treiber bzw. BDA Graph erzeugten Streaming Thread, der die Daten anliefert, ist nicht zu spaßen. Da darf nichts zu lange dauern, weil alles unter Zeitdruck im Push-Modus arbeitet. Der Treiber schiebt die Daten rein, und wenn sie nicht schnell genug weiterverarbeitet werden, gibt es Verluste. Ein Treiber mit kleinen Datenlieferungen muss besonders schnell einen Abnehmer finden, weil sie in kurzen Abständen kommen und nicht viel aufgefangen werden kann..

..das passt zu der Beobachtung daß die Prozess Priorität vom RS zumindest bei mir einen Einfluss auf nicht empfangsbedingte Diskontinuties hat..und das nicht erst seit gestern. In welcher Sprache ist der RS geschrieben und geschieht das Buffer Handling nicht über eine Interrupt Service Routine?

.

Der Server auf dem der RS läuft idelt vor sich hin und ist mit Sicherheit schnell genug.

.

IMO ist die wichtigste Frage, warum das mit dem Netstreaming Plugin problemlos funktioniert bei unveränderten Treibern/Buffern der 'chinesischen Freunde'...das kann also imo nicht der Grund sein.

--

Edited August 4, 2013 by omnium

[Griga]

In welcher Sprache ist der RS geschrieben

 

Delphi

 

und geschieht das Buffer Handling nicht über eine Interrupt Service Routine?

 

Im Treiber ja. Da gibt es i.a. einen Interrupt, wenn ein DMA-Puffer voll ist, der abgeholt werden muss. Im RS nicht.

 

Bei der alten SkyStar2 mit WDM-Treiber ist der DVBViewer nahe am Geschehen dran. Da gibt es zwei DMA Puffer (DMA = Direct Memory Access) die die Hardware im Wechsel füllt. Wenn einer voll ist, gibt es einen Interrupt, und der Treiber kopiert den Inhalt in einen Ringpuffer, auf den der DVBViewer Zugriff hat. Es gibt Datenverluste, wenn der Treiber mit dem Kopieren des einen Puffers noch nicht fertig ist, bevor der zweite voll wird. Und wenn der DVBViewer den Ringpuffer zu langsam ausliest.

 

Bei gängigen BDA-Geräten und Treibern dürfte es ähnlich aussehen, aber mit dem BDA-System befindet sich noch ein Abstraktions-Layer zwischen Treiber und Anwendung, das die Daten in einem DirectShow-Filtergraph durchreicht, wodurch weitere Faktoren ins Spiel kommen.

[Frank Sommer]

Ich denke, die Lösung liegt eher darin, die Pakete besser über die Zeit zu verteilen. Ist aber nur ein Bauchgefühl..

Das kann man versuchen zu simulieren, indem man beim NIC-Treiber das Checksum-Offloading etc. abschaltet, d.h. der NIC Treiber muß die Cheksummen selbst berechnen/prüfen.

[omnium]

Das kann man versuchen zu simulieren, indem man beim NIC-Treiber das Checksum-Offloading etc. abschaltet, d.h. der NIC Treiber muß die Cheksummen selbst berechnen/prüfen.

..und das soll die 'Pakete besser über die Zeit verteilen'? Verstehe ich nicht...hab's aber trotzdem ausprobiert..hat nix gebracht!

 

--

Edited August 7, 2013 by omnium

[CiNcH]

 

Das kann man versuchen zu simulieren, indem man beim NIC-Treiber das Checksum-Offloading etc. abschaltet, d.h. der NIC Treiber muß die Cheksummen selbst berechnen/prüfen.

 

Erstens ist das ein TCP Feature, zweitens versteh ich nicht, was das mit der gleichmäßigen Verteilung von Paketen zu tun haben soll .

[Frank Sommer]

 

Erstens ist das ein TCP Feature, zweitens versteh ich nicht, was das mit der gleichmäßigen Verteilung von Paketen zu tun haben soll .

Die CPU verbleibt ein paar uS länger im Treiber um die Prüfsummen zu berechnen/verifizieren anstatt die Task an die HW auszulagern.

[CiNcH]

 

Die CPU verbleibt ein paar uS länger im Treiber um die Prüfsummen zu berechnen/verifizieren anstatt die Task an die HW auszulagern.

 

Sonst passiert es im Treiber und dauert da wahrscheinlich eher länger... Aber wie gesagt, ist TCP...

[Donald24]

Ich hatte vor Monaten auch mal so ein Problem, herausgestellt hatte sich auch bei mir, dass der Switch zu alt war, und dass ich einen brauchte, der IGMP-snooping bot. Dumme Switche sind schnell mit UDP-Lasten überfordert (und Live-TV ist auch noch sehr latenzempfindlich)

Läßt sich ganz einfach testen, Netzwerkkabel mit Quelle und Server direkt verbinden...

[omnium]

Läßt sich ganz einfach testen, Netzwerkkabel mit Quelle und Server direkt verbinden...

jau..

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

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

..bei mir ändert das aber nix.

 

--

no sig today

[MaxB]

Ich hatte vor Monaten auch mal so ein Problem, herausgestellt hatte sich auch bei mir, dass der Switch zu alt war, und dass ich einen brauchte, der IGMP-snooping bot. Dumme Switche sind schnell mit UDP-Lasten überfordert (und Live-TV ist auch noch sehr latenzempfindlich)

Läßt sich ganz einfach testen, Netzwerkkabel mit Quelle und Server direkt verbinden...

Genau diese Erfahrungen habe ich auch gesammelt! Besonders Switche von "noname" Herstellern machen viele Probleme mit UDP und auch bei der Fritz.Box gab es am Anfang massive Probleme mit UDP-Traffic...

Ein weiteres Thema sind Netzwerkkarten! Seit dem ich auf meinen Servern mit Intel Netzwerkkarten arbeite sind die UDP-Probleme in Richtung 0 gegangen und wenn ein OnBoard-LAN nicht sauber läuft kommt da auch eine vernünftige NW-Karte rein.

Ich schicke hier bis zu 8 komplette QAM256 TS (=> ca. 400 MBps) in meinem Netzwerk hin und her um mit Transedit den UDP-Traffic zu checken. "Missing Pakets" gibt es manchmal beim Starten eines Tuners, danach bleibt es sauber.

[omnium]

Ich schicke hier bis zu 8 komplette QAM256 TS (=> ca. 400 MBps) in meinem Netzwerk hin und her..

..Du hast ein Gbit-LAN..imo nicht vergleichbar mit einem 100Mbit-LAN.

[Donald24]

Dann läuft ja alles daraus hinaus, dass du den Fehler mal in den NICs suchen solltest. ähnlich wie MaxB stehe ich auf Qualität und achte auf onboard verbaute Intel-NICs. Sollte der Fehler bei zwei unabhängigen Clients auftauchen, is ja klar, welche Karte du zuerst tauschen solltest

 

Ich benutze den RS in allen möglichen Konstellationen mit Clients, sogar über WLAN kein Problem! (was eine weitere Hürde in der sauberen Implementation von UDP-Filterung des Routers/Accesspoints bedeutet)

 

// Warum hat man heute noch ein 100Mb-Netzwerk? Wenn, wie du sagst, du Quellserver und Client direkt verbunden hattest, müsstest du allerdings ne Gb-Verbindung gehabt haben, wenn Du keine antiquarische Hardware einsetzt. Oder hast du ein 100Mb-Quellserver?

[MaxB]

..Du hast ein Gbit-LAN..imo nicht vergleichbar mit einem 100Mbit-LAN

 

Natürlich habe ich GBit LAN, was anderes macht in der heutigen Zeit jawohl auch kein Sinn mehr, oder?

Hast Du etwa nur 2 Geräte (inkl. WLAN) in Deinem Netzwerk und bist Dir zu 100% sicher, dass dein Netzwerk-Switch/Router oder was auch immer nicht mit anderem Traffic beschäftigt ist?

Selbst über Power LAN (100 MBit-Hardware) schaue ich im Schlafzimmer 2 HD-Sender über RTSP (per UDP) störungsfrei. Nur beim WLAN mit 54MBit verwende ich TCP, da WLAN zu instabil ist.

Edited August 8, 2013 by MaxB

[omnium]

Wenn, wie du sagst, du Quellserver und Client direkt verbunden hattest, müsstest du allerdings ne Gb-Verbindung gehabt haben, wenn Du keine antiquarische Hardware einsetzt. Oder hast du ein 100Mb-Quellserver?

den Server habe/hatte ich fest auf 100Mbit full duplex festgeklemmt..ich habe keinen Gbit Router/Switch.

Der Server hat nur einen Realtek onboard NiC, die Clients haben Intel/Realtek onboard NICs bzw gehen über WLAN.

Um einen Fehler beim Realtek onboard NIC und Konfigurationsfehler auszuschliessen habe ich sogar den RS komplett auf den Client mit Intel NIC umgezogen...dann allerdings nur mit dem Ex-RS-Server/WLAN Client getestet...ok, ich werde mir für den alten Server eine PCIe Intel NIC kaufen und dann hier berichten.

.

 

Lieferung voraussichtlich: 12. August 2013

1 "Intel EXPI9301CTBLK PRO1000 Netzwerkkarte CT

.

Aber trotzdem frage ich Euch/mich, wieso ich trotz des evtl defekten NIC, mit dem netstream Plugin/iperf, keine Probleme habe/60 Mbit/sec über UDP schaffe?

 

--

no sig today

Edited August 8, 2013 by omnium

[MaxB]

Bevor neue Hardware gekauft wird wären ein Support.zip oder ein paar detailliertere Infos viel wichtiger, z.B. triit das Problem nur an einem Client auf, wurde RTSP mit TCP mal getestet, sind die verwendeten Codecs OK, gibt es ggf. Empfangsprobleme usw. ...

[nuts]

Das ham wir hier doch schon alles durch.

Bin für den Test mit PCIe Intel NIC ...

[omnium]

..hab' ja auch schon bestellt...die 25€ ist mir der _Spass_ allemal Wert. Das ist quasi der Wetteinsatz für/gegen Bauchgefühl/der Obulus für Erkenntnisgewinn

 

--

Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

[Samuel Beckett]

Edited August 8, 2013 by omnium

[dbraner]

Genau diese Erfahrungen habe ich auch gesammelt! Besonders Switche von "noname" Herstellern machen viele Probleme mit UDP und auch bei der Fritz.Box gab es am Anfang massive Probleme mit UDP-Traffic...

Ein weiteres Thema sind Netzwerkkarten! Seit dem ich auf meinen Servern mit Intel Netzwerkkarten arbeite sind die UDP-Probleme in Richtung 0 gegangen und wenn ein OnBoard-LAN nicht sauber läuft kommt da auch eine vernünftige NW-Karte rein.

Ich schicke hier bis zu 8 komplette QAM256 TS (=> ca. 400 MBps) in meinem Netzwerk hin und her um mit Transedit den UDP-Traffic zu checken. "Missing Pakets" gibt es manchmal beim Starten eines Tuners, danach bleibt es sauber.

 

Möglicherweise mit der Fritzbox und ihrer Software. Ansonsten muss ich die Switche jetzt mal in Schutz nehmen. Ein Switch verteilt Ethernet Pakete auf Layer 2. UDP hingegen ist in Layer 4 implementiert. Das bedeutet, dass einem normalen Hausgebrauch-Switch völlig egal ist, was in den Ethernet-Frames steckt, die er von einem Anschluss zum andern verteilt (ob IP mit TCP/UDP darüber oder Appletalk oder Rohrpost-Protokoll)

 

Bekannt sind allerdings Probleme zwischen NICs und Switchen oder zwischen Switchen unterschiedlicher Hersteller. Beispiel: Gigabyte Boards mit integriertem Realtek Chipsatz (NIC) sollte man tunlichst nicht an Netgear Switchen betreiben. Die mögen sich nicht und es kommt immer wieder zu Paketverlusten.

Edited August 8, 2013 by dbraner

[Moses]

Ein Switch verteilt Ethernet Pakete auf Layer 2. UDP hingegen ist in Layer 4 implementiert. Das bedeutet, dass einem normalen Hausgebrauch-Switch völlig egal ist, was in den Ethernet-Frames steckt, die er von einem Anschluss zum andern verteilt (ob IP mit TCP/UDP darüber oder Appletalk oder Rohrpost-Protokoll)

Das ist spätestens seit Gigabit Ethernet nur halbrichtig. Es ist richtig, dass der Switch eigentlich nur auf Ebene 2 arbeiten soll. Aber auf Ebene 2 gibt es mittlerweile auch Flußkontrolle (eigentlich schon bei 100Mbit/s eingeführt, http://de.wikipedia.org/wiki/Ethernet#Ethernet_flow_control ). Die können die beteiligten NICs oder der Switch besser oder schlechter machen. Bei TCP spielt das nicht so eine große Rolle, da hier TCP selber nochmal eine Flußkontrolle und insbesonder "kooperative Überlastvermeidung" macht (soll heißen: TCP bremst, wenn was schief geht ). UDP hat das alles nicht. Daher spielt hier die Flußkontrolle auf Ebene 2 eine viel größere Rolle. Es wäre m.E. schon sinnvoll zu versuchen die UDP Pakete gleichmäßiger auf das Netzwerk los zu lassen.

 

Bekannt sind allerdings Probleme zwischen NICs und Switchen oder zwischen Switchen unterschiedlicher Hersteller. Beispiel: Gigabyte Boards mit integriertem Realtek Chipsatz (NIC) sollte man tunlichst nicht an Netgear Switchen betreiben. Die mögen sich nicht und es kommt immer wieder zu Paketverlusten.

Ich wunder mich etwas, dass hier so vehemennt auf Realtek NICs rumgehackt wird... ich hab in meinem Netzwerk fast nur Realtek NICs und nie ein Problem damit gehabt. Aber ich missbrauche auch keinen Router-Ich-Kann-Alles-Mit-WLAN-Und-FileServer als Switch, sonder einen dedizierten Switch.

[omnium]

Die neue Netzwerkkarte ist angekommen. Die Artefakte sind verschwunden...da die UDP Bandbreite laut Transedit von ca. 13 Mbit/sec auf ca. 25 Mbit/sec gestiegen ist..aber immer noch massive Paketverluste...

 

<< Intel NIC >> << Realtek NIC >>

 

..war/ist der onboard Realtek-NIC jetzt defekt/arbeitet suboptimal/liegt es am chinesischen Freund/RS/?????

Theorien dazu überlasse ich Euch...ich habe keinen Bock mehr dem nachzugehen/das zu ergründen.

 

<edit>

mit jperf kommt ich wie bisher out of the box auf ca. 50 Mbit/sec. Der NIC-Empangsbuffer ist default 256 Bytes gross und lässt sich von 80-2048 einstellen..ohne Verbesserung. Der 'Übertragungsbuffer' hat default eine Grösse von 512 Bytes...Versuche mit 128-2048 haben auch nix geändert.

</edit>

 

--

Und er kommt zu dem Ergebnis: Nur ein Traum war das Erlebnis.

Weil, so schließt er messerscharf, nicht sein kann, was nicht sein darf.

[Christian Morgenstern, Die unmögliche Tatsache]

Edited August 12, 2013 by omnium

[CiNcH]

 

Theorien dazu überlasse ich Euch...ich habe keinen Bock mehr dem nachzugehen/das zu ergründen.

 

Du bist echt wie ein kleines Kind.

 

 

Wenn du von deinem Tripp wieder herunten bist, kannst du dann mal die Puffergrößen ("Send Buffer") im NIC Treiber vergleichen? Die sollte man in den Eigenschaftsseiten der NIC's im Geräte-Manager editieren können.

[Frank Sommer]

Nun, ich habe letzte Woche die NIC im RS (war Realtek) gegen eine NIC von Broadcom getauscht. Leider hing an der NIC aber noch ne CPU dran die mit getauscht werden musste. Auf Deutsch: Ich habe die HW des RS von einem Aspire One D270 (Atom N2600 CPU) gegen ein Aspire One 756 (Celeron 1007U) getauscht. Ein NB mit i3-CPU war mir für diesen Zweck zu teuer. Der Rechner ist im Schrank eingebaut und serviert ansonsten nur meine Hsussteuerung.

Seitdem habe ich keine Abbrüche, fehlende Pakete oder sonst was mehr. Es tut jetzt einfach. (Ich habe extra ein paar Tage gewartet bevor ich das hier schreibe).Die CPU ist ein bischen flotter und sogar das transcodieren eines HD Senders im Profil superfast mit 600kBit klappt jetzt auch.

 

BTW: Die UDP Rate mit iperf lag mit der alten HW angeblich bei 80mbit, Transedit hat bei zdfvision (HD-Programme) knapp 42Mbit gebracht, allerdings mit ca. 1% Paketverlust auf allen Kanälen. Ich lerne daraus, daß eine CPU-Auslastung von 30% im Taskmanager nicht bedeutet, daß keine Pakete verloren gehen. Es gibt wohl Effekte zwischen Himmel und Erde die ich nicht kenne die auch noch eine Rolle spielen.

 

 

Edited August 12, 2013 by Frank Sommer

[dbraner]

Ich wunder mich etwas, dass hier so vehemennt auf Realtek NICs rumgehackt wird... ich hab in meinem Netzwerk fast nur Realtek NICs und nie ein Problem damit gehabt. Aber ich missbrauche auch keinen Router-Ich-Kann-Alles-Mit-WLAN-Und-FileServer als Switch, sonder einen dedizierten Switch.

 

Bzgl. Flusskontrolle bei Ethernet: Du hast recht.

 

Bzgl. Realtek: Ich habe nur behauptet, dass es Probleme mit Gigabyte Boards mit Onboard Realtek Chipsatz und Netgear Switchen gibt (kein Router). Habe selbst die Erfahrung gemacht (Server mit Recservice und Gigabyte Board an NetGear Switch). Das Problem kann man in diversen Foren nachlesen. Üblicherweise schieben sich Gigabyte und NetGear gegenseitig die Schuld zu,

[CiNcH]

 

Wenn du von deinem Tripp wieder herunten bist, kannst du dann mal die Puffergrößen ("Send Buffer") im NIC Treiber vergleichen? Die sollte man in den Eigenschaftsseiten der NIC's im Geräte-Manager editieren können.

 

Hier mal meine Werte...

 

Intel 82579V Send Buffer: 512

Marvell Yukon Send Buffer: 256

 

Mit Intel NIC ist die UDP Übertragungsrate deutlich höher. Evtl. variiere ich diesen Werte bei Gelegenheit einmal...

 

 

Überflutet der RS evtl. den NIC? Aber wieso verbessert Flow Control dann die Situation? Über den Mechanismus sagt der Switch ja zum NIC, er soll mal langsam machen. Das würde ja das Überlaufen der NIC Puffer eher fördern. Oder evtl. blockiert dann auch das Senden auf höheren Ebenen?