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
Eventuell mit Richtantennen arbeiten, damit erhöht sich die Signalstärke und Strörungen die aus einer anderen Richtung kommen werden abgeschwächt.
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
1 | ping -l 2000 sendet Pakete mit 2000 bytes... |
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.
Läubi .. schrieb: >
1 | ping -l 2000 sendet Pakete mit 2000 bytes... |
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.