Lancom 1781A an Kabelmodem Cisco ECP 3208

[LoUiS]

Hi,

in der naechsten LCOS Release wird das Verhalten korrigiert sein.


Ciao
LoUiS

[GrandDixence]

Der WAN-Queue-Fehlerzähler "DSL-CH-1" läuft auch unter der Konstellation "1781EF+ mit LCOS v8.84 und 150 MBit/s-Internetanschluss" bei Volllast hoch. Der 1781EF+ ist also mit LCOS < 9.00 RU2 nicht für sehr schnelle Internetanbindungen (> 125 MBit/s) geeignet. Warten wir mal ab, ob das Performance-Problem mit LCOS v9.00 RU2 behoben wird.

[LoUiS]

Nicht geeignet halte ich jetzt für masslos uebertrieben und fuer ein wirkliches Performance Problem halte ich das Verhalten auch nicht. Ich habe selbst ein symmetrische 200 MBit/s Verbindung und habe das Verhalten bei Bursts ebenfalls.
Trotzdem habe ich beim normalen Arbeiten keinerlei Probleme und auch bei Downloads mit mehreren Verbindungen bekomme ich noch immer mehr als genug Durchsatz. Da muessen ein paar Pakete wiederholt werden, aber das faellt bei den Geschwindigkeiten im normalen Arbeiten nicht so richtig ins Gewicht. Wie ich aber bereits schrieb wird das in einer der naechsten Versionen behoben sein. Ob man dafuer jetzt auf LCOS 9.90 warten muss, hoffe ich nicht. Ich denke das wird schon frueher kommen.

[GrandDixence]

Nicht geeignet halte ich jetzt für masslos uebertrieben und fuer ein wirkliches Performance Problem halte ich das Verhalten auch nicht.

In meinem Fall (1781EF+ mit LCOS v9.00 RU1 und 150 MBit/s) hat das "WAN-Queue-Problem" eine so grosse Auswirkung auf die allgemeine Internet-Performance, dass ich mir überlege, auf LCOS v8.84 zurück zu wechseln. Ich erreiche zum Beispiel bei Test-Downloads nur etwas mehr als die Hälfte der tatsächlich möglichen Download-Geschwindigkeit. Gemäss der LANCOM-Hotline liegt keine Fehlkonfiguration meines 1781EF+ vor. Die LANCOM-Hotline hat bestätigt, dass das "WAN-Queue-Problem" mit dem nächsten LCOS-Release behoben wird.

[LoUiS]

Hast Du auch mal mal gegen andere Server getestet, oder immer nur gegen diesen einen Uni FTP?
Ich hab da gerade selbst mal einen Download gestartet und bekomme bekomme nur knapp 75 MBit/s Durchsatz.
Teste ich andere Server komme ich auch auf weitaus hoehere Uebertragungsgeschwindigkeiten.

[GrandDixence]

Ja ich habe auch gegen andere FTP-Server getestet (inklusive japanischer FTP-Servern!). Jedoch erscheint mir der http://ftp-stud.hs-esslingen.de/ als der schnellste Server. Er ist der einzige Server, welcher mir ohne dazwischen liegendem 1781EF+ immer eine faden-gerade Download-Kurve mit der leitungsbedingten-maximalmöglichen Datenrate liefert!

Ist nicht der Server oder die Leitung zu schwach, kann mit dazwischen geschalteten 1781EF+ und LCOS v9.00 immer das gleiche Verhalten beobachtet werden:

Beim Start des Download erhöht sich die Datenrate, da das TCP Window vergrössert (TCP Window Size um 16 MB!) wird. Bis die maximal mögliche Datenrate erreicht wird, dann wird für wenige Sekunden die maximal mögliche Datenrate geliefert (in meinem Fall: 150 MBit/s). Danach läuft wegen einem Softwarefehler im LCOS irgendein Buffer/Warteschlange über und die Download-Geschwindigkeitskurve wird sehr instabil bzw. schwankt sehr stark.

[GrandDixence]

Da muessen ein paar Pakete wiederholt werden, aber das faellt bei den Geschwindigkeiten im normalen Arbeiten nicht so richtig ins Gewicht.

Wie der Screenshot der Wireshark-Aufzeichnung der Ethernet-Schnittstelle des LINUX-Client von den ersten Sekunden eines ISO-Image-Download ab dem FTP-Server der UNI Freiburg zeigt, sind nicht nur einige wenige Pakete nicht in Ordnung. Ich finde insbesondere seitenweise "TCP Dup Ack"'-Einträge in der Wireshark-Aufzeichnungen. Ich bin kein TCP/IP-Spezialist, kann die rot/schwarzen-Einträge nicht interpretieren, aber mir gefällt das schon rein optisch gar nicht..

