Jump to content

Full Duplex Patch ?


alloc

Empfohlene Beiträge

sprich: wo kein "gegenverkehr" da keine kollisionen ;-)

effektiver performancegewinn schätze ich auf maximal 10%, aber wirklich maximal, wenn ich von unbelastetem lan-anschluss ausgehe.

 

der größte Vorteil ist das völlige(!) Fehlen von Kollisionen. Stichwort: Kollisionsdomäne vs. CSMA/CD

wer sich einmal beim streamen auf einen NFS-Server die Kollisionsstatistik ansieht, erkennt die Vorteile recht deutlich.

Alternativ mal die CollisionDetect-LED am e.g. Switch beobachten.

Zitat:

 

Aufgrund der auftretenden Kollisionen ist es nicht möglich, die theoretische Übertragungskapazität eines Mediums voll auszuschöpfen. In der Praxis kann man davon ausgehen, dass sich im günstigsten Fall etwa 70 % der Nominalleistung erzielen lassen, unter ungünstigeren Bedingungen sind es unter 30 %. Die Ursache ist einfach: Je mehr Rechner sich im Netzwerk beteiligen und je höher die Auslastung steigt, desto mehr Kollisionen treten auf, folglich sinkt der reell erzielte Datendurchsatz deutlich ab.

 

Nutzen nur zwei Stationen dasselbe Übertragungsmedium, schafft der Duplex-Betrieb Abhilfe. Bei Ethernet kann das Medium mittels Switch oder Bridge in mehrere Kollisionsdomänen aufgeteilt werden. Dann können pro Segment oder Kollosionsdomäne zwei Knoten (Stationen) im Duplex-Betrieb aktiv sein, ohne dass es zu Kollisionen kommt.

 

 

http://de.wikipedia.org/wiki/CSMA/CD

http://de.wikipedia.org/wiki/Ethernet#CSMA.2FCD-Algorithmus

http://de.wikipedia.org/wiki/Kollisionsdom%C3%A4ne

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • Antworten 78
  • Created
  • Letzte Antwort

@oppih:

und dein post zeigt das erfahrung durch lesen von wikis nicht ersetzt werden kann.

das ist nämlich in dem besprochenen zusammenhang absoluter unsinn *rofl*

 

du wirst mir ja nicht weissmachen das du auf deinem anschluss der box "viele endgeräte" im selben netz hast, oder hast du ein ganzes hochhaus verkabelt ;-)

 

fakt ist:

da die gängigen homeswitches maximal 4 ports haben und diese zumindest zwischen 100mbithub und 10mbithub geswitcht sind dürft dort nur der verkehr ankommen der zur box soll und die broadcasts/multicasts.

wenn du nicht gerade dein netz falsch konfiguriert hast und parallel zum streaming auch noch ein neues image auf die box knallen willst, sondern wenn du einfach nur streamst von der box zum pc dann dürftest du nur "sehr wenige" kollisionen sehen.

 

und die 70% sind absoluter wiki-humbug (wie immer, vertraut mal nicht so oft auf die wiki). alleine durch den overhead und generelle protokolleffekte sind maximal 90% sowieso nur möglich, auch bei FD. 100% erreicht man nie.

abhängig von der tcp implementierung sowie vom delay der verbindung meist sogar noch viel weniger ;-)

somit sind 80% für fullduplexbetrieb eher realistisch.

und es gibt, wenn kein gegenverkehr herrscht, zwischen fd und hd nur den unterschied das fd eben nicht zwischendurch immer mal wieder "auf die leitung hört" um der gegenstation auch eine möglichkeit der sendung zu geben.

 

eine kollision entsteht übrigens nur dann wenn beide gleichzeitig senden. denn vor dem senden hören ja beide erst mal auf die leitung ob sie belegt ist.

in grossen netzen (mit LANGEN kabeln bzw kaskadierten hubs) ist natürlich die wahrscheinlichkeit einer kollision höher, da die signale länger brauchen bis sie bei der empfangenden seite sind und somit das zeitfenster für eine unbemerkte doppelsendung größer wird.

deswegen darf man auch nicht mehr als 3 hubs kaskadieren bzw gibt es längenrestriktionen:

sobald die zeit die ein paket vom sender zu empfänger braucht größer wird als die sendezeit für das paket (beim kleinstmöglichen ethernetpaket) kann dieses von einer kollision zerstört werden ohne das der sender das hört.

deswegen kann man ausserhalb des rfc auch oft längere kabel nehmen wenn man fd fährt ;-)

 

 

 

und nfs ist so ziemlich das schrecklichste beispiel dafür. denn das protokoll ist nun wirklich ziemlich miserabel implementiert *g*

kommt netwerktechnisch direkt nach cifs im reigen der schlechten protokolle.

streamen macht übrigens per multicast immer noch am meisten sinn, btw.

dort gibt es nämlich keinen "gegenverkehr".

nebenbei macht "echtzeitkommunikation" wie streaming mit einem fileserviceprotokoll ja mal gar keinen sinn. da sträuben sich dem geneigten netzwerker die haare zu berge.

 

@cumalot:

wir reden von collisionen auf der leitung. collisionen zwischen den ports gibt es but cut-through switches wenn 2 stationen gleichzeitig senden. leider sind viele home-billigswitches eben solche cut-through switches, und mit denen bringt auch FD sehr wenig.

sinn macht, gerade im gemischten 10/100 umfeld, immer ein "store and forward" switch, der pakete zwischenspeichert.

leider werden aber cutthrough switches sowie hubs die als switches gelabelt sind immer noch an home-user verscherbelt obwohl sie nicht halten was sie versprechen *sigh*

 

zu einem anderen thema:

kann man eigentlich von der dbox aus auch per multicast streamen? das wäre denke ich die effektivste methode möglichst resourcensparend zu steamen.

und man kann damit dann auch mehrere clients gleichzeitig versorgen (am pc schauen und an einem anderen aufnehmen, zB).

Link zu diesem Kommentar
Auf anderen Seiten teilen

ja super aufsatz.

wir reden hier nicht von komplexen netzwerken.

es geht hier um das ausloten der letzten reserven der dbox.

kollisionen treten beim nfs-streamen in 10HD so gehäuft auf, dass es den verfügbaren

durchsatz signifikant, beweisbar verringert.

selbst mit deiner fiktiver 10%-iger steigerung wäre das ENORM und ein großer erfolg.

nfs mag scheisse sein, ist aber nunmal nicht zu ersetzen und erheblich performanter als

CIFS/FTPS, alternativen nicht bekannt. alles andere ist nonsens.

oder programmierst du fix was besseres?

 

es ist toll das du alles besser machen willst, obwohl mir fehlt der glaube das du es tust.

10MF/FD auf Sagem habe ich getan.

das ist der unterschied zwischen theoritischem hätte/wäre/wenn und dem praktischen tun.

Link zu diesem Kommentar
Auf anderen Seiten teilen

hab ich irgendwo gesagt das ich ein problem damit hab? ganz im gegenteil. *sigh*

zum bereich hobby gehört dazu das man auch total sinnlose sachen macht *g*

 

ich wollte nur die diskussion mal darauf lenken dass vielleicht ein anständiger multicast server die bessere lösung wäre als mit krücken-filetransfer protokollen echtzeitdaten speichern zu wollen ;-)

 

achja, ich vermisse übrigens immer noch eine genaue messung wie viel performance es eigentlich wirklich bringt.

 

und offtopic:

das ist der unterschied zwischen theoritischem hätte/wäre/wenn und dem praktischen tun.

toll. haste also deine box umgebaut... klasse :-)

was soll mir der kommentar sagen, ausser zu provozieren?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich weiß ja gar nicht, warum ihr euch hier so aufregt. Fakt ist, dass es möglich ist und es deshalb auch gemacht werden kann.

Bei NFS treten die Kollisionen eben auf, nen Multicast server hat die DBox nicht und deshalb ist es auch in gewissem Maße sinnvoll der Box FD beizubringen.

Diejenigen, die das Sinnlos finden, müssen sich hier ja nicht beteiligen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke für die Info... ich hatte schon ein Uboot aus einer anderen Distribution runtergeladen und war drauf und dran (aus purer Verzeweiflung), es einfach mal auszuprobieren....

 

Schade. Mir geht zwar der tiefere Sinn ab, warum die nicht zusammen passen; aber wird schon so sein, wenn ihr es sagt....

 

Also wohl warten auf die nächste Version....

Link zu diesem Kommentar
Auf anderen Seiten teilen

Mir geht zwar der tiefere Sinn ab, warum die nicht zusammen passen; aber wird schon so sein, wenn ihr es sagt....

Kannst Du schon glauben. :rolleyes:

Im uboot ist nicht nur festgelegt, welcher Bereich (root, var) welchem Partitionseintrag (mtdx) zugeordnet ist, auch die Größe der Bereiche ist darin festgelegt. Und paßt das alles nicht exakt zum Image auf der Box, ist die Box nicht mehr bootfähig ("kein System").

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • Admin

Da ich keine umgebaute Box habe und auch nicht vorhabe, eine umzubauen,

kann ich das FD nicht testen und bin auf die Zuarbeit derjenigen angewiesen,

die das eingebaut haben wollen. Bekomme ich Links zu falschen oder unvoll-

ständigen Patches sollte es nicht verwundern, wenn es nicht funktioniert.

Sollte also jemand einen getesteten Patch zur Verfügung stellen, baue ich ihn

ein, anderenfalls lege ich die Sache aus Zeit- und Interessengründen erst mal

auf Eis.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich hab ja keine Ahnung vom Image-Bau...

 

Würde dieser Link irgendwie helfen:

 

http://tuxbox-forum.mine.nu/forum/viewtopi...t=uboot#p352717

 

Hier steht, wie man bei denen zum Einbau vorgeht und dass dieses uboot wohl den Patch eingebaut hat.

 

Ansonsten kann ich zu dem Gesamtthema noch sagen: ich bin schon seit sehr langer Zeit auf solch eine Lösung scharf, weil die Konstruktion, die man machen muss, um das Streamen halbwegs vernünftig ans Laufen zu kriegen, schon einiges an Problemen darstellt (extra switch (mit halb duplex Fixierung) für dbox; extra Netzwerkkarte am Server; damit verbunden eigenes IP-Segment für diese Konstruktion). Und trotz aller Konstruktionen ist es mir immer wieder unangenehm, meiner besseren Hälfte erklären zu müssen, dass ich die Tageschau auf ARD nicht aufnehmen kann, weil es da eine kleine Limitierung mit der box gibt... -> die Lösung genau dieses ARD/ZDF Problems erhoffe ich mir von dem Patch, wäre also super, wenn er irgendwie rein käme.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Sollte also jemand einen getesteten Patch zur Verfügung stellen, baue ich ihn

ein, anderenfalls lege ich die Sache aus Zeit- und Interessengründen erst mal

auf Eis.

 

Ich meine, der Patch im Tuxbox Wiki wurde aktualisiert. Zumindest ist dort das fehlende Gleichheitszeichen enthalten.

Leider komme ich gerade nicht in das Wiki... scheint offline zu sein.

 

Zum Testen biete ich meine beiden Sagems (1xI) gerne an ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 weeks later...

Hallo,

 

habe mir mal das neue Key-Image draufgezogen, um 10mbit fullduplex zu testen.

 

Die Testbox war eine Nokia AVIA 500 SAT BOX. Um den NIC-Chip auf fullduplex umzuschalten wurde einfach PIN 21 auf Masse gezogen. Die Leitung hatte ich ja schon, vom Umbau der Netzwerkstatusanzeige. Pin 21 ist ja mit der Collisions-LED verbunden.

Ich habe einfach einen Jumper gesetzt, um vom NIC-Chip auf die LED, oder auf Masse umzuschalten.

 

+ --- LED ---- Jumper ---------PIN21 NIC

GND --------------'

 

Soviel zur Hardware.

 

In die botconf des Key-Image habe ich einfach die Zeile aus TuxboxWiki "bootcmd=setenv bootargs console=ttyS0,9600 root=/dev/mtdblock2 rootfstype=squashfs dbox_duplex=1;fsload;bootm" eingetragen und los gings.

 

Die Gegenstelle war einmal mein PC und einmal mein EISFAIR Server.

 

Nun zu den Ergebnissen

 

vor den Umschalten auf fullduplex:

 

DBOX an PC mittels Crosslinkkabel und NIC des PC auf 10bit-halb

FTP Kopie deiner Datei (Imagedatei ca. 8mb groß) mittels FlaschFXP

1,08 mbit/s vom PC zur BOX

816 kbit/s von BOX zum PC

 

DBOX an SERVER mittels Crosslink und NIC des SERVERS auf 10mbit-halb

FTP Kopie deiner Datei (Imagedatei ca. 8mb groß) mittels M-Comander

850 kbitB/s vom Server zur BOX

750 kbitb/s von BOX zum Server

 

NFS Netztest (Testprogramm von Worschter) von BOX zu SERVER und zurück 10mbit-halb

mit r/wsitze 32768

8258 von BOX zum Server

8258 von Server zur BOX

mit r/wsitze 16384

7876 von BOX zum Server

7757 vom Server zur BOX

mit r/wsitze 8192

7371 von BOX zum Server

7211 von Server zur BOX

mit r/wsitze 4096

5953 von BOX zum Server

6649 vom Server zur BOX

 

NFS Netztest von BOX zum SERVER und zurück 10mbit-halb jedoch zwischen Box und Server ist ein Switch (T8 von Conrad) zwischengeschaltet.

mit r/wsitze 32768

8393 von BOX zum Server

abgebrochen, (dauert ewig lang) von Server zur BOX

mit r/wsitze 16384

7757 von BOX zum Server

1505 vom Server zur BOX

mit r/wsitze 8192

7529 von BOX zum Server

4162 von Server zur BOX

mit r/wsitze 4096

7529 von BOX zum Server

4162 vom Server zur BOX

mit r/wsitze 4096

6320 von BOX zum Server

2039 vom Server zur BOX

 

NFS Netztest von BOX zum Server und zurück 100mbit-halb jedoch zwischen Box und Server ist ein Switch (T8 von Conrad) zwischengeschaltet.

mit r/wsitze 32768

8677 von BOX zum Server

8126 von Server zur BOX

 

 

Jetzt wird die BOX auf Fullduplex umgeschaltet

 

DBOX an PC mittels Crosslinkkabel und NIC des PC auf 10mbit-full

FTP Kopie deiner Datei (Imagedatei ca. 8mb groß) mittels FlaschFXP

118 kbit/s vom PC zur BOX

1,13 mbit/s von BOX zum PC

 

DBOX an Server mittels Crosslink und NIC des SERVERS auf 10mbit-full

FTP Kopie deiner Datei (Imagedatei ca. 8mb groß) mittels M-Comander

31 kbit/s vom Server zur BOX

1000kbit/s von BOX zum Server

 

NFS Netztest (Testprogramm von Worschter) von BOX zu Server und zurück 10mbit-full

mit r/wsitze 32768

8827 von BOX zum Server

2959 von Server zur BOX

mit r/wsitze 16384

8827 von BOX zum Server

1946 vom Server zur BOX

mit r/wsitze 8192

7876 von BOX zum Server

abgebrochen, (dauert ewig lang) von Server zur BOX.

mit r/wsitze 4096

8000 von BOX zum Server

abgebrochen, (dauert ewig lang) von Server zur BOX.

 

Fazit:

Bei meinen Test kam heraus, dass bei der BOX-Einstellung von 10mbit-halb immer die Verbindung über Switches am schnellsten ist, im Vergleich zu einer Direktverbindung. Aber dazu gibt es ja einen eigenen Beitrag.

Aber interessant ist jetzt wenn die BOX im Fullduplex Betrieb läuft, Direktverbindung zu PC oder Server, ist sie um einiges schneller beim Senden der Daten als im halbmodus mit Switch.

Anders sieht es aber beim Empfangen von Daten aus, da geht die Geschwindigkeit in den Keller. Ich vermute ein Treiberproblem seitens der DBOX.

Da ich leider keinen Switch besitzt bei dem sich die Ports fest auf 10mBit-full Einstellen lassen, kann ich das nicht testen. Aber ich habe schon einige Switche getestet und es zeigte sich immer, dass der Switch noch zusätzlich Geschwindigkeit brachte.

Ich habe mich damals für den T8 von Conrad entschieden, da günstig im Preis, gute Werte beim Senden der Daten von BOX zum Server hatte. Die Datenrate vom Server zur BOX ist mir beim Streaming eigentlich egal, da ich mit der BOX nur Aufnehme, wiedergeben tue ich die Dateien mit der XBOX.

 

 

Grüße

Carlos12345

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo,

 

Streaming habe ich noch nicht versucht.

 

Nochmals zu meinem Test.

 

