VERBINDUNGSABBRUCH IAP-54

[BEIO]

Hallo,
wir haben 2 IAP-54 (v4.12) auf 1,7km mit O-18a Antennen (5 GHz) verbunden.

Der Durchsatz der Antennen ist gut (lt. WLAN-LINK-TEST meist auf 72 MBIT bei 17-20db SNR, alles im grünen Bereich).
Versuche ich allerdings diese vorhandene Bandbreite zu nutzen (etwa durch einen Filetransfer von 20MB von Standort A nach B), dann bricht die Verbindung nach 10-20 Sekunden ab und zwar IMMER (weshalb ich nicht an die Theorie vom Kanalwechsel glaube). Lässt man die Leitung in Ruhe oder fährt nur Internet- oder SQL-Datenverkehr, bleibt die Leitung einigermaßen stabil. FAZIT: Belastung führt nach kurzer Zeit zum Abbruch. Dann braucht es 2 Minuten bis wieder alles steht. Man kann sich vorstellen wie das ankommt.

Wir haben darauf hin alle Möglichkeiten durchgespielt, die Antennenverbindung so konservativ und vorsichtig zu konfigurieren, wie es nur geht (z.B durch logisches WLAN auf maximale 24MBit stellen oder TX-Burst off / HW-compression OFF, 5Ghz Modus auf Normal 54 MBit, etc. pp.)
Leider ohne Erfolg, das Phänomen bleibt, egal wie langsam die Übertragungsraten zwischen den Antennen eingestellt sind.

ALLERDINGS:
Workaround dadurch, dass die Leitung von den Routern, die zu den IAP-54 führen, auf 10Mbit full Duplex gedrosselt wurden. So funktioniert es:
72 mögliche MBit (alles auf best- und schnellstmöglich gestellt) durch die Luft und 10Mbit vom und ins LAN. Jetzt gehen auch 80MB (in etwa 3,5 Minuten) ohne Abbruch durch.

Wie soll man sich dieses Verhalten eigentlich erklären. Kommt der IAP bei 100Mbit nicht nach die Pakete von der 100BaseT-Schnittstelle an die Antennenseite durchzureichen und bricht daraufhin deren Verbindung ab?

Wir haben schon Stunden investiert, unsere Einstellungen sind vom Support abgenickt, trotzdem kommen wir nicht weiter und die wissen auch nicht weiter.

Welcher Techie weiss es besser ?
Wie können wir ein wenig aufdrehen?
Wir hätten gerne minimum stabile 36Mbit. Das müsste mit dem Equipment und bei dem Preis drin sein.

danke & Grüße

Bei

[Michael008]

Hi Bei,
mir ist bei eigenen Versuchen aufgefallen, dass die Pings bei steigender Übertragungslast bis hin zur max. Bandbreite(egal eigentlich wie hoch die ist) ab einem best. Punkt,(schätzungsweise 60%-75% Auslastung) ziemlich plötzlich in die Höhe schnellen. >1000ms.
(Vielleicht aufgrund von Kollisionen wie in einem alten BNC-Netz)
Das führt dann zu timeouts.
Du betreibst sicher ein P2P Netz, ich könnt mir vorstellen, das ein AP durch die hohen Pingzeiten die Verbindung für verloren erklärt und einmal rundrum auf die Suche geht.
Mich würde euere Meinung zu dieser Theorie interessieren.
Bisher habe ich es so gelöst, das ich einen zusätzlichen Lancom routen lasse und mit QoS die Bandbreite so beschränkt habe, das Pingzeiten bis max. 400ms auftreten. Das läuft stabil, ist aber umständlich und nicht gerade im Sinne von P2P.
Außerdem muss man für das Routing einen zusätzlichen Adressbereich einrichten.
Gruß
Michael

[alf29]

Moin,

eine Unterbrechung dieser Länge deutet eher
auf eine Radar(fehl)erkennung hin. Die sind
zwar mit der 4.12 deutlich seltener geworden, aber
ganz weg bekommt man sie wegen der strengen
DFS-Vorschriften nicht

