Seit LCOS 7.26 deutlich bessere Signalwerte bei WLAN

[SST]

Nabend...

Also ich kann einen besseren Link als auch schneller Daten Übertragung bestätigen... vorher 1,5-2MB jetzt 2,1MB konstant

[rzaw]

siehe bild

[Buster]

Die Atheros-Chips funktionieren so, daß man regelmäßigt eine Messung des Rauschpegels auf dem
Medium anstoßen muß - der Wert der letzten Messung steht unter Status->WLAN->WLAN-Parameter
oder bei neueren Firmwaren auch unter Status->WLAN-Radio. Dieser Messung kann man einen
Startwert mitgeben, der solange gilt, bis die Messung abgeschlossen ist. Der Rauschpegel ist
ist insofern wichtig, als daß von der Hardware zurückgegebene RSSI-Werte relativ zum zuletzt
gemessenen Rauschpegel sind. Wenn die Hardware nach einem Neustart noch keinen gültigen
Wert hat (also 0 anstelle irgendetwas unter -70 dBm), dann ergeben sich natürlich keine sinnvollen
RSSI-Werte.

Mir ist jetzt nur nicht klar, ob das heißen soll, dass bisher das Rauschen immer falsch angezeigt wurde oder ob sich wirklich etwas an der Empfangsqualität verbessert hat. Der SNR ist für das Vermessen ja nicht unerheblich und wenn da mal eben Sprünge von 7dB auftauchen nur wegen einem Softwareupdate, dann fragt man sich schon ob man nun den alten oder den neuen Werten glauben soll. Wir haben für bestimmte APs schon Bandpassfilter angeschafft, weil dort das Rauschen über -80 dB im Mittel gestiegen ist und die haben geholfen. Nun update ich einen AP, der noch ohne Filter ist und sehe, dass dies "auf dem Papier" denselben Effekt hat. Zumindest die Bandbreite hat sich bei diesem AP dadurch nicht erhöht (bleibt bei ~450KB/s wie vorm Update).

[Buster]

Wenn ich mir die beiden Graphen anschaue, dann tippe ich jetzt eher mal auf einen Bug in LCOS7.26, denn wieso soll es plötzlich keine Schwankungen im Rauschen mehr geben und -106dB im Durchschnitt?!

[_Flo_]

Offensichtlich ist dieses Feature oder dieser BUG noch nicht ganz "ausgereift".

Nach einem probeweisen Upgrade von vier 5,6 GHz Funkstrecken (2 Funkstrecken neue L-54ag Hardware, gekauft dieses Jahr; 2 Funkstrecken L-54ag Hardware gekauft vorletztes und letztes Jahr), welche vor dem Upgrade mit identischer 6.32er Konfiguration und Firmware bestückt waren, haben hier folgende Erfahrung gemacht:

Alle Geräte zeigen nach dem Upgrade deutlich verbesserte Signalwerte auf Grund geringerer ermittelter Rauschwerte an, jedoch:

Von der "verbesserte" Rauschwertbestimmung profitieren offensichtlich nur LANCOM Geräte mit Atheros Chipsätzen neuster Generation. Diese hatten im Testlink auch eine bessere Performance und Linkstabilität.

Bei den "alten Geräten" (Chipsätze vom letzten Jahr und davor) hat sich der Effekt ins Negative gewendet:
- Rauschpegel pauschal 95dB (BUG??)
- Linkstabilität deutlich schlechter: von einfachen Pingverlusten, zu Linkabbrüchen, bis hin zu sich auf einmal komplett deaktivierenden WLAN Chips.
- deutlich geringer Linkperformance (nur noch etwa 5-25% im Vergleich zu FW 6.32)
==> ein Aktivieren der alten FW 6.32 und Rückspielen der gesicherten Konfigs hat die Probleme sofort wieder behoben!

