vServer mit sporadisch auftretend hoher Latenz

Ich hatte mich ja bereits in diesem Thread hier zu dem Problem geäußert.

Nun war heute wieder von ca. 16.18 bis 16.41 Uhr eine Latenz beim vServer von teilweise weit über 200ms - was für Spieler auf einem CS: S-Server nicht zumutbar ist.

Für die hohe Latenz, die direkt vom vServer ausgehen muss, konnte ich selbst keine Ursache finden.

2012-07-05 16:21 Tracroute von traceroute.eu

traceroute to 88.198.182.44 (88.198.182.44), 30 hops max, 60 byte packets
1 	  	  	  	*	*	*
2 	hos-tr1.juniper1.rz13.hetzner.de 	213.239.224.1 	  	0.136 ms 	0.148 ms 	 
	hos-tr4.juniper2.rz13.hetzner.de 	213.239.224.97 	  	0.132 ms
3 	hos-bb2.juniper1.rz6.hetzner.de 	213.239.240.143 	  	4.099 ms 	4.119 ms 	4.118 ms
4 	gw01-hetzner.netcup.net 	78.47.244.254 	  	3.120 ms 	3.125 ms 	3.121 ms
5 	static.88-198-182-44.clients.your-server.de 	88.198.182.44 	  	212.119 ms 	212.091 ms 	212.107 ms

stats Befehl per rcon bei 88.198.182.44:27015

16:23:26 CPU    In (KB/s)  Out (KB/s)  Uptime  Map changes  FPS      Players  Connects
         0.00   8.44       26.75       239     6            66.83    3        120

stats Befehl per rcon bei 88.198.182.44:27045

16:23:56 CPU    In (KB/s)  Out (KB/s)  Uptime  Map changes  FPS      Players  Connects
         0.00   23.29      56.36       239     7            66.70    5        116

$ date && traceroute www.traceroute.eu
Thu Jul  5 16:28:53 CEST 2012
traceroute to www.traceroute.eu (88.198.46.60), 30 hops max, 60 byte packets
 1  37.221.192.3 (37.221.192.3)  210.373 ms  210.109 ms  210.338 ms
 2  static.253.245.47.78.clients.your-server.de (78.47.245.253)  210.341 ms  210.338 ms  210.327 ms
 3  hos-bb2.juniper1.rz13.hetzner.de (213.239.240.133)  212.784 ms hos-bb2.juniper2.rz13.hetzner.de (213.239.240.134)  212.827 ms hos-bb2.juniper1.rz13.hetzner.de (213.239.240.133)  218.396 ms
 4  hos-tr2.ex3k12.rz13.hetzner.de (213.239.224.45)  215.181 ms  215.279 ms hos-tr3.ex3k12.rz13.hetzner.de (213.239.224.77)  215.312 ms
 5  faces.eu (88.198.46.60)  212.832 ms  212.815 ms  212.822 ms

$ top
top - 16:30:15 up  4:14,  1 user,  load average: 0.59, 0.36, 0.34
Tasks:  22 total,   1 running,  21 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.9%us,  6.0%sy,  0.0%ni, 59.9%id, 25.8%wa,  0.0%hi,  1.4%si,  0.0%st
Mem:   2097152k total,   588676k used,  1508476k free,        0k buffers
Swap:  2097152k total,        0k used,  2097152k free,   371876k cached




***

Auf das Problem hatte mein Kollege den Support erst gestern noch mal aufmerksam gemacht, hierzu aber bisher noch keine konkrete Antwort erhalten.

Für Vorschläge zur Lösung des Problems wären wir daher sehr dankbar.

Seit dem 10. Juli 2012 setzten wir nun ein von mir selbst erstelltes Shell-Script ein, bei dem Ping alle 10 Sekunden ein „Echo-Request“-Paket an den nächstgelegen Host sendet, welchen ich zuvor per Traceroute ermittelt habe.

Erreicht die gemessene Latenz hierbei 100ms, wird dies plus die Load Average der letzten Minute geloggt. Die hierzu erstellte Log-Datei ist über den Webserver einsehbar.