Netto etwa 400 KByte/s ist deutlich zu langsam,
eine Turbo-A-Verbindung mit 72 MBit brutto
leistet theoretisch etwa 40MBit/s netto, Euch fehlt
also etwa ein Faktor 10. Das übliche Problem
bei Outdoor-Strecken ist eine gar nicht oder zu kurz
eingestellte Maximaldistanz, so daß Timing und
Timeouts nicht an die Ausbreitungszeiten der
Radiowellen angepaßt werden. Der Effekt ist dann,
daß der Sender ein Paket 10-mal schickt und die
Bestätingungen der Gegenseite immer zu spät
bekommt...

Gruß Alfred

[BEIO]

Moin,

eine Unterbrechung dieser Länge deutet eher
auf eine Radar(fehl)erkennung hin. Die sind
zwar mit der 4.12 deutlich seltener geworden, aber
ganz weg bekommt man sie wegen der strengen
DFS-Vorschriften nicht :-(

[...] Das übliche Problem
bei Outdoor-Strecken ist eine gar nicht oder zu kurz
eingestellte Maximaldistanz, so daß Timing und
Timeouts nicht an die Ausbreitungszeiten der
Radiowellen angepaßt werden. Der Effekt ist dann,
daß der Sender ein Paket 10-mal schickt und die
Bestätingungen der Gegenseite immer zu spät
bekommt...

Gruß Alfred

Hallo,

Wir haben den maximalen Abstand recht naturgetreu gesetzt.
hier meine WLAN-Konfiguration:

Konfiguration:
- WLAN-Interface „ein“
- Basisstation
- 5 GHZ
- Unterbänder 1
- automatische Kanalwahl
- 108 Mbit/s Turbo-Modus nur primäre Antenne
- nur auf primärer Antenne senden
- Antennen-Gewinn 6dBi (Standard-Kabel-Länge)
- Reduktion 0
- Basisstationsdichte mittel
- max Abstand 2km (tatsächlich 1,7km)
- Kanal-List leer
- TX Burst ein
- HW-Compression an
- PTP exclusiv
- Kanalwahl: eine Master / eine slave
- Logisches Netzwerk: aktiviert, geschlossen, MAC-Filter: Ein
- Logisches Netzwerk Übertragung:
- Paketgrösse 1550
- minmal: auto
- maximal: auto
- Broadcast 2 Megabit
- Schwellwert 2347
- keine WEP Verschlüsselung

Hättest Du einen Tipp zum Tuning ?
Wie können wir verhindern, dass die Leitung wieder abbricht, sobald wir auf 100Mbit vom LAN aus zurückschalten.

Das DFS Trace sieht bei uns etwa auszugsweise folgendermaßen aus:
"
[DFS] 1905/05/18 15:35:07,340
[WLAN-1] received radar pulse RSSI 21 at timestamp 0x000000001bad0b18:
0000: 00


[DFS] 1905/05/18 15:35:07,390
[WLAN-1] received radar pulse RSSI 18 at timestamp 0x000000001baddffe:
0000: 00


[DFS] 1905/05/18 15:35:07,430
[WLAN-1] received radar pulse RSSI 16 at timestamp 0x000000001bae65ee:
0000: 00


[DFS] 1905/05/18 15:35:07,430
[WLAN-1] received radar pulse RSSI 16 at timestamp 0x000000001bae6c6a:
0000: 00


[DFS] 1905/05/18 15:35:07,450
[WLAN-1] received radar pulse RSSI 21 at timestamp 0x000000001baec044:
0000: 00


[DFS] 1905/05/18 15:35:07,460
[WLAN-1] received radar pulse RSSI 18 at timestamp 0x000000001baed35a:
0000: 00


[DFS] 1905/05/18 15:35:07,600
[WLAN-1] received radar pulse RSSI 18 at timestamp 0x000000001bb1106b:
0000: 00
"

Rennt also ziemlich wild und schnell durch. Trotzdem gibt es einen Kanalwechsel lt. Logbuch nur 2-5 mal am Tag. Das ginge ja noch...

Was ist bei uns das Problem?

Grüße

Hendrik

[alf29]

Moin,

- Unterbänder 1

Das muß eine 2 sein. Unterband 1 ist in diesem Fall das
Band von 5,15...5,35 GHz, das ist gar nicht für
Outdoor-Betrieb erlaubt, außerdem gilt da ein EIRP-
Limit von 23 statt 30 dBm.

- max Abstand 2km (tatsächlich 1,7km)

probiert's ruhig auch mal mit ein paar Kilometern mehr.
Zuwenig ist im Zweifelsfalle schädlicher als zuviel.

- HW-Compression an

Das besser auslassen. Zum einen erreicht man damit
in diesem Modus wahrscheinlich eher eine Verlangsamung
als eine Beschleunigung, zum anderen scheint die
Verwendung der Kompresion aus noch nicht geklärten
Gründen die Wahrscheinlichkeit von Radar-Fehlauslösern
zu erhöhen.

Wie können wir verhindern, dass die Leitung wieder abbricht, sobald wir auf 100Mbit vom LAN aus zurückschalten.

Es gibt natürlich Mittel und Wege, die Radarerkennung
abzuschalten. Legal wäre das trotzdem nicht...

Rennt also ziemlich wild und schnell durch. Trotzdem gibt es einen Kanalwechsel lt. Logbuch nur 2-5 mal am Tag. Das ginge ja noch...

Es läuft in der Software ein Mustererkennungsalgorithmus,
der nur anschlägt, wenn die Pulse in einer bestimmten
zeitlichen Abfolge kommen, die bekannten Radarsystemen
entspricht.

Was ist bei uns das Problem?

Erstmal ins richtige Band und die Kompression aus. Dann
sehen wir weiter.

Gruß Alfred

[BEIO]

Ich habe jetzt
- das Unterband auf 2
- den Abstand auf 4 km
- und die HW-Kompression ab-
gestellt.

Der Effekt:
- ich hatte im LINK-TEST SNR fettere Werte (sogar mal 25, hatte ich bisher noch nie)
- momentan scheint die Leitung jedoch eher ein wenig instabiler, der Link ist öfters ganz weg und braucht lange bis er wieder da ist.
- das LOG hat nun durchschnittlich alle 4-6 Minuten einen Kanalwechsel verzeichnet, auch ohne besondere Last.

Leider ist am anderen Standort gerade kein Mitarbeiter mehr da, was die Änderungen der Einstellung schwierig macht...

Hast du mir noch einen Tip für morgen?
Sollte ich mal master und slave vertauschen? Auf unserer Seite (master) ist eine FH in der Nähe, weiss der Teufel, was die da so experimentieren. Würde der Wechsel etwas bewirken?

Danke für die kompetente Hilfe...

Hendrik

[alf29]

Moin,

nein, weitere Hilfen habe ich leider nicht. Die
Radarerkennung ist zulassungsrelevant, an
der können wir nicht so ohne weiteres drehen,
und die aktuellen Atheros-Chips können es
nicht besser...

Ist die Kompression auf beiden Seiten aus?

Gruß Alfred

[BEIO]

Moin,

nein, weitere Hilfen habe ich leider nicht. Die
Radarerkennung ist zulassungsrelevant, an
der können wir nicht so ohne weiteres drehen,
und die aktuellen Atheros-Chips können es
nicht besser...

Ist die Kompression auf beiden Seiten aus?

Gruß Alfred

Guten Morgen Alfred,

Die Antennen haben sich jetzt wohl auf einen Kanal geeignet, auf dem nichts los ist. Seit gestern 18:00 Uhr gab es keine Kanalwechsel mehr.
Die Leitung ist jetzt auch unter Belastung stabil. Das sind gute Nachrichten. Zumindest habe ich gerade 100 MB ohne Fehler herüber gezogen, dass ganze aber leider in 7 Minuten.
Der Durchsatz ging nie über 400KB/s.
Die Accesspointliste zeigte anonsten in etwa
rx-phy link 28, rates je 36-48M, link 35.

An welchem Wert kann ich jetzt schrittweise drehen um die Performanz zu erhöhen?
Soll ich den Abstand von 4km auf einen noch größeren Wert verändern ?

Ich muss bei diesen WLAN-Link-Werten doch davon ausgehen, dass die Antennen gut ausgerichtet sind und auch keine Wasser eingedrungen ist oder ähnliches. Ich gehe also davon aus, dass auch noch stärkere Antennen das Problem nicht lösen würden? Gäbe es bei LANCOM für unseren Zweck besser passende Produkte?

Oder wird das LCOS 5 die Rettung sein und bis wann ist es fertig?
Wie mir langsam dämmert, bist Du ja sehr nahe an der Entwicklung :-)