[GrandDixence]

Anbei noch die Screenshots vom Firmenrechner, also komplett diversitäre Software+Hardware. Mir fällt auf, dass der Unterschied "mit/ohne 1781EF+" im Windows-Taskmanager weniger deutlich sichtbar ist als im GNOME-Systemmonitor. Jedoch ist der mirror.switch.ch ein nicht so leistungsfähiger Server. Die Einbrüche im Screenshot "IE10_direkt_am_Kabelmodem" sind Server-bedingt!

[GrandDixence]

Mit LCOS 9.00 RU2 wurde das Performance-Problem mit meinem LANCOM 1781EF+ behoben. Jetzt unterstützt der LANCOM 1781EF+ auch Datenraten von 150 MBit/s einwandfrei. Der WAN Queue-Fehlerzähler bleibt auch unter Volllastbetrieb auf 0. Die LANCOM-Entwicklung hat das Performance-Problem mit der LCOS-Version 9.00 RU2 behoben.

[LoUiS]

Der WAN Queue-Fehlerzähler bleibt auch unter Volllastbetrieb auf 0. Die LANCOM-Entwicklung hat das Performance-Problem mit der LCOS-Version 9.00 RU2 behoben.

Ich hatte bereits in einem meiner letzten Postings geschrieben, dass das in der naechsten Version gefixed ist.


Ciao
LoUiS

[Bernie137]

Hallo,

ich habe an 3 verschiedenen Router auch sehr schnell hochzählende DSL-Queue-Errors. 2x 1781EF+, 1900EF, jeweils 10.30.0167RU1. An vielen anderen Routern habe ich direkt Null DSL-Queue-Errors. Da haben entweder alle das interne Modem oder ein MOdem mit einem Uplinkkabel dran.

Bei den drei Routern mit den vielen Queue-Errors sind Bandbreiten von 200MBit/s im Spiel und jeweils davor ein Switch. Hat das was mit dem Problem aus den Vorjahren weiter oben zu tun?

Code: Alles auswählen

[Table] 2019/08/27 12:14:17,005
Content of table: /Status/DSL/Errors

Ifc   Rx-Errors Tx-Errors NIC-Errors Queue-Errors Rx-CRC-Errors Collisions Single-Collisions Multiple-Collisions Late-Collisions Excessive-Collisions Rx-Align-Errors Rx-Too-Short Rx-Too-Long Tx-Carrier Tx-Deferred
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DSL-1 16124     0         0          2699274      0             0          0                 0                   0               0                    0               0            16124       0          0          
DSL-2 16124     0         0          3135217      0             0          0                 0                   0               0                    0               0            16124       0          0          
DSL-3 0         0         0          5            0             0          0                 0                   0               0                    0               0            0           0          0          
DSL-4 0         0         0          0            0             0          0                 0                   0               0                    0               0            0           0          0          
DSL-5 0         0         0          0            0             0          0                 0                   0               0                    0               0            0  

Gruß Bernie

[GrandDixence]

Könnte an "Ethernet flow control" liegen. Oder der LANCOM-Router ist mit dem schnellen Internetanschluss überfordert (fraglich bei 1900EF):
aktuelle-lancom-router-serie-f41/bandbr ... 17271.html

https://en.wikipedia.org/wiki/Ethernet_flow_control

Wird der Internetanschluss über einen (Gigabit-)Ethernet-WAN-Port des LANCOM-Routers realisiert, empfiehlt sich die Datenübertragungsrate in Senderichtung (vom Heim-/Firmennetzwerk ins Internet) im LANCOM-Router künstlich zu drosseln. Damit sich im LANCOM-Router und nicht beim Medienkonverter ein Datenpaketstau in Senderichtung bildet.
fragen-zum-thema-firewall-f15/qos-funkt ... tml#p86139

[Bernie137]

Hallo GrandDixence,

danke für Deine Antwort.
Also Hardware NAT ist nicht im Einsatz.

Der Anschluss wird über einen Gigabit Ethernet Port am Lancom realisiert per IPoE mit DSL-2 Interface:

Code: Alles auswählen

> ls /Setup/Interfaces/dsl

Ifc       Operating        Upstream-Rate  Ext.-Overhead  Downstream-Rate
==========--------------------------------------------------------------
DSL-1     Yes              71680          0              51200
DSL-2     Yes              200000         0              200000
DSL-3     Yes              2600           0              11800
DSL-4     No               0              0              0
DSL-5     No               0              0              0

Könnte an "Ethernet flow control" liegen.

Ich werde es zum Test am Lancom mal ausschalten.

Gruß Bernie