Ich arbeite an einem BDE-System (Online-Datenerfassung) für eine
Druckerei - d.h. an jeder Maschine befindet sich ein Touchscreen mit
integriertem PC zur Zeit- und Leistungserfassung und zur Anzeige der
Auftragsdaten. Aus Kostengründen bestand der Auftraggeber auf WLAN statt
dem guten alten Netzwerkkabel - und das in einer industriell
"verseuchten" Umgebung mit viel Metall, starken Motoren usw.
Überraschenderweise funktioniert das sogar beim größten Teil der
Terminals einigermaßen, aber es gibt Geräte, teilweise in unmittelbarer
Nähe eines AP, die immer mal wieder die Verbindung verlieren. Alle
Mini-PC sind baugleich und haben den selben WLAN-Adapter. DIe
Datenmengen sind übrigens minimal, grob vereinfacht: ca. alle 2...5
Minuten 1..2 kB (UDP mit Handshake).
Noch gibt es nicht wirklich Streit, aber ich spühre schon
unterschwellig, dass jeder Systemausfall die Stimmung verschlechtert. Es
handelt sich fast immer um Geräte an der selben Position. Die sind auch
nicht frei beweglich, denn die sind zum größten Teil fest oder mit
Gelenkarmen an den Maschinen an ergonomisch gut erreichbaren Positionen
verschraubt. Externe Antennen wären in den Problemfällen möglich, habe
ich schon merhmals angeregt, wurde aber nocht nicht gemacht.
Zur Dokumentation habe ich nun ein Tool in Betrieb genommen, dass
regelmäßig alle Terminals anpingt und dieses protokolliert. Leider
scheinen die Laufzeiten nur in sehr ungenügendem Maße die Leistung der
Netzwerkverbindung wiederzuspiegeln, die Abweichungen (meist um die 5 ms
bei einem Mittelwert von 65 ms) liegen innerhalb der normalen Streuung.
Auffällig ist, dass das erste Ping-Paket nach einigen Minuten oft extrem
lage braucht (ca. das zehnfache), alle Folgepakete dann wieder bei 65 ms
liegen - so als ob sich da irgendwas "schlafen legt". Die Adapter in den
PCs sind aber so eingestellt, dass sie das (eigentlich) nicht tun
sollten.
Gibt es da noch andere Möglichkeiten, die Verbindungsqualität zu
ermitteln? SMPT auf die Accesspoints scheidet aus, weil ich darauf
keinen Zugriff habe. Lasttest mit Speedmessung wollte ich (noch) nicht
machen, um das System nicht zusätzlich zu belasten ... Danke für Tips.
Frank
Frank schrieb:> Gibt es da noch andere Möglichkeiten, die Verbindungsqualität zu> ermitteln?
meines wissen leider nicht. Aber ich würde lieber die Anwendung so
umbauen damit sie damit zurecht kommt. Da muss das Protokoll ebend so
gestaltet werden das recht hohe Timeouts und viele Wiederhohlen möglich
sind. Die Störung ist ja meinst nur Kurzzeitig.
Das Protokoll ist schon ziemlich aufwändig. Leider schützt das nicht
gegen die Dummheit der Bediener. Sobald ein Terminal mal einige Sekundne
zögert, sind die ziemlich schnell mit der Resettaste zu Gange und tönen
"Geht nich...". Auch macht die verbreitete Vermutung, es handle sich um
ein Überwachungsinstrument, viele der Leute nicht gerade wohlwollend
tolerant ...
Frank
Ich glaub was du suchts nennt sich OpenNMS.
Das ist ein System zur überwachung von Diensten.
Was für ein OS läuft denn auf den BDE Terminals.
Wenn man auf den Dingern SNMP freischaltet, bekommt man relativ viele
Infos heraus.
In so einer Umgebung ist es relativ schwierig ein funktionierendes WLAN
zu betreiben.
Mit OpenNMS hast du zumindestens die Möglichkeit für eine
Langzeitmessung.
Auf den Terminals läuft Windows XP Embedded SP2.
Bin gerade auf der Suche nach einem schlanken Command Line Tool oder
einem Declare-Beispiel zum API-Zugriff. Die Anwendung ist in Real Studio
(ähnlich VB) geschrieben - mit C hab' ich es leider nicht so.
API-Zugriff oder ein Shell-Kommando im Hintergrund sind dagegenn kein
Problem ...
Dann würde ich auf den Clients immer für eine gewisse Zeit die
Signalstärke messen und an eines der nächsten Datenpakete mit anhängen.
Die Datenmenge kann minimal sein, z.B. 60 Byte für eine Stunde (jedes
Byte enthält den Durchschnittswert für eine Minute, gemessen im
10-Sekunden-Takt) oder so ähnlich.
Frank
Frank schrieb:> Auffällig ist, dass das erste Ping-Paket nach einigen Minuten oft extrem> lage braucht (ca. das zehnfache), alle Folgepakete dann wieder bei 65 ms> liegen - so als ob sich da irgendwas "schlafen legt". Die Adapter in den> PCs sind aber so eingestellt, dass sie das (eigentlich) nicht tun> sollten.
Kann es sein, dass die Geräte vom AP selbst aus dem Netz geschmissen
werden? Hatte mal das gleiche Prolem, einfach jede Minute einen Ping
machen war dann die Lösung, die Ping-Zeit blieb dann schön konstant und
die Verbindung funktionierte ohne Unterbrechung. Sobald das Gerät
nämlich erstmal aus dem Netz ist, kann es nicht mehr von aussen
angesprochen werden, sondern muss selbst eine Verbindung initiieren, um
wieder reinzukommen. Und dafür braucht es eben die paar 100 ms.
MfG Mark
Die möglichen technischen Lösungen des Problemes ist schon klar. Selbst
kleine 3dB-Magentfuß-Antennen würden wohl in einigen Fällen schon besser
sein, als die Gummi-Stummel direkt an den PCs.
Im Moment geht es erstmal um die Argumentation, um nicht gleich das böse
Wort "Schuld" in den Mund zu nehmen. Der Auftraggeber wollte WLAN um die
Kosten fürs Kabellegen zu sparen, nun zickt er 'rum, weil es nicht
richtig funktioniert und sucht bei mir ... also brauche ich Beweise.
Habe da übrigens etwas gefunden, funktioniert per "WMI", sogar
Programmbeispiele in VB, VBS und RealBasic. Jetzt hoffe ich bloß, dass
die erforderlichen System-Komponenten auch in dem Embedded XP drin sind
... dann baue ich das in die Client-Software ein und habe fortan ein
Messnetz mit 25 Stationen und die Ergebnisse wunderschön in einer
SQL-Tabelle :-)
Frank
Mork schrieb:> Kann es sein, dass die Geräte vom AP selbst aus dem Netz geschmissen> werden? Hatte mal das gleiche Prolem, einfach jede Minute einen Ping> machen war dann die Lösung, die Ping-Zeit blieb dann schön konstant und> die Verbindung funktionierte ohne Unterbrechung. Sobald das Gerät> nämlich erstmal aus dem Netz ist, kann es nicht mehr von aussen> angesprochen werden, sondern muss selbst eine Verbindung initiieren, um> wieder reinzukommen. Und dafür braucht es eben die paar 100 ms.
Das ist ein interessannter Gedanke! Eine Ping-Klasse hab' ich schon
drin, bisher aber nur im Falle eines kompletten Verbindungsausfalles
benutzt, um festzustellen, wann der Server wieder da ist. Als keep-alive
bisher noch nicht ... probier' ich mal! Danke.
Frank
Frank schrieb:> Habe da übrigens etwas gefunden, funktioniert per "WMI", sogar> Programmbeispiele in VB, VBS und RealBasic. Jetzt hoffe ich bloß, dass> die erforderlichen System-Komponenten auch in dem Embedded XP drin sind
War leider nix, auf den Clients ist WMI nicht installiert ... :-((
Sch...
Frank
Frank schrieb:> Zur Dokumentation habe ich nun ein Tool in Betrieb genommen, dass> regelmäßig alle Terminals anpingt und dieses protokolliert. Leider> scheinen die Laufzeiten nur in sehr ungenügendem Maße die Leistung der> Netzwerkverbindung wiederzuspiegeln, die Abweichungen (meist um die 5 ms> bei einem Mittelwert von 65 ms) liegen innerhalb der normalen Streuung.> Auffällig ist, dass das erste Ping-Paket nach einigen Minuten oft extrem> lage braucht (ca. das zehnfache), alle Folgepakete dann wieder bei 65 ms> liegen - so als ob sich da irgendwas "schlafen legt". Die Adapter in den> PCs sind aber so eingestellt, dass sie das (eigentlich) nicht tun> sollten.
wenn das erste paket länger braucht dann muss vermutlich erst der arp
eintrag aktualisiert werden, kann man mit 'arp -a' überprüfen.
generell zur dokumentation:
wie gross sind die pakete die beim doku-ping verwendet werden und wie
gross sind die udp frames? ein typisches windows-ping-paket ist nur was
um die 32 byte und hat damit eine viel höhere chance als ein 1500byte
grosses udp paket ohne kaputt zu gehen an der gegenstelle anzukommen.
entweder es werden die doku-ping pakete vergrössert oder die udp pakete
werden verkleinert (rts/frag einstellungen oder mtu des interfaces)
Danke, neuer und guter Gedanke. Die UDP-Pakete habe ich auf 1450
begrenzt. Die Ping-Pakete sind "natürlich" nur 32 Byte - kann man die
1450 groß machen?
Als Anwendungsentwickler, mit eher Bezug zu technischen und ökonomischen
Prozessen, musste ich bisher nie so "tief" hinabsteigen ...
Den WMI-Dienst musste ich übrigens nur starten ... werd also nun
Empfangsfeldstärke UND Ping-Laufzeiten dokumentieren.
Frank
Ansosnten eventuell ein zusätzlicher WLAN AP der per Kabel an dem PC
dranhängt etwas weiter entfernt von der "Störquelle"?
Und wenn der Kunde nichtmal ne vernünftige Antenne einsetzen will ist
das eigentlich schon wieder selbst Schuld.
Ansosnten
> eventuell ein zusätzlicher WLAN AP der per Kabel an dem PC dranhängt> etwas weiter entfernt von der "Störquelle"?
So in etwa würde ich das auch probieren.
Einen der störanfälligen AP per wild verlegtem Kabel vom WLAN nehmen.
Und wenn dieser dann auf wundersame Weise die nächsten 2 Monate keine
einzige Störung mehr hat, müsste auch der unkundigste Kunde zu denken
anfangen, dass er sich mit dem beharren auf WLAN ein Eigentor geschossen
hat.
Frank schrieb:> - kann man die 1450 groß machen?
klar:
ping -l 1450 127.0.0.1
> Als Anwendungsentwickler, mit eher Bezug zu technischen und ökonomischen> Prozessen, musste ich bisher nie so "tief" hinabsteigen ...
wlan in so einer umgebung ist einfach mist - dabei meinte ich weniger
die maschienen die dort stehen sondern die anforderung das es "immer"
funktionieren muss. im 2.4ghz band (ISM) wird praktisch alles
übertragen: wlan, babyfone, drathlos kamera und selbst eine mikrowelle
kann den empfang empfindlich stören. die funker sagen immer: 'wer funk
kennt nimmt kabel' - wie recht sie haben... vielleicht lässt sich der
auftraggeber dazu überreden wenigstens die stationen die bauchschmerzen
machen per ethernet anzubinden, für dich sollte das ja keinen
unterschied machen. alternativ muss du die daten solange auf den
terminals halten bis es wieder verbindung zum server gibt.