Danke für die Unterstützung und Grüße

Hendrik

[alf29]

Moin,

Du könntest mal in den WLAN-Paketstatistiken schauen, wie sich
die WLAN-Tx-Fehler zu der Gesamtpaketzahl verhalten. Wenn's
100% Fehler sind, deutet das auf einen zu niedrig eingestellten
Abstand hin.

Oder wird das LCOS 5 die Rettung sein und bis wann ist es fertig?

LCOS 5 wird - vermutlich - einen schnelleren Kanalwechsel nach einer
Radarerkennung bieten, weil die ETSI-Vorschriften inzwischen so weit
klar gestellt sind, daß man das darf. Wann LCOS 5 weiß aber noch keiner,
das ist noch mitten in der Entwicklung.

Wie mir langsam dämmert, bist Du ja sehr nahe an der Entwicklung

Viel schlimmer

Gruß Alfred

[BEIO]

Morgen,

ich hab jetzt mal "Werte löschen" gewählt und danach nochmal 100Mb über die Leitung gezogen. Hier die Werte für die Fehler- und Paket-Transportstatistik:

Rx-Fehler 33736
Tx-Fehler 3
Stack-Fehler 0
Tx-Verworfen 387062
Wiederholungen 48217
Mehrfach-Wiederholungen 39523
Dupes-Verworfen 11
Unentschluesselbar 1637
Undekomprimierbar 67335
----------------
Rx-Pakete 86967
Tx-Pakete 29869
Rx-Broadcasts 50
Rx-Multicasts 9
Rx-Unicasts 85
Rx-Komprimiert 1632273
Tx-Broadcasts 50
Tx-Multicasts 292
Tx-Unicasts 29530
Tx-Komprimiert 1002744

