ping(8)-Zeiten im WLAN und im Ethernet im Vergleich

Herakles

Herakles

Profifragensteller
Moin!

Klemme ich meinen Rechner an ein Ethernet-Netzwerk und schicke ping(8)s ab, so bekomme ich Antwortzeiten von etwa 0.150ms bis 0.650ms.

Spiele ich das gleiche im WLAN durch, bekomme ich Antwortzeiten von etwa 1.000ms bis 1.800ms (wenn durch Übertragungsfehler keine großen Ausbrüche zu verzeichnen sind.)

Weiß jemand, wieso diese Zeiten im WLAN derart vervielfacht sind? Die Lichtgeschwindigkeit ist laut meinen Informationen im Kabel wie in der Luft die gleiche :D

Danke, Herakles
 
In einem Störungsfreien WLAN würde ich einen Aufschlag von ca. 2ms erwarten. Ich würde mal sagen du solltest dir einen freien Kanal suchen, der wird unter Garantie schon von anderen verwendet.
 
Ja, der Kanal ist störungsfrei. Aber selbst in einem störungsfreien WLAN sagst Du, würdest Du 2ms Aufschlag erwarten.

Wieso würdest Du diese 2ms erwarten? Genau DAS war doch meine eigentlich Frage... ;-)

Herakles
 
Persönliche Erfahrung.

Außerdem ist es allgemein bekannt, dass WLAN erheblichen Overhead produziert. Das Gerät muss prüfen ob der Kanal frei ist, Pakete verschicken, pausieren, damit andere den Kanal frei machen, ACKs zurückschicken...

Der Overhead liegt wahrscheinlich über 50%.

Irgendwie habe ich 1.8s gelesen. Deswegen dachte ich der Kanal sei belegt.
 
Ping über WLAN zum Access Point:
PING ap.bsdbox.de (192.168.1.50): 56 data bytes
64 bytes from 192.168.1.50: icmp_seq=0 ttl=255 time=1.382 ms
64 bytes from 192.168.1.50: icmp_seq=1 ttl=255 time=1.407 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=255 time=1.219 ms

Ping über LAN zum Access Point:
PING ap.bsdbox.de (192.168.1.50): 56 data bytes
64 bytes from 192.168.1.50: icmp_seq=0 ttl=255 time=0.558 ms
64 bytes from 192.168.1.50: icmp_seq=1 ttl=255 time=0.558 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=255 time=0.575 ms

Beim WLAN ist WPA aktiviert, und WLAN hat einen beträchtlichen Overhead. Daher auch die wesentlich geringere Datendurchsatzrate in Relation zu einer equvalenten LAN Verbindung.
 
Außerdem ist es allgemein bekannt, dass WLAN erheblichen Overhead produziert. Das Gerät muss prüfen ob der Kanal frei ist, Pakete verschicken, pausieren, damit andere den Kanal frei machen, ACKs zurückschicken...
Zum Vergrößern anklicken....
Und bei Ethernet muss nicht geprüft werden, ob die Leitung frei ist oder der Host muss pausieren?
Der Overhead liegt wahrscheinlich über 50%.
Zum Vergrößern anklicken....
Wo steht denn das? Ich kenne es zwar auch, das Wlan langsamer ist, aber solche Zahlen hab ich noch nie gesehen.
 
Im LAN verbindet ein Kabel immer genau 2 Stationen. Full Duplex sei dank kann gleichzeitig gesendet und empfangen werden. WLAN ist quasi wie BNC, alle müssen sich die Bandbreite teilen, zusätzlich gibt es keine Schirmung.

Das mit dem 50% Overhead ist eine Schätzung auf Erfahrungswerten basierend.
 
Im LAN verbindet ein Kabel immer genau 2 Stationen.
Zum Vergrößern anklicken....
Und was ist bei einer Sterntopologie um nen Hub drumrum? Ich glaube schon, dass man da das gleiche Problem hat. Und wie kommst du zu deiner Schätzung? Das muss ja irgendeine Basis haben.
 