@Alfred: Kann es sein, dass der Rauschwert nicht mehr korrekt bestimmt wird? Das würde erklären, warum ältere Geräte, welche bauartbedingt höhere Rauschwerte besitzen, nicht mehr korrekt funktionieren.

-Flo

[alf29]

Moin,

etwas hatte ich darüber ja schon in diesem Thread geschrieben,
ich schreibe's aber gerne noch einmal etwas ausführlicher - wenn
Ihr hier zehn Minütchen Zeit zum Lesen & Nachvollziehen habt.

Wie, keine Zeit? Egal, ich erzähl's trotzdem

Ausgangspunkt der Sache ist, daß man bei Atheros-Chips eine
regelmäßige Rausch-Kalibrierung durchführt, d.h. der Chip wartet
auf eine 'Sendepause' und mißt den Signalpegel. Wie oft das
getan wird, kann man unter Setup->WLAN im Menü einstellen,
allerdings nur, wenn keine Betriebsart mit DFS aktiv ist. Bei
DFS muß man den Kanal nämlich nicht nur bei Radarsignalen,
sondern auch bei zu hohem Rauschpegel verlassen - ein zu hoher
Rauschpegel muß auch als Indiz für einen Primärnutzer gewertet
werden. Der Grenzwert liegt aber jenseits dessen, was man selbst
in einem 'schmutzigen' Umfeld so an Rauschen findet...

Der zuletzt gemessene Rauschpegel hat aber noch eine weitere
Funktion, er dient nämlich als Referenzpegel für RSSI-Werte, d.h.
wenn ein Paket empfangen wurde, dann gibt ein Atheros-Chip dessen
Signalstärke in dB relativ zum aktuellen Rauschpegel aus.

Direkt nach einem Reset/Neustart der Hardware hat der Chip
natürlich keinen gültigen Rauschpegel, bis die erste Messung
abgeschlossen ist. Als RSSI bekommt man in dieser Phase
ziemliche Phantasiewerte...das war leider bei einem Kunden das
Problem, denn dessen (LANCOM-)Clients sind so eingestellt, daß
sie sich nur zu einem AP verbinden, wenn dessen Beacons einen
bestimmten Mindest-Signalwert haben. Dummerweise ist der Aufbau
auch noch so, daß der Client einen Video-Stream empfängt, und
wenn der Client im Betrieb sein Funkmodul neu startet, dann ist
das Medium durch den Video-Stream so gesättigt, daß es anstelle
einiger Millisekunden auf einmal diverse Sekunden braucht, bis
die erste Kalibrierung abgeschlossen ist. Das war dann lange
genug, daß der Client meinte, der AP wäre 'weg', weil die Beacons
auf einmal alle so schwach erschienen.

Netterweise hat Atheros aber vorgesehen, bei der
Rauschkalibrierung einen programmierbaren Startwert vorzusehen,
der solange gilt, bis die Kalibrierung abgeschlossen ist. Also
wurde als Startwert einfach anstelle einer Null der zuletzt
gemessene Wert eingesetzt, und mit einem Merge ist diese Änderung
in die 7.26 gewandert. Für den Fall, daß auch kein letztes
Ergebnis verfügbar war, wurde als Startwert -95 dBm eingesetzt,
was auch an anderer Stelle als guter 'Defaultwert' angenommen
wird.

So ist es in der 7.26 drin, bei näherer Betrachtung hat das
Verfahren aber einige Tücken:

(1) Bei der Übernahme des 'letzten' Wertes wurde nicht
berücksichtigt, ob dieser Wert überhaupt auf dem gleichen
Kanal gemessen wurde - z.B. bei einem Scan bekam ein Kanal
als Startwert das Ergebnis des letzten Kanals...die kommende
7.28 (oder wie immer sie heißen wird) wird die letzten
Ergebnisse pro Kanal nachführen.

(2) Der Startwert wird offensichtlich nach Ende der Kalibrierung
nur durch deren Ergebnis ersetzt, wenn das Ergebnis
*niedriger* ist. Füttert man also bei wiederholter
Kalibrierung immer das letzte Ergebnis als Startwert ein, so
werden die Werte immer nur niedriger, und reagieren nicht auf
eine Verschlechterung des Kanals.

(3) -95 dBm sind wohl speziell für die alten 3-Chip-Module bei
2,4 GHz ein bisserl optimistisch...

(4) Der gemessene Rauschpegel wird nicht nur für RSSI-Werte
benutzt, sondern beeinflußt intern auch die CCA-Schwelle,
d.h. den Signalpegel, ab dem der WLAN-Chip das Medium als
'belegt' betrachtet und nicht sendet. Fängt man sich einen
zu niedrigen Wert ein, dann sendet der Chip nicht mehr...

Man könnte also den Startwert wieder fix auf Null senden und
damit das alte Verhalten bekommen. Andererseits ist das aber
wegen des oben beschriebenen Kundenszenarios nicht möglich,
außerdem scheint dieses Vehalten bei manchen Szenarien durchaus
positive Effekte zu haben - mit dem Startwert bügelt man quasi
Fehlmessungen mit viel zu hohen Peglen aus, weil der Chip sie
nicht übernimmt.

Also muß man irgendwie einen sinnvollen Zwischenweg finden, und
an dem tüftele ich noch und hatte mich vergleichsweise bedeckt
gehalten. Ein sinnvoller Ansatz könnte z.B. sein, als Startwert
den letzten Wert *plus einiger dB* zu nehmen, auf diese Weise
unterdrückt man immer noch Ausreißer und kann trotzdem auf einen
sich verschlechternden Kanal reagieren. Des weiteren wird man
den 'Notanker' -95 wohl durch einen Chipsatz-abhängigen Wert
ersetzen müssen...

Grüße & frohe Feiertage

Alfred

[_Flo_]

Hallo Alfred,

vielen Dank für deine ausführliche Darstellung zur Thematik:
Mit diesen Hintergrundinformationen lassen sich die ermittelten Effekte und auch andere beobachtete Probleme auf einmal deutlich besser nachvollziehen.

Was würde eigentlich dagegen sprechen, die erfassten NOISE Werte zu mitteln und bei starken NOISE Schwankungen zusätzlich die Messzyklen automatisch zu verkürzen, bzw. umgekehrt zu verlängern?

z.B.
NOISE = 0.3x Mittelwert der letzten 100 NOISE-Messungen + 0.3x Mittelwert der letzten 10 NOISE-Messungen + 0.4x letzter NOISE-wert.

... und dabei alle unbekannten NOISE-Werte durch einen chiptypischen, manuell änderbaren/optimierbaren Wert für den Kaltstart-Fall ersetzten.

Ein frohes Fest und ruhige Feiertage wünscht euch allen,
-Flo

[_Flo_]

noch ein kleiner Nachtrag:
Mit dem alten (vor FW 7.26) NOISE-Erfassungsverfahren haben wir hier teilweise die Beobachtung gemacht, dass auf Funkstrecken mit sehr hohem Datenaufkommen nach Ermittelung eines einzelnen "zu hohen" Rauschwertes die Linkperformance bis zu einem erzwungenen Kaltstart zusammenbrach:
Ein einzelner NOISE Wert kann offensichtlich vor FW 7.26 folgende Kettenreaktion auslösen:
sehr hoher NOISE-Wert (z.B. -55dB) => schlechte SNR => zurückschalten auf sehr geringe Datenrate => Vollauslastung, bzw. Überlastung der Funkverbindung => keine , oder erst sehr, sehr späte Erfassung eines neuen, brauchbaren NOISE Wertes, weil das Funkmedium plötzlich ständig belegt ist.

Hoffentlich lässt sich durch Einführung von brauchbaren NOISE-Mittelwerten oder NOISE-"Max.werten" dieses Problem zukünftig umgehen...

[alf29]

Moin,

Was würde eigentlich dagegen sprechen, die erfassten NOISE Werte zu mitteln und bei starken NOISE Schwankungen zusätzlich die Messzyklen automatisch zu verkürzen, bzw. umgekehrt zu verlängern?

So etwas gibt es im LCOS schon. Wenn ein neu ermittelter Wert um mehr als 5 dB höher liegt als
das Mittel der vorigen Meßwerte, wird die Rate auf eine Sekunde hochgesetzt. Entweder man
bekommt danach wieder einen 'normalen' Wert oder das Mittel paßt sich so dem neuen Wert
schneller an.

Gruß Alfred

[_Flo_]

Hallo Alfred,

So etwas gibt es im LCOS schon. Wenn ein neu ermittelter Wert um mehr als 5 dB höher liegt als
das Mittel der vorigen Meßwerte, wird die Rate auf eine Sekunde hochgesetzt.

hmm, merkwürdig: wie kann es dann passieren, dass sich der Rauschpegel bis zu einem erzwungenen Kaltstart plötzlich irgendwo in der Region des besten ermittelten Signalwertes "festfrisst"?

Wird nur der letzte ermittelte NOISE Wert immer als Grundlage zur Berechnung des SNR herangezogen, oder ein Mittelwert? Und falls Mittelwert, aus welchen Werten setzt sich dieser zusammen?

Offensichtlich kann ein sinnvoll gewählter "Notanker", bzw. können robuster bestimmte NOISE-Werte scheinbar die Grundlage für eine bessere Linkperformance und -stabilität bei Outdoor-Richtfunkverbindungen sein.

Frohe Feiertage,
-Florian

[alf29]

Moin,

das sind zwei unterschiedliche Paar Schuhe. Da eine betrifft die Ermittlung in der Hardware und
einen eventuellen Startwer, das andere etwas, was die Software schon immer anhand der Ergebnisse
macht.

Wird nur der letzte ermittelte NOISE Wert immer als Grundlage zur Berechnung des SNR herangezogen, oder ein Mittelwert?

Es ist immer der letzte Wert, der angezeigt wurde, das wird durch die Hardware vorgegeben - man
kann nun einmal nicht einen bestimmten Wert in der Hardware setzen, man muß das zur
Kenntnis nehmen, was die Hardware ermittelt. Was ich meinte, ist daß die Firmware schon
immer die letzten 20 Werte mithält und wenn ein neuer Wert mehr als 5 dB höher als der Mittelwert
dieser letzten 20 ist, dann wird eine neue Messung sofort anstatt nach dem konfigurierten
Intervall gemacht - in der Hoffnung, daß das nur ein Ausreißer war. Mit der Änderung bezüglich
des Startwertes konnte so etwas gar nicht mehr passieren...

Offensichtlich kann ein sinnvoll gewählter "Notanker", bzw. können robuster bestimmte NOISE-Werte scheinbar die Grundlage für eine bessere Linkperformance und -stabilität bei Outdoor-Richtfunkverbindungen sein. Smile

Ja, aber das Problem ist eben, daß man in der Hardware keinen Wert von der Software aus
setzen kann - man kann nur in gewissen Grenzen das Ergebnis einer Messung beeinflussen.

Frohe Feiertage,

Danke gleichfalls - bisher waren sie lecker wie immer und für morgen ist auch noch etwas
Roastbeef im Kühlschrank

Gruß Alfred

[_Flo_]

Hallo Alfred,

[...] man kann nun einmal nicht einen bestimmten Wert in der Hardware setzen, man muß das zur Kenntnis nehmen, was die Hardware ermittelt.

Wie ist es dann möglich, dass mit der 7.26er Firmware der NOISE-Wert nicht schlechter als -95dB werden kann? Ist das nur ein Anzeigefehler?

[...] wenn ein neuer Wert mehr als 5 dB höher als der Mittelwert dieser letzten 20 ist, dann wird eine neue Messung sofort anstatt nach dem konfigurierten Intervall gemacht [...]

