massiver Geschwindigkeitseinbruch bei P2P Verbindung

Guten Tag die Damen und Herren,

Ich habe da leider ein kleines Problem. Ich kam heute auf Arbeit, und da hatte sich Just der Durchsatz einer meiner WLAN-Strecken durch 10-30 geteilt. Je nach Laune. Rolling Eyes

Zur Umgebung:

Wir haben eine WLAN-bridge zwischen 2 LANCOM OAP-54 Wireless AP`s. Die Strecke läuft seit ca. 1,5-2 Jahren stabil. Link Quality ist zwischen 50 und 60%. Durchsatz war früher 5-6Mb/s möglich. Seit Heute habe ich 100-500KB/s. Wir haben schon Soft- und Hardresets der Geräte durchgeführt. Messungen mit NETIO (s.U.) und Resets der sonstigen angeschlossenen Geräte. Eine Prüfung der Antennen auf Feuchtigkeit ist ebenfalls negativ. Ping-Zeiten sind übrigens akzeptabel, auch mit etwas größeren Paketgrößen. Copy- und Datenbankoperationen zum Server in dem Gebäude, welches ja mit dem WLAN angebunden ist sind wie gesagt quälend langsam. Meine User mögen das gar nicht, und ich bin mit meinem Latein am Ende.

Geräteinformationen:

Gerät: LANCOM OAP-54 Wireless
Hardware-Release: A
Firmware-Version: Ver. 7.60.0160Rel
Firmware-Datum: 25.02.2009
Firmsafe: symmetrisch, 2 Image(s)
Image 1 (aktiv): Ver. 7.60Rel (25.02.2009)
Image 2: Ver. 7.30 (20.03.2008)
Software-Optionen: keine

NETIO-Througput:

Client zu Server:

TCP connection established.
Packet size 1k bytes: 3327.71 KByte/s Tx, 15.57 KByte/s Rx.
Packet size 2k bytes: 3212.52 KByte/s Tx, 185.72 KByte/s Rx.
Packet size 4k bytes: 2910.95 KByte/s Tx, 36.65 KByte/s Rx.
Packet size 8k bytes: 3100.50 KByte/s Tx, 246.56 KByte/s Rx.
Packet size 16k bytes: 3210.14 KByte/s Tx, 164.69 KByte/s Rx.
Packet size 32k bytes: 3187.68 KByte/s Tx, 90.65 KByte/s Rx.
Done.

Server zu Client:

TCP connection established.
Packet size 1k bytes: 157.29 KByte/s Tx, 1035.89 KByte/s Rx.
Packet size 2k bytes: 138.40 KByte/s Tx, 2781.05 KByte/s Rx.
Packet size 4k bytes: 174.59 KByte/s Tx, 3620.74 KByte/s Rx.
Packet size 8k bytes: 95.69 KByte/s Tx, 2390.89 KByte/s Rx.
Packet size 16k bytes: 101.70 KByte/s Tx, 3456.67 KByte/s Rx.
Packet size 32k bytes: 65.80 KByte/s Tx, 857.78 KByte/s Rx.
Done.

Wenn jemand eine zündende Idee hat: Bitte raus damit!

MfG Maik

Moderator Anmeldungsdatum: 07.11.2004 Beiträge: 4500 Wohnort: Aachen

Moin,

wie man sehen kann, ist der Durchsatz ziemlich asymmetrisch. Auf einer der beiden
Seiten hat also etwas einen Schlag. Was zeigt ein Linktest dann so an Signal- und
Rauschwerten an?

Wenn man da keine nennenswerten Unterschiede sieht, lohnt sich auch ein Blick
in die LAN-(Fehler-)Statistiken, ob man z.B. auf einer der Seiten CRC-Fehler hat.
Bisweilen ist das WLAN völlig unschuldig und es klemmt auf der Ethernet-Seite..

Gruß Alfred

Hier mal die Ergebnisse von AP1:

Link Test:

Signalpegel: -55dBm
Rauschpegel: -94dBm
SNR: 39dB
Datenrate: T-108M
lokal gesehen:
Signalpegel: -56dBm
Rauschpegel: -88dBm
SNR: 32dB
Datenrate: T-108M

Fehler WLAN2:

RxFehler: 69722
TxFehler: 82
Tx-Verworfen: 85183
Wiederholungen: 1344942
Mehrfach-Wiederholungen: 361304
Dupes-Verworfen: 4400
Rx-CRC-Fehler: 69722

Fehler Lan:

Queue-Fehler: 74

die Ergebnisse von AP2:

Link Test:

Signalpegel: -58dBm
Rauschpegel: -91dBm
SNR: 33dB
Datenrate: T-108M
lokal gesehen:
Signalpegel: -56dBm
Rauschpegel: -88dBm
SNR: 32dB
Datenrate: T-108M

Fehler WLAN2:

Rx-Fehler: 1896777
Tx-Fehler: 9
Tx-Verworfen: 6578
Wiederholungen: 518257
Mehrfach-Wiederholungen: 40044
Dupes-Verworfen: 4894
Undekomprimierbar: 1
Rx-CRC-Fehler: 1896776

Fehler Lan:

Rx-Fehler: 12
Queue-Fehler: 25
Rx-CRC-Fehler: 7
Rx-Align-Fehler:5

Imho ist es so dass das WLAN der Übeltäter ist. Am AP2 gibt es noch eine Strecke, welche an WLAN1 ein anderes Gebäude anbindet. Diese Streke hat ebenfalls hohe Fehlerwerte auf der WLAN-Seite. Der Signalpegel ist hier etwas schlechter, SNR niedriger. Dennoch kann man hier beobachten dass die Fehlerwerte niedriger liegen:

Fehler WLAN1:

Rx-Fehler: 1592092
Tx-Fehler: 4
Tx-Verworfen: 6578
Wiederholungen: 190
Mehrfach-Wiederholungen: 513
Dupes-Verworfen: 5
Rx-CRC-Fehler: 1592092

Den Durchsatz habe ich auf dieser Strecke noch nicht gebenchmarkt, da sie nur für Verwaltungszwecke und zur Replikation kleiner Datenmengen über Nacht genutzt wird. Das Kopieren über Windows hat aber den gleichen niedrigen Durchsatz.

MfG Maik

P.S.: Danke für die Schnelle Antwort, Alfred!

Edit: Nachtrag: Die 2te WLAN-Strecke zeigt das gleiche Verhalten. Wir haben auch dort reproduzierbar 3Mb in Senderichtung, 50-200KByte/s in Empfangsrichtung. Ich denke der AP ist das Problem. Mochte der den Jahreswechsel nicht? Shocked

Update: Der Router war`s nicht. Ich habe einen in der Reserve liegenden L54 für die Bridge konfiguriert, angeschlossen -> gleiches Verhalten! Langsam weiß ich echt nicht mehr weiter... Zusätzlich haben wir zwischenzeitlich auch die Router mit neu gestartet, da Ich daran gedacht habe dass das Netz im Nachbargebäude ein anderes ist. Den Versuch war`s wert, auch wenn die RX/TX-Fehler sicherlich eine eindeutige Sprache sprechen. Wir tauschen heute noch einmal die Antenne auf der einen Seite (war bis heute nicht zugänglich) und sehen weiter. Wenn`s das nicht war bete ich dass einer von euch noch Ideen hat...

alf29 hat folgendes geschrieben:

Bisweilen ist das WLAN völlig unschuldig und es klemmt auf der Ethernet-Seite..

Was darf man sagen? Wir haben nun an allen möglichen Punkten Durchsatzmessungen durchgeführt: Die Strecke vom POE des Lancom im entfernten Gebäude zum Serverraum scheints zu sein. Nichtsdestotrotz kriegen wir nur 3-4Mb von AP zu AP durch gequetscht. Bei 13,5Mb theoretischer Bandbreite erscheint mir das etwas müde. Ebenfalls frage ich mich was es mit den CRC-Fehlern im WLAN auf sich hat. Hat da jemand einen Tip? Wenn man eh schonmal 4 Tage an solch einem Problem hängt darf es auch gern besser gehen als vorher wenn man fertig ist Wink

MfG Maik

Moderator Anmeldungsdatum: 07.11.2004 Beiträge: 4500 Wohnort: Aachen

Moin,

ein CRC-Fehler im WLAN ist im Prinzip genau das gleiche
wie bei anderen Medien: Auf der Übertragungsstrecke von
Sender zu Empfänger sind so viele Bits verfälscht worden,
daß auch die schon im Empfänger eingebauten Fehler-
korrekturmechanismen nicht mehr ausreichen, um das
gesendete Paket zu rekonstuieren. Aufgrund der anderen
physikalischen Eigenschaften eines Funkmediums im
Vergleich zu einem Kabel tritt so etwas bei WLAN viel
häufiger auf als bei einem Ethernet, aber das ist bekannt und
WLAN wirkt dem durch Bestätigung und Wiederholung von
Paketen entgegen. Von daher sind CRC-Fehler an sich
kein Beinbruch, zu Paketverlusten kommt es erst, wenn
ein Paket auch nach n Wiederholungen nicht ankommt (im
Sender dann als Tx-Fehler gezählt) - dann fangen die
Mechanismen z.B. im TCP an zu greifen.

Häufige Wiederholungen von Paketen kosten natürlich
Bandbreite. Es ist aber sehr schwer, festzulegen, was noch
eine 'akzeptable Rate' von Wiederholungen ist, da kann
eigentlich nur jeder Kunde selber eine 'gute' mit einer
'schlechten' Strecke vergleichen und seine eigenen Limits
setzen.

Zitat:

Die Strecke vom POE des Lancom im entfernten Gebäude zum Serverraum scheints zu sein. Nichtsdestotrotz kriegen wir nur 3-4Mb von AP zu AP durch gequetscht. Bei 13,5Mb theoretischer Bandbreite erscheint mir das etwas müde.

Verstehe ich das richtig, daß der Durchsatz jetzt wieder
symmetrisch ist?

Bei WLAN gibt es durch das CSMA-Protokoll und die
Bestätigungen von Paketen generell einen erheblichen
Unterschied zwischen Brutto und Netto-Rate. Bei einem
54 MBit-WLAN auf 5 GHz werden z.B. Nettoraten von
22..27 MBit als gut und normal angesehen. Im Turbo-Modus
kann man grob mit dem doppelten rechnen, aber auch da
nur unter optimalen Bedingungen. Dazu rechnet z.B. auch
die Paketgröße, durch das Bestätigen von Paketen hat
WLAN einen viel höheren Overhead pro Paket als ein
Ethernet, d.h. bei kleinen Paketen geht der Durchsatz deutlich
runter.

Gruß Alfred

Moderator Anmeldungsdatum: 03.01.2005 Beiträge: 1905 Wohnort: Ex-OPAL-Gebiet

Hi Alfred,

aus einem anderen Thread:

RottenSon667 hat folgendes geschrieben:

... wir analysieren das im Hausnetz lokalisierte Problem. Ich denke unsere tollen Hausmeister haben beim Schnee vom Dach schieben das Kabel vom AP zum Switch zerlegt. Aber das sehen wir nachher.

Vermutlich ist der Durchsatz dann wieder symmetrisch...

Viele Grüße,
Jirka

Hallo Alfred,

Wie Jirka schon schrieb habe ich gestern verschiedene Messungen an jedem Punkt wo sich das Medium ändert bzw. eine Verbindungsstelle ist getätigt. Jeweils in Richtung Haus1 und Haus2. Zur Umgebung:

Wir gehen hier von Haus1 mit einer LWL-Strecke zu einem Verteiler, von dort mit Cat.6 weiter zum Anschlusspunkt des WLAN-Mastes, über die P2P Strecke zu Haus2 und vom AP weiter über Kupfer zum Serverraum. Daher gibt es leider einige mögliche Fehlerquellen bzw. Punkte an denen man Tests durchführen muss. Letzter Fakt gestern war dass ich von einem direkt am AP1 angeschlossenen Notebook zu einem direkt an AP2 angeschlossenen Notebook folgende Transferraten erhalte:

TCP connection established.
Packet size 1k bytes: 3803.83 KByte/s Tx, 2597.52 KByte/s Rx.
Packet size 2k bytes: 3591.24 KByte/s Tx, 1269.45 KByte/s Rx.
Packet size 4k bytes: 4294.57 KByte/s Tx, 1693.87 KByte/s Rx.
Packet size 8k bytes: 4310.95 KByte/s Tx, 2409.65 KByte/s Rx.
Packet size 16k bytes: 4273.97 KByte/s Tx, 1074.53 KByte/s Rx.
Packet size 32k bytes: 4225.77 KByte/s Tx, 1045.08 KByte/s Rx.

Die Tests erfolgen alle mit NetIO im TCP-Mode.

Die Datenraten sind also direkt von AP zu AP akzeptabel, wenn auch mmn nicht gut. Vielleicht könnte man hier Optimierungen anstreben. Da wollte ich nachher noch ein wenig mit Komprimierung, Frequenz und Mode herum spielen.

Momentan läuft die Strecke mit folgenden Einstellungen:

108Mbit (Auto)
Komprimierung angehakt, jedoch im LanMonitor inaktiv angezeigt
2,4GhZ
Kanal 13

Abschließend kann man sagen dass du mit deiner Aussage dass es auch auf LAN-Seite hängen könnte recht hattest. Die Verbindung vom AP2 zum Serverraum ist messbar auf 3Mb/s tx und 200-300Kb/s rx limitiert. Wie gesagt messen wir jetzt aus woran es genau liegt. Ich hatte gestern Abend keine Lust mehr noch den LAN-Tester auszupacken. 8.00-19.30 hat gereicht. Wir haben zwischendurch immer wieder andere Aufgaben herein bekommen, daher kommt man manchmal nicht so voran. Danke für eure Hilfe, Ich halte euch auf dem Laufenden!

MfG Maik

Moderator Anmeldungsdatum: 07.11.2004 Beiträge: 4500 Wohnort: Aachen

Moin,

Komprimierung sollte man ausgeschaltet lassen. Leider
ist die von Atheros so konstruiert worden, daß alle Daten
dreimal über den PCI-Bus geschoben werden, auch wenn
die Gegenseite gar keine Komprimierung unterstützt. Bei
Embedded-Prozessoren und Raten von ein paar MByte/s
rennt man dann sehr schnell in Bandbreitenprobleme im
Businterface, und bekommt den Effekt, daß es mit
Komprimierung langsamer ist als ohne...

Gruß Alfred

Dann tun wir das auch so. Der Fehler ist mittlerweile auch lokalisiert, wenn auch nicht nachvollziehbar:

Die Server auf die zugegriffen wird haben als Standardgateway einen Bintec VPN5 Router. Dieser stellt sowohl das Internet bereit, als auch die Routen in unsere anderen Netze. Nun ist es so dass der Router die Bandbreite limitiert, wenn er von Haus2 zu Haus1 routet. Ich weiß NICHT warum das so ist. Ich bin nun erst einmal so vorgegangen dass ich für das Netz in Haus1 eine statische Route auf den betreffenden Servern eingetragen habe. Die Endlösung bleibt DAS aber nicht.

Ich halte euch auf dem Laufenden, falls gewünscht. Der Support hat mittlerweile auch geantwortet, denen sende ich nachher noch Informationen zu. Vielleicht kann man die Bandbreite im WLAN ein wenig optimieren Wink

MfG aus der Lutherstadt

Maik