Ryzom

LAG entsteht häufig auf dem Weg der Pakete zu den Servern und nicht am Server selbst. Mit dem tracert-Befehl kann man aber sehr gut die Pakete verfolgen und sehen, wo das LAG wirklich herkommt.

Hier eine kurze Anleitung daqzu:

Start/Ausführen anwählen. Dort "cmd" eingeben und Return drücken. (Öffnet ein DOS-Fenster)
im DOS-Fenster gebt ihr ein: tracert 213.208.119.189

Das Ergebnis sieht dann so aus:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Dokumente und Einstellungen\xxxxx>tracert 213.208.119.189

Routenverfolgung zu ryzom.com [213.208.119.189] über maximal 30 Abschnitte:

1 13 ms 2 ms 2 ms . [xxx.xxx.xx.x]
2 53 ms 54 ms 54 ms xxx.x.xxx.xxx
3 63 ms 51 ms 53 ms 217.237.156.254
4 52 ms 51 ms 52 ms 62.154.32.85
5 69 ms 51 ms 51 ms 62.154.32.134
6 51 ms 52 ms 50 ms hbg-b2-pos0-3-1.telia.net [213.248.103.233]
7 67 ms 67 ms 67 ms hbg-bb1-pos0-1-0.telia.net [213.248.65.177]
8 68 ms 75 ms 69 ms adm-bb1-pos7-0-0.telia.net [213.248.65.153]
9 69 ms 67 ms 92 ms ldn-bb1-pos7-0-0.telia.net [213.248.65.149]
10 68 ms 67 ms 67 ms ldn-b1-pos3-0.telia.net [213.248.74.6]
11 68 ms 68 ms 67 ms nildram-104066-ldn-b1.c.telia.net [213.248.100.7
0]
12 69 ms 67 ms 68 ms lon1-11.nildram.net [195.149.20.137]
13 68 ms 67 ms 67 ms jolt-gw.nildram.net [195.149.20.214]
14 67 ms 101 ms 69 ms ryzom.com [213.208.119.189]

Ablaufverfolgung beendet.

Es werden immer 3 Zahlen gezeigt, die maximalen, minimalen und durchschnittlichen Zeiten. Hat man irgendwo * stehen statt Zahlen, ist das ein timeout. Je höher die Zahlen sind, desto schlechter die Verbindung. In meinem Beispiel hier ist es eine recht gute Verbindung.

Zusätzlich zum tracert Befehl gibt es eine kurze Variante, der Ping-Befehl. Dazu gebt ihr im DOS-Fenster ein: ping 213.208.119.189.

Das Ergebnis sieht dann so aus:

Ping wird ausgeführt für 213.208.119.189 mit 32 Bytes Daten:

Antwort von 213.208.119.189: Bytes=32 Zeit=93ms TTL=57
Antwort von 213.208.119.189: Bytes=32 Zeit=68ms TTL=57
Antwort von 213.208.119.189: Bytes=32 Zeit=67ms TTL=57
Antwort von 213.208.119.189: Bytes=32 Zeit=69ms TTL=57

Ping-Statistik für 213.208.119.189:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 67ms, Maximum = 93ms, Mittelwert = 74ms

Viele Grüße
Merrit

dann hab ich aber einen Ping von 36, nur im Spiel schwankt er immer zwischein 150~300 ?!

Entscheidend ist der Ping, den Du außerhalb des Spiels hast. Die Anzeige im Spiel erhebt keinen Anspruch auf Genauigkeit

Merrit

...und was kann ich jetzt bei einer schlechten Verbindung tun?

Ich meine, mit den Hilfen kann ich zwar eine Messung durchführen, aber das hilft mir bei meinem Problem im Spiel auch nicht weiter.

Ach ja:
Was zeigt denn der Ingame-Ping-Wert an? und wozu kann er genutzt werden, wenn er nicht entscheidend ist? Wofür ist er denn überhaupt gut (wenn er schon keine Aussagekraft besitzt)?

BTW:
Wie groß sind denn die Datenpakete, die über ryzom ausgetauscht werden? (nicht nur ingame, sondern auch bei Anmeldung, Gebietwechsel etc.)
Kann mann/frau das irgendwo nachlesen? (bin ja nur neugierig)

Hat man schlechte pings/tracerts hilft oftmals einfach neu ins Internet zu verbinden. Ansonsten ist es halt so, dass es zB Routingprobleme gibt, (Ausfall von Knoten etc.) und man schlechte Karten hat, bis die Telekom (oder wer auch immer) das Routing ändert oder den Schaden behebt.

Grüße
Merrit

Hi Homins!

Guter Post, Merrit!

Wer meint, wirklich Probleme mit seinem Provider zu haben, sollte auch mal einen Pathping ausführen (ab W2KSP2/XP), dieser analysiert die Knoten selbst, dauert abllerdings etwas länger zur Auswertung.
Mal ein Beispiel von mir:


Syntax: pathping <Adresse>:

Routenverfolgung zu 213.208.119.189 über maximal 30 Abschnitte

0 xxx [xxx.xx.x.xxx] Mein Rechner
1 xxx.xx.x.x Router
2 xxx.xxx.xx.xxx Firewall/Externer Anschluß
3 xxx-x.xx-xxxx-xx-xx.hh.hansenet.de [xxx.xxx.xx.xxx] "Eingang Provider"
4 xxx-x.xx-xxxx-xx-xx.lon.hansenet.de [xxx.xxx.xx.xxx] "Ausgang Provider"
5 lon1-10.nildram.net [217.79.160.15] "Landingzone" für Ryzom, der Provider
6 lon1-9.nildram.net [195.149.20.130]
7 jolt-gw.nildram.net [195.149.20.126]
8 213.208.119.189