Was kann dieses Phänomen hervorrufen und wie können wir es noch genauer untersuchen

Ein anderes Problem wurde von meinem Kollegen am 07.07.2012 gegen 20.23 Uhr bemerkt. Er befand sich zu diesem Zeitpunkt auf einem der CS: S-Server.

Die Spieler stockten in unregelmäßigen Abständen - für ca. eine bis drei Sekunden - mindestens einmal in der Minute. Nach über 30 Minuten bestand das Problem immer noch, ehe es später wieder verschwand.

Im Netgraph waren im Spiel während dieser Zeit keine ungewöhnlichen Werte zu erkennen, ebenso blieben Load Average und die Arbeitsspeicherauslastung des vServers wie gewohnt.

Mit dem Programm Top hatte ich mir dann die Auslastung der einzelnen CPU-Kerne etwas näher angeschaut, wobei mir einige Kerne mit Wait-Werten über 5-17% aufgeführt wurden.

Würde dies die Ruckler erklären, auch wenn die Angabe „wait“ für den eigenen vServer niedriger angezeigt wurde

Mein Kollege hatte sich bereits mit diesem Problem an den Support gewand, welcher darauf aber nicht näher einging und ihn stattdessen u. a. bzgl. möglicher eigener Konfigurationsfehler in dieses Forum hier verwies.

Zitat von vmk

Du pingst also nur zwischen deinem Privatrechner und dem vServer?

Nein, es wird die Latenz zwischen dem vServer und dem Host gemessen, welcher ausgehende Daten als Erster empfängt.

Siehe dazu in meinem Anfangspost:

Zitat von MMax

Code

$ date && traceroute www.traceroute.eu
Thu Jul  5 16:28:53 CEST 2012
traceroute to www.traceroute.eu (88.198.46.60), 30 hops max, 60 byte packets
 1  37.221.192.3 (37.221.192.3)  210.373 ms  210.109 ms  210.338 ms
***

Hier noch mein auf dem vServer eingesetztes Shell-Script - loghighpings.sh:

#!/bin/sh




# Start it with: ./loghighpings.sh & >/dev/null 2>&1
# Kill the process with: pkill -15 -U `whoami` loghighpings.sh




# Save the inet ip
IP="37.221.192.3"




# Send a ping request to the ip every 10s
while true
do
  # Save the relevant line from ping request
  PING_TEXT=`ping -c 1 $IP | grep time=`




  # Ping >= 100 ?
  if [ `echo $PING_TEXT | awk '{print $7}' | awk -F'=' '{print $2}' | awk -F'.' '{print $1}'` -ge 100 ]
    then
      # Log the high ping with load average from the last min
      echo "$(date "+%Y-%m-%d %H:%M:%S") $PING_TEXT | load average: `cat /proc/loadavg | awk '{print $1}'`" >> ping.log
  fi
  sleep 10
done

Für diesen Monat stehen in unserem High-Ping-Log bereits wieder 12 Einträge für den 7., 1 Eintrag für den 12. und 9 Einträge für den 13.

Ist denn inzwischen bekannt was diese hohen Latenzen zwischen dem vServer und dem nächstgelegenen Host verursacht oder verursachen kann?

Über Vorschläge wie sich das Problem weiter eingrenzen lassen könnte würden wir uns sehr freuen.

Inzwischen hat mein Kollege bereits mehrmals den Support kontaktieren müssen, da das Problem auch weiterhin besteht.

19.08.2012 - Anfrage per Supportformular
Mein Kollege machte den Support nochmals auf das Problem, mit Verweis auf diesen Thread, aufmerksam.

19.08.2012 - Antwort per E-Mail

Zitat

[...] ein einfacher Ping ist leider nicht aussagekräftig, da aus diesem nicht hervor geht an welcher Stelle die erhöhte Latenz auftritt. [...] Daher benötigen wir für solche Diagnosen aussagekräftige Routenverfolgungen die mittels des Tools MTR oder WinMTR angefertigt wurden. [...]