Die TX-Fehler halten sich also im Rahmen...
Kannst du sonst irgendwas aus dem Kaffeesatz lesen?

gruß

Hendrik

[alf29]

Moin,

bei der 4.12 werden leider einige WLAN-spezifische
Zähler mit dem Delete-Values nicht zurückgesetzt.
Von daher enthalten die Compress/Retry-Werte
wahrscheinlich noch Werte von vorigen Konfigs.
Könntest Due die Geräte mal durchbooten, damit wirklich
alle Zähler auf Null gesetzt werden?

Gruß & Dank

Alfred

[BEIO]

Hallo,

nach einem beidseitigem Kaltstart (per Software) und der erneuten 100MB-Übertragung, sieht es so aus:

Rx-Fehler 59776
Tx-Fehler 11
Stack-Fehler 3
Tx-Verworfen 418
Wiederholungen 1710
Mehrfach-Wiederholungen 1277
Dupes-Verworfen 0
Unentschluesselbar 10
Undekomprimierbar 0
----------------
Rx-Pakete 89437
Tx-Pakete 29621
Rx-Broadcasts 59
Rx-Multicasts 10
Rx-Unicasts 0
Rx-Komprimiert 0
Tx-Broadcasts 68
Tx-Multicasts 398
Tx-Unicasts 21168
Tx-Komprimiert 0

gruß

Hendrik

[BEIO]

Hallo,

... ich bin dann für eine Woche weg.
bitte aber trotzdem auf meine Message von vorher antworten. Meine Kollege ist mit der Sache vertraut.

danke & Grüße

Hendrik