Berechnung der Statistiken dauert ca. 200 Sekunden...

Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse

0 xxx [xxx.xx.x.xxx]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% xxx.xx.x.x
0/ 100 = 0% |
2 26ms 0/ 100 = 0% 0/ 100 = 0% xxx.xxx.xx.xxx
0/ 100 = 0% |
3 18ms 0/ 100 = 0% 0/ 100 = 0% xxx-x.xx-xxxx-xx-xx.hh.hansenet.de [xxx.xxx.xx.xxx]
0/ 100 = 0% |
4 38ms 0/ 100 = 0% 0/ 100 = 0% xxx-x.xx-xxxx-xx-xx.lon.hansenet.de [xxx.xxx.xx.xxx]
0/ 100 = 0% |
5 39ms 0/ 100 = 0% 0/ 100 = 0% lon1-10.nildram.net [217.79.160.15]
0/ 100 = 0% |
6 39ms 0/ 100 = 0% 0/ 100 = 0% lon1-9.nildram.net [195.149.20.130]
0/ 100 = 0% |
7 39ms 0/ 100 = 0% 0/ 100 = 0% jolt-gw.nildram.net [195.149.20.126]
1/ 100 = 1% |
8 39ms 1/ 100 = 1% 0/ 100 = 0% 213.208.119.189

Ablaufverfolgung beendet.

In diesem Beispiel habe ich doch tatsächlich ein Paket verloren , allerdings ist dieses bei jolt zwischen Schritt 7 und 8 verlustig gegangen .
Packetloss ist deutlich einflussnehmender auf eure Netzwerkperformance, als die reine Antwortzeit - immerhin muß dann das verlorene Paket neu angefragt werden und nimmt dann den gleichen Weg nochmal...
Problematisch wird's auch dann, wenn zuviele Schritte zwischen eurem Ausgang (Modem, Router, etc) und der ersten "Landingzone" der Ryzom Server (hier 5 lon1-10.nildram.net [217.79.160.15]) liegen, oder schon dort gar Paketverlust auftritt. Optimal sind, wie in diesem Beispiel , 2 Schritte mit max 40ms Gesamtverlust. Ansonsten hilft nur noch eine (wenig erfolgversprechende) Beschwerde beim Provider. Dies hatte ich auch Anfang des Jahres und endete in einem langwierigen Providerwechsel und in Zwangsverzicht auf die ersten OpenBetas - jetzt kann ich wieder ...
Im DSL-Betrieb kann es auch zu Performance-Steigerungen führen, wenn ihr die MTU ändert, oder, wenn Merrit noch die MTU der Server bekanntgibt, diese an die Server anzugleichen (wenn euer Provider oder Jolt dies nicht wieder zerschießt).
Bei detaiilierten Fragen, schickt mir 'ne PrivateMessage. Wenn's zuviel wird, schicke ich 'ne Rechnung

Und ja, das ist mein Job

CU

Schön und gut das Hier ne Anleitung zur Lag suche drinn steht.
Aber mal ne Frage: Warum hab ich nur Lag`s bei Ryzom ?
Das kann ja wohl kaum an meine Provider liegen. Noch dazu wenn ich bei anderen Online Games ohne Probs spielen kann.
Ausserdem sind nich alle Spieler so mit der Materie Ihres PC`s vertraut , das man von Ihnen erwarten kann dieses Problem selber zu suchen.
Aber lasst Euch nich aufhalten..nur denke ich das das Problem nich wirklich an den User Leitungen liegt.

golbor wrote:Schön und gut das Hier ne Anleitung zur Lag suche drinn steht.
Aber mal ne Frage: Warum hab ich nur Lag`s bei Ryzom ?
Das kann ja wohl kaum an meine Provider liegen. Noch dazu wenn ich bei anderen Online Games ohne Probs spielen kann.
Ausserdem sind nich alle Spieler so mit der Materie Ihres PC`s vertraut , das man von Ihnen erwarten kann dieses Problem selber zu suchen.
Aber lasst Euch nich aufhalten..nur denke ich das das Problem nich wirklich an den User Leitungen liegt.

Lag != Lag != Lag ...

Momentan ist's ziemlich offensichtlich, dass der Server Lags hervorruft. Der Thread war eigentlich für Fälle gedacht a la
A: Mist ist das am laggen!
B: Also, ich hab keine Probleme
C: Ich auch nicht, hab sogar noch Programm xy nebenbei laufen
A: Hmmm.... Komisch...

1. ryzom verwendet nur UDP packete, und keine echten pings (also ICMP). d.h. das SoR selbst einen vollständigen protocol stack implementiert hat, um die ingame anzeige für den ping zu basteln.

2. sind UDP verbindungen im vergleich zu TCP verbindungen connectionless. sprich, im protocol selbst ist keine error handling/packet loss handling vorgesehen. das ist auch etwas, das sich Nevrax selbst implementiert hat, um sich den sogenannten TCP protocol overhead zu sparen (annahme).

3. wenn eure firewall schlecht konfiguriert ist, dann kann das auch zu verzögerungen führen, da die einzelnen packete unter umständen sehr lange regelketten durchlaufen müssen, bis sie auf das interface losgelassen werden.

------------

die einzelnen UDP packete sind sehr klein, mit der MTU sollte es daher keine Probleme geben (außer man überfordert seinen eigenen router, weil man die MTU zu hoch hat).

cyall,

anasazi

hilft es dann was wenn man die firewall abschaltet? Und wie kann man die Datenmenge verringern? Einstellung aus machen?