19.08.2012 - Anfrage per Supportformular
Mein Kollege erklärte dem Support, dass bereits aus dem Schreiben vom 22.06.2012, mit einem Traceroute zu google.de (173.194.35.184) und aus dem Thread hier, mit einem Traceroute am 05.07.2012 zu traceroute.eu (88.198.46.60), hervorgehen würde, dass die erhöhte Latenz bereits am nächstgelegene Host hinter dem vServer auftritt. Ein aktueller Traceroute vom 19.08.2012 zu netcup.de sollte zudem beweisen, dass der nächstgelegene Host auch weiterhin die IP 37.221.192.3 ist.

20.08.2012 – Antwort per E-Mail

Zitat

[...] MTR erstellt wie sie richtig erfasst haben, eine Art Traceroute und ping Kombination. Dabei wird jeder Hop des Tracerouts angepingt wodurch dies nachvollziehbarer wird.
Ein normaler Traceroute zeigt immer nur eine Momentaufnahme vom einmaligen Aufbau des Trace Pfades.

Mit dem Tool MTR ist es möglich dies über mehrere Durchgänge zu betrachten wodurch sich dann auch die Dauer der erhöhten Latenzen und ähnlichem erkennen lässt.

Die Ausgabe von MTR/WinMTR ist hier deutlich informativer als bei einem einfachen Traceroute. [...]

21.08.2012 - Anfrage per Supportformular
Mein Kollege machte den Support nochmals darauf aufmerksam, dass der Einsatz von MTR aus seiner Sicht überflüssig wäre: „[...] da bereits der nächstgelegene Host hinter dem vServer für die hohe Latenz verantwortlich ist. Da liegt also kein weiterer Host dazwischen. Ein Aufruf von Ping reicht also in diesem Fall um die hohe Latenz nachzuweisen. [...]“

22.08.2012 - Antwort per E-Mail

Zitat

[...] es kann durchaus sein, das ein einzelner Host erhöhte Antwortzeiten auf ICMP anfragen hat, gerade router sind meist so konfiguriert das diese unpriorisiert auf ICMP Anfragen reagieren.

Erst wenn Sich die erhöhte Latenz dann auch auf die folgenden Hops überträgt kann man davon ausgehen das an dem genannten Hop ein Problem vorliegt. [...]

22.08.2012 - Anfrage per Supportformular
Mein Kollege versicherte dem Support: „ [...] dass sich die erhöhte Latenz in meinem Fall auch auf nachfolgende Hops überträgt, da die unter http://88.198.182.44/ping.log erfassten Latenzen direkten Einfluss auf meine Gameserver hatten. In mehreren Fällen war ich hierzu selbst anwesend, ansonsten lässt sich dieser Zusammenhang auch an den im jeweiligen GS-Log erfassten Spielerreaktionen nachvollziehen.“

23.08.2012 - Antwort per E-Mail

Zitat

[...] wenn sie uns dies zusichern, hilft dies dennoch unserer Analyse nicht weiter. Bitte übersenden sie uns den angeforderten MTR, da dies unserer Analyse entgegen kommt. [...]

24.08.2012 - Anfrage per Supportformular
Mein Kollege erklärte dem Support, dass MTR nach der Installation genauso wie auch bei anderen Kunden auf dem vServer nicht funktionieren würde. Siehe: My Traceroute (mtr-tiny)

24.08.2012 - Antwort per E-Mail

Zitat

[...] bitte machen Sie MTRs von Ihrem Rechner aus Richtung des Vservers. Machen Sie gegebenenfalls traceroutes vom vServer auf ein beliebiges zuverlässiges Ziel.
Und stellen Sie uns diese zur Verfügung. [...]

Meiner Einschätzung nach haben wir bereits genug Anhaltspunkte geliefert und „MRTs“ vom privaten Rechner zum vServer gestalten sich etwas schwierig, wenn man dabei erst auf das Problem mit der hohen Latenz warten muss. Wäre eine derartige Überprüfung nicht vom netcup-Support selbst zu realisieren und zu erwarten? Immerhin steht die Fehlerquelle für uns bereits weitestgehend fest und wird ausschließlich vom Support angezweifelt, während eine weitere Analyse mittels 2. Rechner vorgegeben wird. Wie seht ihr das?

