Diskussion:Paketumlaufzeit

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 9. März 2018 um 17:26 Uhr durch imported>Zac67(126937) (→‎RTT vs. Ping).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

aus der QS vom 13.12.05

Ich versteh gar nix? Pakete die rumreisen? In Computern? --Kenwilliams QS - Mach mit! 03:18, 13. Dez 2005 (CET)

Naja, innerhalb von Computern schon, z.B. bei der Busarbitration bei irgendwelchen Mehrprozessor-Systemen... für gewöhnlich ist es jedoch das, was die gemeinen Online-Gamer ansprechen, wenn sie sagen "Meine Pingzeit ist zu hoch" und die Provider bewirbt, wenn es heisst "Jetzt Fastpath sichern für nur 0,99FRZ/Monat". Sprich: Es geht um die Datenpakete, die z.B. von Deinem Browser zum Wikipedia-Server geschaufelt werden und die der Server Dir dann zurückliefert... hoffentlich.... wenn nicht -weil mal wieder timeout/Überlast- fragt der TCP/IP-Stack Deines Rechners ab und an mal nach, wo denn die Päckchen bleiben. Und um zu wissen, wann es überhaupt sinnvoll ist, "mal nachzufragen", lernt der TCP/IP-Stack Deines Rechners, wie schnell Deine Internetanbindung ist. (Bei einem DSL-Zugang lohnt sich das Nachfragen nach 0,5s, bei einem 14k4er-Modem kann man auch erneut anfordern, wenn aber die erste Lieferung noch auf dem Weg ist, dann bekommt man die gleiche Bestellung zweimal geliefert, was die Verbindung dann noch langsamer erscheinen läßt, denn "auf dem Browser angezeigt" wird natürlich nur der Erstankömmling.)
Lange Rede, gar kein Sinn: Der Artikel ist in meinen Augen brauchbar. --jha 03:54, 13. Dez 2005 (CET)
OK - dann bin ich nur zu blöd -ich kapiere nämlich auch nichts von dem, was du sagst. Aber das ist OK, liegt an mir... ;) Kenwilliams QS - Mach mit! 03:59, 13. Dez 2005 (CET)
Nimm einen (Basket)ball, wirf ihn gegen die Wand und fang ihn wieder. Die Zeit vom Abwurf bis zum wieder fangen ist halt die Roundtrip Time :-)--Wiggum 11:22, 13. Dez 2005 (CET)
  • also ich find den garnicht erledigt. Ich bin mir bewusst was die RTT ist. Verlinkung und Erläuterung zu Ping (Datenübertragung) wäre gut. Ausserdem muss der Artiekl überarbeitet werden, da er nicht wirklich verständlich ist. --FabianLange 12:37, 13. Dez 2005 (CET)

Lemmaüberschneidung

Die RTT wird nicht ausschließlich in TCP/IP-Netzen bestimmt, sondern auch bei X25/X75-Netzen, ebenfalls auf Ethernets etc.pp... Eine Zusammenlegung mit dem Ping-Artikel wäre problematisch. Ping müsste dann hier hinein, nicht umgekehrt. --jha 23:32, 24. Dez 2005 (CET)

Es muss ja nicht unbedingt eine Zusammenlegung erfolgen. Eine Abgrenzung würde mir auch reichen. --Flominator 12:27, 26. Dez 2005 (CET)

aus Wikipedia:Artikel zum gleichen Thema

Ich bin mir aber nicht sicher, ob es da einen Unterschied gibt. --Flominator 14:58, 24. Dez 2005 (CET)
Dann wärs schön, wenn du erst fragen würdest. :)
Die meisten Ping-Implementierungen melden unter anderm die RTT - die RTT hat aber nichts mit Ping per se zu tun, die kannst du auch mit anderen Paketen und Protokollen messen. Ping=ein Programm, RTT: ein Akronym für eine im Netzwerkbereich häufig verwendete Kenngröße. Beide Artikel haben ihre Berechtigung. Zum Messen der rtt mit TCP-Paketen siehe z.B. http://serversniff.de/ipinfo.php. Thomas Springer 16:17, 24. Dez 2005 (CET)
Kannst du das eventuell in die jeweiligen Artikel reinschreiben, wenn noch nicht geschehen? --Flominator 17:05, 24. Dez 2005 (CET)
Nachtrag: Siehe auch Diskussion:Round Trip Time --Flominator 12:29, 26. Dez 2005 (CET)
Ping ist eine Implementierung eines Tests zur Prüfung der RTT. Zwei Artikel m. E. durchaus gerechtfertigt. Stern 00:33, 6. Jan 2006 (CET)
Beide Artikel bleiben, Baustein entfernt. --Krille 11:28, 9. Jan 2006 (CET)
Daran habe ich ja gar nicht gezweifelt, aber abgerenzt sollten sie trotzdem werden! --Flominator 19:45, 11. Jan 2006 (CET)
Es gibt hier wirklich nichts abzugrenzen, weil die beiden Artikel gar nicht viel miteinander zu tun haben. Thomas Springer hat das oben schön erklärt. Es ist ja auch nicht so, dass Ping hauptsächlich ein Programm zu Messung der RTT wäre: Ping testet Netzwerkverbindungen bzw. das Routing im Netzwerk und gibt den Status meist in Form von ICMP-Fehlermeldungen, Paketverlustquoten, Sequenznummern, Informationen über Paketgrössen/Fragmentierung, Time-to-live und u.a. auch der Round-Trip-Time aus (die genauen Informationen hängen vom verwendeten Ping-Programm bzw. Betriebssystem ab). Wer die RTT sinnvoll messen will, darf gar nicht ping verwenden, da ICMP in manchen Netzwerken anders priorisiert wird als der Datenverkehr. – Du versuchst hier, ein nicht existierendes Problem lösen zu lassen und da niemand dein Problem sieht, gibt es auch keine Lösung. -- Stefan506 20:20, 11. Jan 2006 (CET)
wir lassen den baustein einfach drin. Der RTT-Artikel wird in ferner zunkunft länger und alles wird gut. serversniff.de misst übrigens tcp- wie auch icmp-rtts (und zeigt die ttls an. ich setz das mal als weblink nach rtt. Thomas Springer 11:39, 13. Jan 2006 (CET)
Ein halbes Jahr später sollte es allmählich reichen, Artikel IMHO ausreichend abgegrenzt, uA durch einen Absatz in RTT. Bausteine entfernt. --Cjesch 13:59, 15. Jun 2006 (CEST)

RTT abhängig von Paketgröße

Man sollte vielleicht erwähnen, dass die RTT abhängig ist von der Paketgröße, oder ? Sprich als Qualitätsmerkmal reicht es doch nicht aus zu sagen: Mindestens eine RTT von beispielsweise 10ms zu Host A. Man muss zusätzlich die Paketgröße angeben (zB bei 1Byte). Ist das richtig oder werfe ich da was durcheinander ?

Jein - nachdem die meisten Pakete ab etwa 2000 byte sowieso fragmentiert werden, hat die paketgroesse meines erachtens keinen einfluss auf die RTT. Ich setz die tage mal ein webinterface auf, um diese behauptung zu bestätigen. Thomas Springer
Doch. Das merkt ein DSL-Surfer wahrscheinlich nicth aber Menschen, die mit Holzmodem unterwegs sind, messen bestimmt einen Unterschied zwischen einen 50 Byte und einem 1500 Byte grossem Paket, da dieses seriell übertragen wird. Allerdings ist das alles von der eingesetzten Technik abhängig. --85.183.97.9 20:53, 10. Nov. 2009 (CET)

Informationen zu Ping sind falsch

Ping testet Wege im Netz bzw. das Routing im Netz und gibt den Status meist in Form von ICMP-Fehlermeldungen, Paketverlustquoten, Sequenznummern, Informationen über Paketgrößen/Fragmentierung, Time-to-live und u. a. auch der Round-Trip-Time (Rundreisezeit) aus (die genauen Informationen hängen vom verwendeten Ping-Programm bzw. Betriebssystem ab). Das ist leider falsch. Ping testet lediglich, ob ein Rechner im Netz erreichbar ist und gibt neben der Erreichbarkeit zusätzliche Informationen aus. Wege im Netz und Routing werden definitiv nicht überprüft. Weitere Informationen finden sich im Artikel zu Ping (http://de.wikipedia.org/wiki/Ping_%28Daten%C3%BCbertragung%29). Wieso wurde eine korrekte Anpassung (Version vom 8. Januar 2014, 13:24 Uhr) wieder rückgängig gemacht?--2003:66:881e:d00:4918:c32b:28f6:f010 18:59, 23. Jan. 2015‎ (CET)

RTT vs. Ping

Wer die RTT sinnvoll messen will, sollte sich nicht auf Ping alleine verlassen, da das von Ping verwendete ICMP-Protokoll in vielen Netzen gegenüber dem üblichen TCP-Datenverkehr anders geroutet oder priorisiert wird. Das stimmt auch nicht. Protokolle können nicht geroutet oder priorisiert werden, Pakete hingegen schon. Vorschlag: ...da die von Ping verwendeten ICMP-Pakete eine andere Priorität haben können als z. B. RTP-Pakete für Multimediadaten.--217.88.134.188 19:18, 23. Jan. 2015 (CET)

Das ist Haarspalterei. Policy-based Routing kann natürlich verschiedene Protokolle auf verschiedene Weisen routen. Tatsache ist, dass (Pakete, die) ICMP-Nachrichten (enthalten,) auf vielen Geräten mit geringerer Priorität oder gar nicht weitergeleitet werde. ICMP ist damit wenig zuverlässig, auch wenn es meistens funktioniert. Übrigens haben nicht die ICMP-Pakete eine geringe Priorität (diffserv) sondern viele Router transportieren sie einfach mit geringer Priorität. DSCPs werden im Internet allgemein einfach ignoriert. --Zac67 (Diskussion) 18:26, 9. Mär. 2018 (CET)

Neuer Wifi-Standard WIFI RTT für Indoorlokalisierung

Der Aspekt der Lokalisierung wird hier komplett vergessen, siehe auch https://stadt-bremerhaven.de/android-p-bessere-indoor-navigation-dank-wifi-rtt-support/