menace schrieb:
Und was ist bei einer Sterntopologie um nen Hub drumrum? Ich glaube schon, dass man da das gleiche Problem hat. Und wie kommst du zu deiner Schätzung? Das muss ja irgendeine Basis haben.
Zum Vergrößern anklicken....

1. Wlan erzeugt durch verschiedene dinge Overhead Wie z.B. die verschlüsselung, zusätzliche abfragen an den Accesspoint und von diesem e.t.c.

2. Es wurde EXPLIZIT von einem "modernen", geswitchten Netz gesprochen, und es wurde ebenfalls EXPLIZIT Wlan mit einem veraltetem, 10baseT netz verglichen ... ich weis also nicht, was du sagen wolltest ...
 
menace schrieb:
Und was ist bei einer Sterntopologie um nen Hub drumrum? Ich glaube schon, dass man da das gleiche Problem hat. Und wie kommst du zu deiner Schätzung? Das muss ja irgendeine Basis haben.
Zum Vergrößern anklicken....
Der Hub ist eine Station und der Rechner der daran hängt ist auch eine. Es bleibt also dabei nur 2 Sender und Empfänger, die gleichzeitig senden und Empfangen könne.

Ein Switch verbessert die Situation noch weiter (und es gibt wirklich keinen Grund einen HUB zu verwenden) in dem er sich merkt an welchem Port welches Gerät zu erreichen ist, so findet also nur notwendiger Verkehr statt.
 
Im LAN verbindet ein Kabel immer genau 2 Stationen.
Zum Vergrößern anklicken....

Und was ist bei einer Sterntopologie um nen Hub drumrum?
Zum Vergrößern anklicken....

Da auch. ;)

Sorry, da hab ich grad kurz gedacht ich wär im Fun-Bereich gelandet.
So ein Netzwerkkabel hat immer nur 2 Enden. Na gut, zur Not crimpe ich dir auch eins mit 16 RJ45 Steckern, aber normen kann ich dir das nicht. :D

(Sorry menace, ich wusste zwar was du meinst, aber lustig hörte sichs trotzdem an)

Edit:
Vieleicht hilft das hier:
http://www.net.in.tum.de/teaching/W...WLan-Bridges--PraktikumBerichtAntwortzeit.pdf
 
Zuletzt bearbeitet:
1. Wlan erzeugt durch verschiedene dinge Overhead Wie z.B. die verschlüsselung, zusätzliche abfragen an den Accesspoint und von diesem e.t.c.
Zum Vergrößern anklicken....
Verschlüsselung erzeugt keine 50% Overhead. Und was für "zusätzliche" Anfragen?
Es wurde EXPLIZIT von einem "modernen", geswitchten Netz gesprochen, und es wurde ebenfalls EXPLIZIT Wlan mit einem veraltetem, 10baseT netz verglichen ... ich weis also nicht, was du sagen wolltest ...
Zum Vergrößern anklicken....
Wo wurde denn hier von einem geswitchten Netz gesprochen?

Da auch.

Sorry, da hab ich grad kurz gedacht ich wär im Fun-Bereich gelandet.
So ein Netzwerkkabel hat immer nur 2 Enden. Na gut, zur Not crimpe ich dir auch eins mit 16 RJ45 Steckern, aber normen kann ich dir das nicht.
Zum Vergrößern anklicken....
Worum es mir geht, dass in einem (nicht-geswitchten) netzwerk, wo alle am Hub haengen, auch erst geschaut werden muss, ob einer schon sendet oder nicht. Also muessen die endpunkte auch evtl pausieren.

Ich kenn die groessere Latenz auch bei WLan, aber ich kenne leider (noch?) keine Begründung, die Punkte die hier gerade genannt wurden, sind jedenfalls nicht stichhaltig, oder ich hab ein Brett vorm Kopf. Im geposteten Link steht übrigens auch keine Begründung, soweit ich das gesehen habe.


Ich freu mich zwar, dass dich das erfreut, aber die Frage, warum das so ist, löst das auch nicht
Zum Vergrößern anklicken....
 