Aktuell besteht auch noch ein weiteres Problem, dass es auf den CS: S-Servern ständig ruckelt. Meinem Kollegen ist dieses Problem seit dem 19.10.2012 bekannt, zuvor hatte er einige Tage nicht gespielt und wurde dann von mehreren Spielern angeschrieben, dass dieses Problem schon seit 1-2 Wochen bestehen würde. Den vServer hatte er daraufhin extra neu gestartet, aber leider ohne Besserung. Ich erfuhr von dem Problem erst am nächsten Tag und habe bereits die Auslastung des vServers mit top und free überprüft, aber nichts besonderes feststellen können. Ich kann im Moment leider selbst nicht auf die CS: S-Server, da mein Grafiktreiber nicht mehr funktioniert und ich auf bereits bestellte Komponenten zum Austausch warte.

Meinem Kollegen ist allerdings noch aufgefallen, dass die unterste Linie im net_graph immer dann orange/rot (siehe [8a]) ausschlägt, sobald es ruckelt. Der Support wurde deswegen bereits gestern kontaktiert. Eine Antwort steht noch aus.

Unsere CS: S Server:
[Blockierte Grafik: http://cache.%5Burl=http://www.gametracker.com/server_info/88.198.182.44:27015/b_350_20_692108_381007_FFFFFF_000000.png%5Dhttp://www.gametracker.com/server_info/88.198.182.44:27015/b_350_20_692108_381007_FFFFFF_000000.png][img][/img][/url]
[Blockierte Grafik: http://cache.%5Burl=http://www.gametracker.com/server_info/88.198.182.44:27045/b_350_20_692108_381007_FFFFFF_000000.png%5Dhttp://www.gametracker.com/server_info/88.198.182.44:27045/b_350_20_692108_381007_FFFFFF_000000.png][img][/img][/url]

Zitat von sim

Sieht für mich OK aus.
Nur der Juniper Router schlägt mit 100ms AVG ein bissl aus der Reihe.

Die erhöhte Latenz tritt wie gesagt sporadisch auf. Wie du auch in der Log-Datei auf dem Webserver erkennen kannst.

Ergänzend möchte ich noch erwähnen, dass der letzte Neustart des Nodes ausfallbedingt am 17.10.2012 zwischen ca. 13:48 und 15:16 Uhr war. Die aktuelle Kernel-Version ist die 3.5.3-vs2.3.4.2.0-nc #3 SMP Mon Aug 27 16:45:21 UTC 2012 x86_64 GNU/Linux. Zuvor war es lange Zeit der „stabile 2.6er-Kernel“. Vielleicht könnte dies ja was mit dem neuen Problem zu tun haben?

Die erhöhten Latenzen wurden zwischen dem 17.10.2012 und dem 20.10.2012 nicht aufgezeichnet, mangels Autostart-Eintrag.

Wie im Log zu erkennen ist, haben die gemessenen Latenzen in den letzten Tagen nochmals zugenommen. Eine Einschätzung wie „[...] es kann durchaus sein, das ein einzelner Host erhöhte Antwortzeiten auf ICMP anfragen hat, gerade router sind meist so konfiguriert das diese unpriorisiert auf ICMP Anfragen reagieren. [...]“, halte ich für etwas unrealistisch, da die Antwortzeit sonst bei unter 1 ms liegt und nun teilweise mit über 665 ms gemessen wird.

Seit kurzen ruckelt es nun auch noch fortlaufend auf den CS: S-Servern, wovon sich jeder bei Interesse selbst überzeugen kann. Dies allerdings auch ohne erkennbare Latenzerhöhung.

Der Support wurde bereits gestern informiert. Eine Antwort bleibt dieser weiterhin schuldig.

Wir denken daher bereits über einen Anbieterwechsel nach!

Zitat von MMax

Meinem Kollegen ist allerdings noch aufgefallen, dass die unterste Linie im net_graph immer dann orange/rot (siehe [8a]) ausschlägt, sobald es ruckelt.

Hierzu ein Screenshot, aufgenommen von meinem Kollegen.
[Blockierte Grafik: http://s14.directupload.net/images/121022/sdbbjjfs.jpg]

Zitat von Impact

Er soll diesen Screenshot mal mit net_graph 4 machen.

Das ist nun nicht mehr notwendig. Es gab heute Wartungsarbeiten, womit zumindest das neuere Problem, ein fortlaufendes Ruckeln auf den CS: S-Servern, behoben werden konnte.

Zitat von netcup-Support

[...] wir müssen Wartungsarbeiten am Node Ihres vServers durchführen. Dadurch ist folgender Ihrer vServer am 24.10.2012 zwischen 16:30 und 17:00 für ca. 30 Minuten nicht zu erreichen: [...]

Mit dem Neustart werden wir ein Update des Kernels verbinden wodurch wir Ihnen einen weiteren Neustart des vServers ersparen. [...]

$ date && uname -va
Wed Oct 24 21:50:49 CEST 2012
Linux *** 3.0.46-vs2.3.2.5.2-nc #1 SMP Wed Oct 24 12:28:39 UTC 2012 x86_64 GNU/Linux

Mein Shell-Script, loghighpings.sh, habe ich eben wieder gestartet.

Zitat von Duschcreme

Ich habe bei meinem vServer Saturn seit ungefähr Mitte letzter Woche ebenfalls starke Lag Probleme.

Welche Kernel-Version ist im Einsatz?

Zitat von Duschcreme

Code

Wed Oct 24 22:16:34 CEST 2012
Linux *** 3.0.42-vs2.3.2.4.0-nc #1 SMP Tue Sep 11 20:27:13 UTC 2012 x86_64 GNU/Linux

Das ist nicht die Version mit der wir die Probleme hatten (3.5.3-vs2.3.4.2.0-nc).

Zitat von Duschcreme

NetCup Antwort war natürlich ne Standard Antwort... es liegt natürlich an meinem vServer an dem ich seit 2 Wochen nichts gemacht habe...

Bei meinem Kollegen gab’s diesmal noch gar keine direkte Antwort, außer die oben erwähnte Systemnachricht.

Zitat von Duschcreme

Jemand Erfahrung mit dem hier oder *** gesammelt?

Nein, leider nicht. Mein Kollege überlegt auch schon ernsthaft stattdessen einen Root-Server zu mieten.

Ich persönlich halte die Leistung von netcup, sofern ohne Fehler - und das Preis-Leistungs-Verhältnis, für sehr gut. Der Support scheint mir etwas schreibfaul zu sein und bemüht sich nach meiner Erfahrung eher selten um klare Antworten und Hilfestellungen.

Würde der Support mal alle von meinem Kollegen genannten Mängel abstellen, dann würden wir uns wohl dazu entscheiden den vServer zu behalten. Zum Betreiben von CS: S-Servern eignet sich dieser nämlich sonst ganz gut.

Zu dem „Update des Kernels“ von heute ist mir noch etwas aufgefallen.

$ date && free -m
Wed Oct 24 23:09:11 CEST 2012
             total       used       free     shared    buffers     cached
Mem:          4096        288       3807          0          0         90
-/+ buffers/cache:        197       3898
Swap:            0          0          0

Zum Vergleich:

$ date && free -m
Thu Jul  5 19:03:13 CEST 2012
             total       used       free     shared    buffers     cached
Mem:          2048        611       1436          0          0        373
-/+ buffers/cache:        237       1810
Swap:         2048          0       2048

Das Ganze erinnert mich ein bisschen an einen Fehler von Ende Juni diesen Jahres.

Da die erhöhte Latenz zum vServer gerade wieder besteht, hier mal ein paar Ergebnisse mit Traceroute von unterschiedlichen Standorten und in beide Richtungen.

2012-11-10 22:28 von meinem PC zum vServer

C:\***>tracert 88.198.182.44




Routenverfolgung zu static.88-198-182-44.clients.your-server.de [88.198.182.44]
über maximal 30 Abschnitte:




  1     1 ms     1 ms     1 ms  *** [192.***]
  2    28 ms    36 ms    28 ms  *** [***]
  3    27 ms    27 ms    27 ms  core1.ber.qsc.de [87.234.11.149]
  4    42 ms    42 ms    43 ms  core1.fra.qsc.de [87.234.12.105]
  5    44 ms    51 ms    44 ms  decix-gw.hetzner.de [80.81.192.164]
  6    48 ms    48 ms    47 ms  hos-bb1.juniper1.rz6.hetzner.de [213.239.240.238
]
  7    47 ms    47 ms    47 ms  gw01-hetzner.netcup.net [78.47.244.254]
  8   226 ms   222 ms   228 ms  static.88-198-182-44.clients.your-server.de [88.
198.182.44]




Ablaufverfolgung beendet.

2012-11-10 22:29 von traceroute.eu zum vServer

traceroute to 88.198.182.44 (88.198.182.44), 30 hops max, 60 byte packets
1 	static.185.212.4.46.clients.your-server.de 	46.4.212.185 	de 	3.686 ms 	3.694 ms 	3.766 ms
2 	hos-tr1.juniper1.rz13.hetzner.de 	213.239.224.1 	de 	0.167 ms 	 	 
	hos-tr4.juniper2.rz13.hetzner.de 	213.239.224.97 	de 	0.125 ms 	 
	hos-tr2.juniper1.rz13.hetzner.de 	213.239.224.33 	de 	0.119 ms
3 	hos-bb2.juniper1.rz6.hetzner.de 	213.239.240.143 	de 	3.025 ms 	2.975 ms 	3.002 ms
4 	gw01-hetzner.netcup.net 	78.47.244.254 	de 	3.128 ms 	3.108 ms 	3.112 ms
5 	static.88-198-182-44.clients.your-server.de 	88.198.182.44 	de 	175.249 ms 	175.251 ms 	175.239 ms

2012-11-10 22:32 vom vServer zu http://www.netcup.de

$ date && traceroute www.netcup.de
Sat Nov 10 22:32:15 CET 2012
traceroute to www.netcup.de (78.46.208.25), 30 hops max, 60 byte packets
 1  37.221.192.3 (37.221.192.3)  181.358 ms  176.879 ms  176.871 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Im Spiel macht sich die erhöhte Latenz natürlich auch bemerkbar:
[Blockierte Grafik: http://88.198.182.44/hohelatenz.jpg]

Zitat von [netcup] Felix

Der Host http://www.netcup.de wird nie auf ICMP reagieren.

Gut zu wissen. In der Vergangenheit ging dies jedenfalls noch, wie Sie es aus einer Anfrage meines Kollegen vom 19.08.2012 entnehmen können. Das ist aber auch nicht weiter tragisch, denn wie Sie erkennen können, tritt die erhöhte Latenz, wie in allen anderen hier genannten Fällen auch, bereits am nächstgelegenen Host auf.

Zitat

Wenn die Latenz am letztem Hop, sprich in dem Fall an Ihrem vServer so hoch ist, bitte diesen prüfen. Wenn Sie dann immer noch der Meinung sind das ein Problem bei netcup vorliegt, prüfen Sie doch einmal eine IP-Adresse die neben der Ihren liegt.

Die Bandbreitenauslastung lässt sich ja bei Ihnen als Kunde leider nicht überprüfen. Wie wäre es mit einem Traceroute von meinem Privatrechner zu 88.198.182.45? Die Route scheint zwar der unseres vServers zu gleichen, doch wie verlässlich ist diese Überprüfung, wenn der vServer in der Vergangenheit bereits einmal samt IP auf einen anderen Node umgezogen ist?

Zitat

Auch empfehlen wir zu beachten, dass Gameserver z.B. verzögert antworten wenn ein anderes Programm auf dem Server, z.B. der Apache, gerade Ressourcen benötigt. Auf der von Ihnen genannten IP-Adresse, antwortet ein Apache. Wenn Sie gleichmäßige Responsetimes haben möchten, sollten Sie auch für eine gleichmäßige Auslastung auf Ihrem System sorgen.

Wie Sie aus dem Log des von mir erstellten Shell-Scripts zum Messen der Latenz zwischen dem vServer und dem nächstgelegenen Host feststellen können, liegt die Durchnittsbelastung des vServers fast immer unter 1.00, wenn die Latenz erhöht ist. So auch gestern zwischen 22:11 und 23:46 Uhr. Eine Bandbreitenauslastung durch den Apache-Dienst käme über so einen langen Zeitraum einem Angriff gleich, da dieser bis für die Motd-Seiten im Spiel und für die benutzerdefinierten Dateien für die Spieler bei uns kaum Verwendung findet. Selbstverständliche habe ich mir die Logs des Apache-Dienstes auch mal dahingehend angeschaut. So gab es z. B. gestern zwischen 22:15 und 22:24 Uhr keinerlei Anfragen an diesen, dennoch hat mein Shell-Script aber für diesen Zeitraum erhöhte Latenzen gemessen.

2012-11-10 22:15:04 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=169 ms | load average: 0.25
2012-11-10 22:15:24 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=154 ms | load average: 0.25
2012-11-10 22:15:34 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=169 ms | load average: 0.21
2012-11-10 22:15:44 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=172 ms | load average: 0.18
2012-11-10 22:15:55 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=153 ms | load average: 0.29
2012-11-10 22:16:05 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=142 ms | load average: 0.32
2012-11-10 22:16:15 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=166 ms | load average: 0.27
2012-11-10 22:16:25 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=178 ms | load average: 0.23
2012-11-10 22:16:35 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=175 ms | load average: 0.27
2012-11-10 22:16:46 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=179 ms | load average: 0.30
2012-11-10 22:16:56 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=185 ms | load average: 0.25
2012-11-10 22:17:06 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=172 ms | load average: 0.37
2012-11-10 22:17:16 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=186 ms | load average: 0.39
2012-11-10 22:17:26 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=170 ms | load average: 0.41
2012-11-10 22:17:37 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=155 ms | load average: 0.43
2012-11-10 22:17:47 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=149 ms | load average: 0.43
2012-11-10 22:17:57 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=161 ms | load average: 0.44
2012-11-10 22:18:07 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=154 ms | load average: 0.45
2012-11-10 22:18:17 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=171 ms | load average: 0.46
2012-11-10 22:18:27 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=165 ms | load average: 0.38
2012-11-10 22:18:38 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.40
2012-11-10 22:18:48 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=154 ms | load average: 0.33
2012-11-10 22:18:58 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=160 ms | load average: 0.28
2012-11-10 22:19:08 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=165 ms | load average: 0.24
2012-11-10 22:19:18 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.20
2012-11-10 22:19:38 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=168 ms | load average: 0.36
2012-11-10 22:19:49 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=183 ms | load average: 0.30
2012-11-10 22:19:59 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=160 ms | load average: 0.25
2012-11-10 22:20:09 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=162 ms | load average: 0.30
2012-11-10 22:20:19 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=181 ms | load average: 0.40
2012-11-10 22:20:49 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=176 ms | load average: 0.36
2012-11-10 22:21:20 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=177 ms | load average: 0.41
2012-11-10 22:21:40 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=179 ms | load average: 0.29
2012-11-10 22:21:50 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=177 ms | load average: 0.24
2012-11-10 22:22:00 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=161 ms | load average: 0.20
2012-11-10 22:22:11 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=170 ms | load average: 0.25
2012-11-10 22:22:21 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=168 ms | load average: 0.21
2012-11-10 22:22:31 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=170 ms | load average: 0.26
2012-11-10 22:22:41 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=171 ms | load average: 0.30
2012-11-10 22:22:51 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=173 ms | load average: 0.25
2012-11-10 22:23:01 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=177 ms | load average: 0.29
2012-11-10 22:23:12 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.25
2012-11-10 22:23:22 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=160 ms | load average: 0.21
2012-11-10 22:23:32 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=184 ms | load average: 0.25
2012-11-10 22:23:52 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=133 ms | load average: 0.41
2012-11-10 22:24:12 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=157 ms | load average: 0.44
2012-11-10 22:24:23 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=159 ms | load average: 0.37
2012-11-10 22:24:33 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.31
2012-11-10 22:24:43 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=161 ms | load average: 0.26
2012-11-10 22:24:53 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=174 ms | load average: 0.22

Zitat von [netcup] Felix

Wo genau kann ich das dort entnehmen?

Zitat von MMax

[...] Ein aktueller Traceroute vom 19.08.2012 zu netcup.de sollte zudem beweisen, dass der nächstgelegene Host auch weiterhin die IP 37.221.192.3 ist. [...]

Der genaue Wortlaut der Anfrage meines Kollegen:

Zitat

[…] Hierzu auch noch mal ein aktueller Traceroute von meinem vServer zu netcup.de
(78.46.208.25):
$ date && traceroute netcup.de
Sun Aug 19 16:08:11 CEST 2012
traceroute to netcup.de (78.46.208.25), 30 hops max, 60 byte packets
1 37.221.192.3 (37.221.192.3) 0.209 ms 0.181 ms 0.168 ms
2 netcup.de (78.46.208.25) 0.144 ms 0.177 ms 0.167 ms

Wie Sie erkennen können, ist der nächstgelegene Host immer die IP 37.221.192.3, daran hat
sich nichts geändert. […]

Alles anzeigen

Zitat von [netcup] Felix

Das lässt sich nicht bestimmen. Allerdings sind die Nodes in der Regel gleich konfiguriert. Der Node auf dem Ihr vServer läuft gleicht der gängigsten Konfiguration. Andere Kunden auf dem Node haben keine Probleme wie Sie.

Was damit zusammenhängen könnte, dass deren Anwendungsschwerpunkt oft woanders liegt und derartige Latenz-Sprünge da nicht weiter auffallen.

Zitat von [netcup] Felix

Gerne können Sie auch beim Support um einen Node-Wechsel bitten. So können Sie Probleme am Node zu 100% ausschließen.

Die Möglichkeit werde ich mit meinem Kollegen diskutieren. In der Vergangenheit hatte dies bereits einmal für einen längeren Zeitraum geholfen. Letzten Endes scheint es Ihren Ausführungen nach aber keine Garantie dafür zu geben, dass eine solche Maßnahme dauerhaft derartige Probleme beheben könnte, wenn die Nodes alle gleichermaßen eingestellt und auch belastet werden.

Zitat von [netcup] Felix

Die Responsetimes sind ja auch durchaus im grünen Bereich. Daher ist es wohl ganz normal das die Load unter 1 liegt. Diese sollten nicht für "Ruckler" in gängigen Gameservern verantwortlich sein.

In „gängigen Gameservern“ wie CS: S, CS, TF2, HL2DM, L4D2 und CoD führt eine Latenz von über 150ms anstatt wie sonst üblich von unter 1ms, zum ersten Host hinter dem vServer, vermutlich zu Situationen, wo ein Spieler bereits hinter einer Ecke verschwunden ist, vom Gegenspieler aber dennoch gesehen und auch getroffen wird.

Zitat von [netcup] Felix

Bedenken Sie bitte auch das vServer nicht unbedingt für aufwendige Echtzeitberechnungen geeignet sind, da vServer neben den garantierten Ressourcen auch zusätzliche Ressourcen nutzen können, sollten andere vServer auf dem Node diese nicht benötigen. In dem Moment wo diese allerdings benötigt werden, finden Verschiebungen der Ressourcen statt. Z.B. werden die Recheneinheiten an den CPUs vermindert. Ich kann mir durchaus vorstellen, dass sich dieses negativ auf einige Gameserver auswirkt.

Zugegeben, wir erwarten von einem vServer in unserem Fall eine besonders niedrige Latenz, da die Spieler sehr sensibel auf erhöhte Verzögerungen zum Server bei der von uns verwendeten Fußballkarte reagieren. Eine derartige Aussage, dass die von Ihnen „garantierten Ressourcen“ (in unserem Fall 4 GHz CPU-Leistung und 2 GB Arbeitsspeicher) sich nicht für eine uneingeschränkte Verwendung eignen würden, das hören mein Kollege und ich von Ihnen zum allerersten Mal.