Funktioniert das auch in der umgekehrten Richtung, also wenn der neue Wert 5dB geringer ist, als der Mittelwert? Wird nur eine zweite Kontrollmessung gemacht, oder soviele Messungen hintereinander, bis der Mittelwert sich mit unter 5dB Unterschied der jeweils letzten Messung angenähert hat?

Werde mich heute noch mit einer leckeren Gans verwöhnen lassen

Viele Grüße,
-Florian

[alf29]

Moin,

Wie ist es dann möglich, dass mit der 7.26er Firmware der NOISE-Wert nicht schlechter als -95dB werden kann? Ist das nur ein Anzeigefehler?

Direkt nach dem Einschalten hat man keinen vorherigen Wert, also wird der 'Notnagel' -95
als startwert für die erste Kalibrierung angenommen. Und von dort ab kann es eben nur noch
bergab gehen, wenn man voraussetzt, daß die Kalibrierung in der Hardware nur nach Werten
sucht, die besser sind als der Startwert...

Funktioniert das auch in der umgekehrten Richtung, also wenn der neue Wert 5dB geringer ist, als der Mittelwert?

Nein, das greift nur für Ausreißer nach oben.

Wird nur eine zweite Kontrollmessung gemacht, oder soviele Messungen hintereinander, bis der Mittelwert sich mit unter 5dB Unterschied der jeweils letzten Messung angenähert hat?

Die neue Messung wird nur schneller angestoßen. Falls der Rauschpegel sich wirklich verschlechtert
hat, dann bekommt man natürlich wieder einen Wert, der deutlich vom Durchschnitt der
letzten 20 Messungen abweicht, usf. Gleichzeitig wandern damit aber auch die Messungen mit dem
alten Wert beschleunigt aus der Historie heraus.

Gruß Alfred

[_Flo_]

Hallo Alfred,

Und von dort ab kann es eben nur noch bergab gehen, wenn man voraussetzt, daß die Kalibrierung in der Hardware nur nach Werten sucht, die besser sind als der Startwert...

Was hälst du davon, wenn man in zukünftigen Firmwareversionen den "Notangelwert" selbst festlegen kann? -88dB bei den alten Geräten und -95dB bei der neuen Generation sollten i.d.R. ein guter Startwert sein

Nein, das greift nur für Ausreißer nach oben.

Wäre schön, wenn das auch in die andere Richtung funktionieren würde, damit "kurze Störungen" nicht unnötig lange die Kommunikation stören; oder sprechen da technische Gründe dagegen?

...wieder einen Wert, der deutlich vom Durchschnitt der letzten 20 Messungen abweicht, usf.

Hört sich sinnvoll an. Was passiert eigentlich, wenn während der Kontrollmessung das Band belegt ist? Wird dann unentwegt solange hintereinander gemessen, bis zufällig das Band mal nicht belegt war?

Viele Grüße,
-Florian

[alf29]

Moin,

Was hälst du davon, wenn man in zukünftigen Firmwareversionen den "Notangelwert" selbst festlegen kann? -88dB bei den alten Geräten und -95dB bei der neuen Generation sollten i.d.R. ein guter Startwert sein

Ich glaube, das bekommt man dem Anwender nicht erklärt. Ich denke, das läuft auf einen fixen,
chipsatzabhängigen Wert hinaus.

Wäre schön, wenn das auch in die andere Richtung funktionieren würde, damit "kurze Störungen" nicht unnötig lange die Kommunikation stören; oder sprechen da technische Gründe dagegen?

Bisher gab's da eigentlich keine Notwendigkeit in der Praxis dafür...

Hört sich sinnvoll an. Was passiert eigentlich, wenn während der Kontrollmessung das Band belegt ist? Wird dann unentwegt solange hintereinander gemessen, bis zufällig das Band mal nicht belegt war?

Nach welchen Regeln die Hardware die Messung abbricht, gehört leider zu den nicht dokumentierten
Dingen...

Gruß Alfred