Wenn ich bei einer Client-Server-Architektur in einem fremden (Firmen-) Netz immer wieder Schwierigkeiten habe, der Admin mir aber immer nur mit den hervorragenden Ping-Zeiten kontert - was kann ich tun? Wie aussagefähig sind Ping-Werte (Verlustquote und Laufzeit) für die Qualität einer auf UDP beruhenden Kommunikation? Hinzu kommt, dass es sich um ein WLAN handelt (nicht meine Idee!). Die UDP-Datagramme sind rel. klein 300 ... 800 Bytes), also eigentlich auch kein Problem mit Fragmentierung. Einzelne Terminals haben eine so miese Verbindung, dass selbst VNC (macht TCP) zur Wartung aller par Mausklicks einfriert - ABER: hervorragende Pings. Wie geht das?
>Wie aussagefähig sind Ping-Werte
Was die Laufzeiten angeht, recht aussagekräftig. Wenn du Qualität prüfen
möchtest, kann ich dir JPerf empfehlen (Server-Client Test). Sonst,
finde ich dir sagen, dass 300 - 800 Byte Pakete nicht optimal sind, da
immer Overhead gesendet wird. Außerdem wenn du schnell hintereinander 2
UDP Pakete
versendet, kann B vor A ankommen.
Frank Esselbach schrieb: > Wie aussagefähig sind Ping-Werte (Verlustquote und Laufzeit) für die > Qualität einer auf UDP beruhenden Kommunikation? Ach ja, dein UDP wieder ... Laufzeit spielt zumindest bei TCP keine übermäßige Rolle, Verlustrate schon. Normale TCP-Verbindungen werden bei einigen Prozent Paketverlusten etwas langsamer, ab etwa 20 % "geht nichts mehr". Es kann natürlich verschiedenerlei Gründe geben, warum die ICMP Echo-Pakete besser "durchkommen" als deine UDP-Sachen. Ein erster Punkt wäre die Paketgröße: man sollte die ICMP Echos schon mal mindestens so groß machen, wie deine realen Datenpakete sind. Sind noch irgendwelche aktiven Netzwerkkomponenten im Spiel (bei WiFi ja praktisch immer der Fall), dann könnte das auch noch sein, dass diese aus irgendeinem Grund (Architektur, in der man auch einen Firewall installieren können will) ICMP und TCP/UDP getrennt behandeln. Man könnte als Alternative versuchen, ein Ping auf UDP aufzubauen. Das braucht natürlich einen UDP-Server am anderen Ende, der alles wieder echot, aber das sollte ja nicht so schwer sein.
Hi, also wenn du mich fragst sagt das nichts aus. Wenn du eine vernüftige Antwort über die Belastbarkeit des Netzwerkes haben möchtest dann sag dem Admin der soll mal mit Jperf ne analyse machen was das netzwerk wirklich kann der Aufwand dafür ist recht gering . (http://openmaniak.com/iperf.php#jperf) Zusätzlich verhält es sich mit den Pings so, dass ein relativ großes delay zwischen den einzelnen anfragen liegt, und somit das netzt nicht wirklich belastet. Wie hoch ist denn die Durchscnittliche Datenrate ? W-Lan liefert bei weitem nicht deas was auf der Packung steht vor allem wenn mehrere PC^s dran hängen ! Gruß Lutz
Hallo Frank, ein guter Ping heißt meines Erachtens nicht, dass das Netz i.O. ist. - In einem Lan sollte es praktisch keine Paketverluste geben (bzw. <<1% sein) Wenn regelmäßig Pakete verliren gehen, ist hier schon mal was faul - Manche Router machen QOS und priorisieren ICMP/kleine Pakete, was zu einer verbesserten PING-Anzeige führt - Wer WLAN kennt, nimmt Kabel ;) Du kannst mal versuchen, größere Ping-Pakete zu senden (ping -l 32768 <ip>) oder ein Tool wie netio verwenden um die Bandbreite zu messen. Gruß Roland
Jörg Wunsch schrieb: > Ach ja, dein UDP wieder ... Da fällt mir noch ein: mach doch mal irgendeine Standard-TCP- Verbindung parallel auf und schau nach, wie diese beeinflusst wird. Könnte im einfachsten Fall eine Webseite sein, die alle paar Sekunden neu geladen wird.
Roland Praml schrieb: > Du kannst mal versuchen, größere Ping-Pakete zu senden (ping -l 32768 > <ip>) Werte größer als die MTU haben keinen wirklichen Sinn, außer dass die Fragmentierung des IP-Stacks damit getestet wird, die ansonsten eigentlich heutzutage niemand mehr benutzt. (IPv6 hat die Fragmente ersatzlos gestrichen.)
Normales Ping taugt weniger für einen kurzfristigen Netztest. Besser geeignet ist da schon Flood-Ping, ohne Wartezeit zwischen den Pings. Verfügbar unter unixoiden Betriebssystemen als "ping -f". Gibt einen ganz guten Indikator für die Verlustrate ab, auch intermittierende Verzögerungen werden gut sichtbar. Aber mach das nur in einem Netz in dem du Admin bist oder es abgesprochen hast, könnte sonst andere Leute nerven. Besonders bei grösseren Frames.
1.Ein einfaches ping ist nur ein grober Test mit 4 Paketen. Versuch mal ping -t -l 4444 Dann sind die Pakete länger und schneller kaputt. Somit Verluste offensichtlicher. 2.Der WLAN-Empfang ist nicht überall gleich gut. Sobald der Kanal gestört wird, gehen Pakete verloren. UDP ist ein verbindungsloses Protokoll. Das merkt den Verlust nicht. Dafür ist dann die Anwendung zuständig. http://de.wikipedia.org/wiki/User_Datagram_Protocol
oszi40 schrieb: > 1.Ein einfaches ping ist nur ein grober Test mit 4 Paketen. Nur bei einem einzigen Betriebssystemhersteller. ;-) Bei allen anderen läuft es, bis man es abbricht.
Jörg Wunsch schrieb: > Werte größer als die MTU haben keinen wirklichen Sinn, außer dass > die Fragmentierung des IP-Stacks damit getestet wird, die ansonsten > eigentlich heutzutage niemand mehr benutzt. (IPv6 hat die Fragmente > ersatzlos gestrichen.) Das ist zwar richtig, dennoch werden mehr Bytes übertragen, was die Wahrscheinlichkeit erhöht, dass ein Paket verloren geht. Insb. bei schlechten WLAN-Strecken habe ich beobachtet, dass kleine Pakete nahezu ohne Paketverlust durchkommen, größere aber nicht. Gruß Roland p.S. ich tippe auf das WLAN, scanne mal ob da noch andere Kanäle dazwischenfunken oder ob sogar ein 2,4GHz Videomodulator irgendwo rum steht.
Frank Esselbach schrieb: > Netz immer wieder Schwierigkeiten habe, der Admin mir aber > immer nur mit den hervorragenden Ping-Zeiten kontert Nutz' halt ICMP anstelle von UDP ;P Ansosnten wurde ja schon gesagt das das wenig aussagekräftig ist. Es kann z.B. auch sein das ICMP Pakete als "ungefährlich" von der FW durchgelassen werden UDP oder TCP hingegen geblockt oder gefiltert wird. Auch der umgekehrte Fall ist denkbar, ich meine das z.B. die WinXP Firewall Ping Pakete standardmäßig blockt.
Ich habe jetzt mal Experimente mit relativ großen Ping-Paketen gemacht (16000 u. 32000 Byte). Was mir eindeutig bei jedem Clienten auffiehl, war die Tatsache, dass IMMER die ersten 2..3 Pakete verloren gehen, alle Nachfolger dann aber ankommen. Nach geschätzten 2 Minuten Pause das Gleiche wieder. Nach nur einigen Sekunden Pause keine Verzögerung, kein Verlust. Kleine Ping-Pakete weren immer und sofort beantwortet. Die Verzögerung tritt nur bei großen auf. Sieht nach irgend einem "Einschlafeffekt" aus ... aber bei welcher Komponente? In den WLAN-Adaptern der Terminals (Netgear-PCI-Karte) ist die Funktion "Energiesparen" überall ausgeschaltet. Der Server hängt im Serverraum am Kabel, ist aber eine VM ... da gibt es die Energiesparfunktion für das Netzwerk nicht.
Frank Esselbach schrieb: > Wenn ich bei einer Client-Server-Architektur in einem _fremden_ > (Firmen-) Netz immer wieder Schwierigkeiten habe, der Admin mir aber > immer nur mit den hervorragenden Ping-Zeiten kontert - was kann ich tun? Kennst Du mtr? Das ist eine Kreuzung aus ping und traceroute. Schau Dir das mal an. Da siehst Du auch sehr schön Paketverluste. fchk
Frank Esselbach schrieb: > Ich habe jetzt mal Experimente mit relativ großen Ping-Paketen gemacht > (16000 u. 32000 Byte). Was mir eindeutig bei jedem Clienten auffiehl, > war die Tatsache, dass IMMER die ersten 2..3 Pakete verloren gehen, alle > Nachfolger dann aber ankommen. Jetzt geh' für einen Vergleich nochmal runter auf einen Wert, der kleiner als die MTU ist. Bei deinen übergroßen Paketen testest du vor allem die IP-Fragmentierung, die du aber ansonsten gar nicht brauchst. (Falls eins der Fragmente dieses "Monster-Pakets" nicht innerhalb der gewarteten Zeit reassemblierbar ist, dann wird das ganze Paket als Verlust verbucht.) > Sieht nach irgend einem "Einschlafeffekt" aus ... Oder eben nach state tables oder sowas, Dinge, die man vor allem dann implementiert, wenn man da drauf auch noch einen Firewall fahren können will. Sowas könnten die beteiligten WiFi-Router in ihrem System drin haben. Details kannst du aber auch hier — wie schon bei deinem originalen UDP-Problem — nur durch Werkzeuge wie wireshark auf beiden Seiten heraus finden.
Hallo, ich würde auch mtr in verbindung mit klassischem ping und hping einsetzen....sind halt klassische unix tools. ich denke ein paar daten damit sammeln und man kann gute aussagen über das netzwerk treffen. Vorallem bei größeren Netzen sollte man bei PING auch auf die TTL achten - diese sollte im normalfall konstant sein und nicht mal 252 und dann 80. Seltsame Performanceprobleme treten auch gerne bei Kombinationen von "Gigabit-Ethernet"-Karten an Fast-Ethernet-Switches auf - oft hat man hier die gleichen duplex und auto-speed probleme wie damals als Fastethernet kam. lg Mario
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.