beim Test wenn die Box auf 10mbit-full eingestellt war, war auch die Gegenstelle auf 10 mbit-full eingestellt.

 

*ich habe auch probiert die Box auf 10mit-full, und die Gegenstelle auf 10mbit-halb zu testen, der NFS Test brach aber wegen read/write error ab.

 

Auch Sagem oder Philips Benutzer, die über einen Switch müssen, haben ein duplex Mischmasch Problem. Außer man kann bei den verwendeten Switch, die Ports fest einstellen.

Bei meinem Test, der 10mibt-fullduplex Geschwindigkeit, wurde kein Switch verwendet, da ich keinen Switch mit einstellbaren Ports besitze.

 

Ich wollte im Test nur zeigen, dass 10mbit-full doch zusätzliche Geschwindigkeit bringt, da ich bei allen Tests, wenn die BOX mit dem Server direkt verbunden war und auf halbduplex läuft, nur auf maximal 8258 Durchsatz komme.

 

Mit einem Switch zwischengeschaltet, die Box läuft immer noch auf halbduplex, erreiche ich schon einen Durchsatz von maximal 8393.

Da ja jetzt ein Switch zwischengeschaltet ist, kann ich die Gegenstelle nun auf 100mbit halbduplex umstellen, die BOX läuft immer noch auf 10mbit halbduplex. Der Datendurchsatz steigt nun auf maximal 8677. Die 100mbit halbduplex haben sich bei früheren Netzwerktests als schnellste Variante bewährt.

 

Im Vergleich dazu wird jetzt die BOX auf 10mbit fullduplex umgeschaltet und mit einem Crosslinkkabel direkt mit der Gegenstelle verbunden. Die NIC der Gegenstelle wird jetzt fest auf 10mbit fullduplex eingestellt, daher auch kein duplex Mischmasch!

Nun steigt der Datendurchsatz bei den Tests auf 8827. Im vergleich im 10mbit halbduplex Betrieb war nur ein Durchsatz von 8258 zu erreichen.

 

Allerdings geht bei meiner Nokia, beim Empfangen von Daten im fullduplex Betrieb, die Datenrate in den Keller.

Senden Top, empfangen Flop!

Ich würde vermuten, dass das von NIC Treiber der DBOX kommt. Denn wenn ich schnell Senden kann müsste der NIC Chip auch zum schnellen Empfangen geeignet sein.

 

Ich wäre gerne dazu bereit meinen Switch zu zerlegen, vielleicht könnte man ja einen Port fest auf 10mbit full einstellen (Hardware mäßig). :lol:

 

Oder wir bringen der BOX autoneg bei. Anscheinend fehlt ja nur ein bestimmtes Protokoll oder so. Kann man das nicht nachrüsten? ;)

 

Für mich wäre der fullduplex Betrieb schon interessant da ich zum Streamen ja nur über die BOX zum Server gehe, wiedergeben tue ich über die XBOX.

 

Grüße

Carlos_1481

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 weeks later...

@ SnowHead

 

Ich habe ja zum Umschalten in den Fullduplexmodus die Befehlszeile aus Tuxbox Wiki genommen.

"bootcmd=setenv bootargs console=ttyS0,9600 root=/dev/mtdblock2 rootfstype=squashfs dbox_duplex=1;fsload;bootm"

 

Hat doch bei mir funktioniert mit dem Keywelt Image, oder dachte es zumindest.

 

Übrigens für die Nokia Benutzer scheint sich auch eine Lösung anzubahnen.

http://tuxbox-forum.dreambox-fan.de/forum/...a&start=180

Link zu diesem Kommentar
Auf anderen Seiten teilen

Für die Fullduplex Tester hätte ich hier noch einen manageable switch zum Verkauf.

 

Original verpackter 8-Port switch von Zyxel mit der Bezeichnung ES-2008. Der switch ist einstellbar per Webinterface oder RS-232 Konsole. Ein entsprechendes RS-232 Kabel liegt mit bei.

Der switch hat direkt ein 230V Netzteil verbaut und wird über eine Kaltgerätekabel angeschlossen (auch mit dabei). Das ganze in der Originalverpackung.

 

Wenn da jemand Interesse dran hat, einfach kurz ne PM schicken.

 

Gruß

Didge2002

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

  • Wer ist Online   0 Benutzer

    • Keine registrierten Benutzer online.

×
×
  • Neu erstellen...