Batman über Halbduplex?

Moin,

wir haben hier in einem Flüchtlingsheim über Cat3-Kabel 10 Mbit/s Halbduplex gemacht. Also durch einen Switch fest eingestellt.

Wenn man nur Clientnetz drüber schickt und am anderen Ende einen Router mit Originalfirmware aufbaut, läuft das total gut. Aber Batman kommt auf Halbduplex irgendwie gar nicht klar. Wenn man über dieselbe Strecke Batman spricht und hinten den 841er (selbe Hardware) mit Gluon betreibt, krüppelt das irgendwie bei unter einem Mbit rum und ist nicht wirklich nutzbar.

Hat da mal jemand Erfahrungen mit gemacht? Woran könnte das liegen?

Grüße
Matthias

Wichtig ist das an beiden enden des Kabels wirklich fest halb Duplex eingestellt ist und nicht nur eine Seite. Eine direkte Erklärung habe ich nicht, da ja auch WLAN nur halb Duplex ist. Werde es aber bei Gelegenheit mal selber testen mit nem alten 10 MBit Hub den ich hier irgendwo rum fliegen habe.

Ich hab noch nicht rausgefunden, wie man dem Switch im 841er das ansagt. Können soll er es, aber mir ist nicht klar, ob der entsprechende Patch mainlined wurde und wie die Syntax ist.

Aber eigentlich zeigt das Gerät 10 Mbit/s Halbduplex in der Konfig an. Leider ist es mir nicht gelungen das mii-tool-Paket zu installieren. Das ist nicht in OpenWRT drin.

Müsste auto negotiation das nicht selbständig anpassen?

Tut sie, wenn man es auf einer Seite vorgibt.

Batman kommt damit aber halt nicht klar. Und wie man es zwischen zwei 841ern erzwingt, weiß ich nicht.

Automatisch hatte die Strecke immer 100 Vollduplex, was aber zu drastischen Paketverlusten führt, sobald die Leitung ausgelastet wird.

Bei mesh on lan wird rebroadcast abgeschaltet, da davon ausgegangen wird dass keine Pake verloren gehen.

Hier dürfte es bei half duplex zu problemen kommen. Versuche doch mal dies umzustellen.

1 „Gefällt mir“

Ich möchte Dir keine Hoffnung machen, selbst wenn man an beide Enden der Batman-Ethernet-Strecke einen manged Switch stellt, der fest auf 10HD genagelt ist: Auch ohne den bei Dir eventuell auftretenden Paketloss und anderweitig auffälligen Werte: Der Batman lahmt unfassbar. Mehr als 2MBit/s würde ich da als nutzbaren Clientdurchsatz „im Stundenmittel“ nicht erwarten. (Speedtest natürlich gern auch 5MBit/s)
Das ist vermutlich ein ähnlicher Grund, warum Batman auf Wifimesh mit stabilen 270Brutto/70MBit/s TCP-netto-FDX(!) nur maximal 1/3 davon (25MBit/s) an Batman-Durchsatz liefert. Das ist alles sehr unerfreulich. Und der Grund, warum man auch für sekundäre Links gern war richtig schnelles haben möchte.

Hm, die Geschwindigkeit kann es ja eigentlich nicht sein, weil WLAN heute, wie du schreibst, teilweise echt fix ist. Es scheint mir mehr was mit dem Halbduplex zu tun zu haben. Denn sonst würde es von 100 Mbit/s auch nur maximal ~33 liefern und da hab ich eigentlich schon mehr gesehen.

Das scheint mir ein echter Bug zu sein und wenn wir den finden, oder verstehen, wo er herkommt, bietet das potentiell auch bessere WLAN-Meschlinks.

Interessant ist doch die Frage: Warum funktionieren WDS-Brücken so viel besser? Die sind defacto auch Halbduplex, werden aber halt so gepuffert, dass keine Pakete verloren gehen.

Irgendwie kommt Batman nicht damit klar, wenn Pakete verloren gehen.

Kann ich so bestätigen. Gerade mal nen kleinen Testaufbau gemacht.

Links: WDR4300 ist der Uplink. Direkt schafft der in unserem derzeitigen Fastd/BAT14 Netz ca. 11 MBit. Mesh on LAN eingeschaltet.
Mitte: Allnet ALL210 8 Port 10 MBit Hub.
Rechts: 841Nv10 mit Mesh on WAN.

Ohne Hub, also Kabel vom 841er in den 4300, die erwarteten 11 MBit/s beim Speedtest direkt vom unserem Gateway.

Mit Hub schafft der Download gerade mal so die 5 MBit/s.

Mein Anschluss ist ein 100/6 MBit/s von Kabeldeutschland/Vodafone über FritzBox 6490.

Naja gut, aber 5-7 ist eh Maximum über 10er Halbduplex. Da ist dein Messergebnis eh ziemlich gut eigentlich. Wir hatten deutlich weniger.

direkt macht der in dem aufbau fastethernet. der Hub kann nur 10 halb-duplex. Die 5,27MBit liegen schon nahe am theoretisch möglichen (80%), da die Antwortpakete auch über die Leitung müssen und Wiederholungen bei Kollisionen. Ich habe bisher nur einmal 90% gesehen und das waren 2 Maschinen die direkt gekoppelt waren für ein Backup.

Möchte auch nicht unerwähnt lassen, das mein Client viele Anläufe brauchte mit Hub zwischen beiden Knoten bis er per DHCP eine IP bekommen hat. Mit direkter Kabel Verbindung war per DHCP sofort eine IP da. Die Kollisions LED am Hub war im übrigen fast immer an, sobald beide Knoten darüber verbunden waren.

Ich weiss leider nicht, wie man einen simplen Switch dazu bringt, Packet-Aggregation zu machen wie die besseren Airmax&Co-Bridges.
Meiner Vermutung nach ist das ein X-Modem-Effekt, der da an der Performance sägt, also „non-sliding-window“, und Ack für jedes einzelende Paket. Plus hohe Packet-Rate. (Und dass die proprietären WDS-Bridges das mehr oder weniger mutig transparent in „Y-modem-G“ auflösen, mit welcher Magie auch immer.)

Was ist denn „total gut“?
Halbduplex ist jetzt nicht wirklich was besonderes für das Protokoll, da ist dann halt länger das PHY belegt.

Vielleicht ne doofe Frage: Warum bei dem alten Klingldraht nicht funken? (wird wohl Gründe geben)

Das hat MPW doch beschrieben: Bei der Nutzung von 10TX/H für br-client bekommt er die zu erwartenden Durchsatzwerte (ich tippe auf „mehr als 8MBit/s bei typischer Nutzung“).
Und bei der Nutzung des 10TX/H für br-mesh gibt es netto auf dem dahinterliegenden br-client unter 1MBit/s.

Ich halte das für einen deutlich fühlbaren Unterschied.
Und leider kann ich ihn technisch nachvollziehen.
Was nichts daran ändert, dass es sich nicht schön anfühlt.
(Und das hat jetzt wenig mit „Klingeldraht“ zu tun)

Wenn wirklich keine Chance besteht, diesen unperformanten Draht zu tauschen (und auch das vielleicht irsinnig erscheinende „Herumprobieren“ von anderen -falschen- Ader-Paarungen und erneutem 10FDX-Ausmessen nichts bringt) und dieser Link strategisch wichtig ist, würde ich evtl. den Versuch mit einem Satz VDSL-Modems wagen, Allnet hat da Paare für unter 200€.

Ich fragte nach Daten nicht nach Vermutungen.

Also was wir noch rausgefunden haben, dass die Idee, auf einer Seite etwas „fest einzustellen“ nicht funktioniert. Es gibt irgendein RFC, was besagt, das wenn auf einer Seite auf Auto steht und auf der anderen Seite z. B. 100 Vollduplex, dann geht die automatische Erkennung auf 100 Halbduplex. Man müsste also beide Seiten fest einstellen. Die Switche der 841er müssten das eigentlich können, ich habe aber den Befehl dafür noch nicht rausgefunden. Das einzige was geht, ist durch 10 Mbit/s Halbduplex dies zu erzwingen oder 100 Mbit/s Halbduplex. Aber 10 Vollduplex kann man nicht erzwingen, ohne es auf beiden Seiten einzustellen.

Wenn man alles auf Auto lässt(100 Vollduplex) und eben kein Batman macht, sondern nur Clientnetz, läuft es. Auf den kurzen Strecken optimal, die längste hat 2% Paketverluste. Da die DSL-Leitung eh der begrenzende Faktor ist, haben wir das jetzt so gelassen. Es ist halt schade, dass die Hälfte der Router jetzt nicht mit Gluon sondern mit Originalfirmware läuft.

Auf Grund der Testergebnisse sind wir ziemlich sicher, dass es an Batman liegt und nicht an den Kabeln. Laut Spezifikationen kann man über diese Kabel bis zu 60 m 100 Mbit/s Vollduplex Ethernet machen. Wir kennen die Kabellängen nicht, können sie nur schätzen, es müsste aber darunter liegen und mit einem normalen Netz läuft es auch. Nur Batman kommt nicht klar.

Entweder zu viele kleine Pakete oder ein Bug im Batman. Natürlich kann man funken, war uns aber auf Grund der räumlichen Gegebenheiten zu aufwändig.

Grüße
Matthias

swconfig dev switch0 port 0 get link
swconfig dev switch0 port 0 set link options

Beide Befehle funktionieren nicht. Kannst du mal ein ganz konkretes Beispiel geben? Z. B. LAN1 auf 10 Mbit/s Vollduplex setzen.

Wieviel kB „extra“ benötigen denn die ethertools im Image?