menace schrieb:
Ich kenn die groessere Latenz auch bei WLan, aber ich kenne leider (noch?) keine Begründung, die Punkte die hier gerade genannt wurden, sind jedenfalls nicht stichhaltig, oder ich hab ein Brett vorm Kopf.
Zum Vergrößern anklicken....
Ja dann hast do wohl leider ein Brett vorm Kopf. Es ist vollkommen egal ob HUB oder Switch. Bei einem Switch hast du weniger unnötigen Traffic, aber bei TCP bist du schon auf einer viel zu hohen Protokollebene. Im LAN hast du einen sehr geringen Overhead, weil immer nur 2 Stationen miteinander verbunden sind, hier geht es darum wie viele Stationen sich ein Kabel teilen, das hat nichts mit der Herkunft der Pakete zu tun.

Jedenfalls sind Kabel geschirmt und erlauben Full Duplex, eine Prüfung ob Pakete unbeschädigt angekommen sind ist gar nicht notwendig. Das findet erst auf der TCP Ebene statt.

Im WLAN ist die Luft das Trägermedium. Das heißt es gibt keinen Schutz gegen Störungen, alle Stationen müssen sich das eine Medium teilen. Deswegen muss ein TCP Paket in kleine Teile zerlegt werden. Vor dem Senden muss eine Station feststellen ob das Medium frei ist, dann wird erst ein Teil des Pakets gesendet und ein ACK verlangt. Dann wird das Senden unterbrochen um auf das ACK zu warten und um anderen Stationen die Chance zu geben auch was zu senden. Dann muss das ganze noch ein paar mal wiederholt werden, bis das ganze Paket angekommen ist.

Über Kabel kannst du einfach losschicken und dich darauf verlassen, das dir jemand zuhört und es keine Störungen gibt.
 
zu 50%:
1. zum einen ist Kabel wie schon erwähnt full-duplex, WLAN muß sich das teilen für senden und empfangen.
2. Fehlerhäufigkeit: Soviel ich weiß (hab gegoogelt, laut http://www.rrzn.uni-hannover.de/fil...rnetze_1/ws_0607/Rechnernetze_I_11_WS0607.pdf, du willst ja sicher einen Link für meine Behauptung) stimmt das ungefähr,
hat man im Netz 10^-9, in Luft 10^-4 als Fehlerhäufigkeit.
D.h. im Kabel ist jedes milliardste Bit kaputt, in der Luftübertragung jedes tausendste. Bei einem TCP/IP-Paket (MTU 1500 Byte) über Luft also 1,5*8=12 Fehler/Paket. (Kabel nur ca. jedes tausendste Paket hat einen Fehler!)
Deswegen hat TCP/IP ja auch eine Prüfsumme, damit das Paket neu geschickt wird, wenn die nicht stimmt. Über Luft hiese das aber, das fast nie ein Paket korrekt ankommt (ok, Fehler meistens als Bursts, aber das geht hier jetzt zuweit).
Also hätte man über WLAN folgende Strategien (kenne WLAN-Protokoll nicht, nur Mutmaßungen):
1. TCP/IP-Pakete runterbrechen => viel neuer Paketheader-overhead
2. WLAN Pakete sind kleiner => siehe 1.
3. Error-Correction-Mechanismen in den WLAN-Paketen (Hamming wird nicht ausreichen) => Overhead durch Error-Correction Informationen

Edit: Mist, zu spät, Kamikaze war schneller!
 
Es ist vollkommen egal ob HUB oder Switch
Zum Vergrößern anklicken....

Das kann man so nich stehn lassen.

Hub => Ethernet=> CSMA/CD
Switch => Full Duplex Ethernet => keine Kollisionskontrolle

Ein Hub verhält sich also doch einem WLAN sehr ähnlich.
 
manga: ja, das meinte ich auch (und stimmt ja auch), aber an was ich nicht dachte, war, weil die pakete bei wlan ueber die luft uebertragen werden, muss da noch eine extra Fehlerkontrolle und -korrektur rein, wo durch das ganze langsamer wird.
 
was auch noch bei WLAN zu beachten ist: der Kram wird (hoffentlich) verschlüsselt, das kostet auch Zeit
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben