Suche einen guten & preiswerten Root-Server Hoster

Das wundert mich aber, das MTR hat ergeben, dass bei einem Hetzner Switch ca. 26% Pakete vom Root zum Client verloren gehen.

Und das ist nun wirklich nicht das, was man bei dem Geld erwartet. ^^

Habe auch eine Antwort vom Support erhalten:

====

Sehr geehrter Herr XXXX,

bitte beachten Sie, dass unser Netzwerk nicht auf Latenz optimiert ist. In den
MTRs ist soweit kein Problem ersichtlich.


Mit freundlichen Grüßen / Best Regards

XXXX XXXX

====

Wieso kein Problem??? Es sind 26% Pakete verloren gegangen, was ist das für 'ne Antwort? :O

Ich muss jedoch sagen das ich beim Minecraft spielen keine "Laggs" bemerke, ich kann d.h. Xirra nur bestens empfehlen.

Laggs machen sich bei Minecraft auch eher nur im "hohen" Ausschlag bemerkbar.

Grüße.
 
MTR verwendet ICMP-Pakete welche mit einer spezifischen TTL (Hop-Anzahl) versehen werden.
Viele Router droppen die Pakete oder verzoegern die Verantwort wenn sie ueberdurchschnittlich belastet sind da es Rechenlast verursacht und nicht fuer die Netzwerkintegritaet von Bedeutung ist.
Solange deine anderen Pakete groesstenteils ankommen (UDP ist stateless, Verlust eines Paketes ist immer moeglich) ist das kein Problem.

Auf meine Frage bezgl dem Programm hast du uebrigens noch nicht reagiert.
Dieses misst die Belastung des Kernels indem es kontrolliert wie hoch dessen Latenzzeit ist. Hohe Latenzzeiten bedeuten meist eine hohe CPU- und/oder IRQ-Belastung.
 
iMarkus said:
Hat jemand noch weitere gute Angebote/Anbieter? ^^

"Kennen" tu ich einige. Erfahrungen habe ich bis jetzt nur mit Hetzner. Und da würde ich auch Leute hin weiterempfehlen. Gab zwar am Anfang mal ein kleines Missverständnis, aber das ist schnell breinigt gewesen und vom Tisch.

Mein allerallererster Gedanke, wo ich einen Server mieten wollte war 1&1. Doch mir rieten zu Hetzner sehr viele aus dem Forum "Administrator.de".

iMarkus said:
Und das ist nun wirklich nicht das, was man bei dem Geld erwartet. ^^

Markus, ich weiss ja jetzt nicht, welches Servermodell Du da bei hetzner genau hast. Aber vergleiche mal die Hardware Deines Servers (egal welcher es auch ist) mit der entsprechenden "Leistung" an Hardware beispielsweise bei 1&1. Also bei 1&1 habe ich bei 2/3 der RAM-Kapazität (des Hetzner-Servers) schon über dessen Preis hinausgeschossen.

Hetzner hat in vielen Servern ASUS-Hardware (Mainboards) (meine private Hausmarke) verbaut. Evtl ist hier der Preisunterschied zu rechtfertigen, also das 1&1 oder Hosteurope von anderen teureren Herstellern (die ausschliesslich Serverhardware herstellen) Produkte in die Server verbaut...

Damit es nicht wieder (wie man von mir gewohnt ist, vielleicht :rolleyes:) ein Riesenroman wird, mache ich es kurz:

Das was ich bei Hetztner für 109€ habe, habe ich weder bei 1&1, noch bei Hosteurope für den selben Preis! Es wären an die 300€(!)
Hetzner ist schon geil. Allerdings will ich nicht verwerfen, das Andere Mitschreibende vielleicht mit ihren Providern noch glücklicher sind... Was mich an Hetzner auch gut finde, das die eine sehr geniale Wiki-Doku haben wo man sich vieles selbst erschliessen kann...
 
Last edited by a moderator:
Ich bin ja auch nicht gerade abgeneigt von Hetzner, aber wenn es schwarz auf weiß steht, dass es einen Paketverlust von 26% gibt, dann frage ich mich, warum man einen Traffic von 5TB Monatlich anbietet und einen derart Leistungsstarken Server anbietet.^^
 
iMarkus said:
Ich bin ja auch nicht gerade abgeneigt von Hetzner, aber wenn es schwarz auf weiß steht, dass es einen Paketverlust von 26% gibt.

d4f said:
MTR verwendet ICMP-Pakete welche mit einer spezifischen TTL (Hop-Anzahl) versehen werden.
Viele Router droppen die Pakete oder verzoegern die Verantwort wenn sie ueberdurchschnittlich belastet sind da es Rechenlast verursacht und nicht fuer die Netzwerkintegritaet von Bedeutung ist.

Sag mal, liest du die Antworten hier im Thread eigentlich?

Wenn die Pakete an deinem Server verloren gehen würden, wäre das ein Problem. Wieso die Router nicht immer auf ICMP Pakete antworten, hat d4f bereits beschrieben. Auch die Router von OVH arbeiten so, um mal einen weiteren großen Hoster zu nennen.
 
Sag mal, liest du die Antworten hier im Thread eigentlich?

Wenn die Pakete an deinem Server verloren gehen würden, wäre das ein Problem. Wieso die Router nicht immer auf ICMP Pakete antworten, hat d4f bereits beschrieben. Auch die Router von OVH arbeiten so, um mal einen weiteren großen Hoster zu nennen.

Fast jede vernünftige Netzwerk Infrastruktur arbeitet so. Da ICMP irrelavant sind für den Betrieb. Deswegen kann es öfters passieren, das mal ein PING flöten geht.
 
Hast nur du so einen hohen Ping oder alle die auf den Gameservern spielen?

Ich weiß aus eigener Erfahrung, dass die Leitung von o2 (mediaways.net) nicht die beste ist. Ich haben selbst solche eine Leitung wg. 1und1 und ich bin bei duchschnittlich 40ms zu Hetzner.
Vorher war ich bei der Telekom und hatte durchschnittlich 20ms.
 
Sag mal, liest du die Antworten hier im Thread eigentlich?

Wenn die Pakete an deinem Server verloren gehen würden, wäre das ein Problem. Wieso die Router nicht immer auf ICMP Pakete antworten, hat d4f bereits beschrieben. Auch die Router von OVH arbeiten so, um mal einen weiteren großen Hoster zu nennen.

Die Verlustrate liegt vom Client zum Server hin bei ca. 7%, laut deiner Aussage ist das wohl ein Problem, richtig? :O

Hast nur du so einen hohen Ping oder alle die auf den Gameservern spielen?

Ich weiß aus eigener Erfahrung, dass die Leitung von o2 (mediaways.net) nicht die beste ist. Ich haben selbst solche eine Leitung wg. 1und1 und ich bin bei duchschnittlich 40ms zu Hetzner.
Vorher war ich bei der Telekom und hatte durchschnittlich 20ms.

Alle.
Grüße.
 
Last edited by a moderator:
Die Verlustrate liegt vom Client zum Server hin bei ca. 7%, laut deiner Aussage ist das wohl ein Problem, richtig? :O
Auch dein Server reagiert nicht unbedingt auf alle PING, zumal wenn er belastet ist. Des weiteren hat Linux afaik ein Mindest-Intervall zwischen 2 Pings, waere moeglich dass diese unterschritten wurde.

Das Hauptproblem selber - dass dein Server aus dem letzten Loch pfeift - scheinst du geflissentlich zu ignorieren und die Schuld verzweifelt beim Netzwerk zu suchen.
 
@iMarkus: hast Du denn überhaupt schon mal Deine Serverressourcen analysiert, wenn "Du glaubst dass er laggt"? Wie siehts mit dem freien RAM aus, was sagt die CPU Last?

Gibts die Probleme auch, wenn Du z.B. mal einen Teil Deiner Prozesse abschaltest?
 
Markus, gib mal "top" in die Shell ein, wenn Du auf dem Server bist und Du meinst, das es Paketverlust gibt und/oder der Ping "so unmöglich" ist.

Dann beobachtest das mal über einen längeren Zeitraum. Und wenn die avg nicht unter sagen wir 60-70% ist -also kontinuierlich - dann würde ich mir evtl Gedanken machen, entweder einen stärkeren Server zu nehmen, wie Thunderbyte geraten hatte, nicht benötigte Prozesse auszuschalten, oder auf 2 Server zu verteilen. Mir persönlich würde mein Server, liefe er kontinuierlich auf über 70% sagen wir mal um es nicht zu übertreiben, Leid tun.

Ich habe von hier bis zum Server auch an die 20ms bis 30ms Ping-Zeit. Nur das kommt ja auch immer ein wenig drauf an, wie weit Du vom Server weg bist. Wenn jemand in der Schweiz wohnt und sein Server steht bei Hetzner, das sind schonmal paarhundert km weniger als meine Entfernung beispielsweise zum Server. Dann wundert es mich nicht, das hier manche von 13ms berichten.

Nochein Beispiel:

Mach mal einen Speedtest und IP-Test Deines Inet-Zuganges. Die Dir am nähesten gelegenen Pingtest-Server zeigen Dir unglaubliche 5ms - 10ms. Dann suchst mit Absicht einen entfernteren Testserver. Und hast 2-3mal so hoch...
 
So, also auf unserem Server ist das Plugin Webmin drauf. Das sollte eigentlich relativ verlässliche Daten von sich geben:

CPU-Last im Durchschnitt: 0.11 (1 Minute) 0.24 (5 Minuten) 0.23 (15 Minuten)
CPU Auslastung: 14% Benutzer, 3% Kernel, 0% IO, 83% Leerlauf
Realer Speicher: 15.62 GB gesamt, 5.60 GB benutzt
Virtueller Speicher: 32 GB gesamt, 34.90 MB benutzt
Lokaler Festplattenspeicher: 2.70 TB gesamt, 289.79 GB benutzt

Also, auch wenn ich nicht das größte Fachwissen habe, würde ich sagen, dass er mit mit der CPU im 83%igen Leerlauf nicht "ausm letzten Loch pfeift".^^

Habe außerdem mal die Einträge von "top" rauskopiert:

top - 22:25:21 up 62 days, 20:01, 1 user, load average: 0.47, 0.26, 0.24
Tasks: 179 total, 2 running, 177 sleeping, 0 stopped, 0 zombie
Cpu(s): 10.5%us, 2.3%sy, 0.0%ni, 86.4%id, 0.4%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 16383052k total, 15447380k used, 935672k free, 283824k buffers
Swap: 33553332k total, 35736k used, 33517596k free, 9264272k cached

Prozesse:

5489 cod4srv -41 0 362m 352m 3120 S 17 2.2 117:13.18 cod4_lnxded-bin
18721 cod4srv -41 0 364m 318m 3468 S 15 2.0 1630:05 cod4_lnxded-bin
10062 cod4srv -41 0 364m 314m 3444 S 14 2.0 862:51.82 cod4_lnxded-bin
18921 mcsrv -31 0 4717m 987m 6196 S 13 6.2 8115:34 java
1072 root -51 0 0 0 0 S 8 0.0 5871:53 irq/44-eth0
7985 cod4srv -41 0 364m 260m 3424 R 8 1.6 3:06.08 cod4_lnxded-bin
28838 cod4srv -41 0 364m 318m 3468 S 6 2.0 222:13.67 cod4_lnxded-bin
567 ts3srv -21 0 354m 30m 4488 S 4 0.2 1334:39 ts3server_linux
23735 cod4srv -41 0 362m 314m 3140 S 2 2.0 595:48.69 cod4_lnxded-bin
1295 cod4srv -41 0 364m 307m 3432 S 2 1.9 75:29.24 cod4_lnxded-bin
13632 cod4srv -41 0 363m 273m 3416 S 2 1.7 6:58.61 cod4_lnxded-bin
22150 cod4srv -41 0 363m 177m 3168 S 2 1.1 58:09.68 cod4_lnxded-bin
28142 cod4srv -41 0 363m 305m 3424 S 2 1.9 162:43.98 cod4_lnxded-bin
28202 cod4srv -41 0 364m 307m 3436 S 2 1.9 197:12.44 cod4_lnxded-bin
32200 cod4srv -41 0 364m 304m 3432 S 2 1.9 369:24.43 cod4_lnxded-bin
3 root -2 0 0 0 0 S 0 0.0 114:29.43 ksoftirqd/0
20 root -2 0 0 0 0 S 0 0.0 110:20.19 ksoftirqd/3
 
Solange du geflissentlich Fragen und Anregungen ignorierst kann man dir nicht helfen.
Ich habe Quellcode gepostet den du kompilieren und ausfuehren sollst.

Ausserdem bitte die Ausgabe (fullscreen) von "atop 1"
(atop muss ggf nachinstalliert werden)
 
Zitat von meinem Techniker^^

Wir benutzen den RT-Kernel-Patch (rt.wiki.kernel.org) und die Gameserver-Prozesse laufen mit der SCHED_RR scheduling policy mit gleicher Priorität ( > -50 ). Wenn ich das Programm in SCHED_RR oder SCHED_FIFO mit beliebiger Priorität ausführe, errechnet es eine durchschnittliche CPU-Latenz von 550ns. Ohne eine spezielle Priorisierung (also SCHED_OTHER) liegt die Latenz bei ca. 53000 ns, aber das ist ja unwichtig. Interessant wären jetzt noch eventuelle CPU-Latenz-Peaks, die vielleicht in der Durchschnitts-Berechnung untergehen...
Ich möchte nochmal genaueres zu den Lag-Problemen sagen: In Call of Duty 4 gibt es für den Client ein sogenanntes Lag-O-Meter; dieses zeigt seit ein bis zwei Wochen hin und wieder und dann auch nur bei einzelnen Clients "rote, schmale Säulen" im Netzwerk-Latenz-Graphen an. Die Netzwerkverbindung zum Server (UDP-Pseudo-Verbindung) wird also mehrere Male pro Sekunde kurz unterbrochen. Ich deute das so, dass einige UDP-Pakete tatsächlich nicht ankommen. Ja, ich weiß, UDP garantiert keine Ablieferung, allerdings trat das Problem wie gesagt vor ein bis zwei Wochen noch nicht auf. Merkwürdig ist auch, dass das Problem, wie schon gesagt, scheinbar nicht bei allen Clients gleichzeitig auftritt, sondern nur einzeln. Als ich selbst den mysteriösen Packet-Loss zu spüren bekam, habe ich probeweise kurzzeitig die Server-Firewall komplett abgeschaltet. Daran liegt es nicht.

Das was du geschrieben hast d4f, werden wir so schnell wie möglich machen! :)

//edit: So, gemacht:

Ausgabe von
# atop 1 10

Als Link auf 'ne Externe Seite: http://pastebin.com/dKDeSHkY
 
Last edited by a moderator:
Hmm 550ns ist eigentlich ein guter Wert, sicher dass zu diesem Augeblick die Probleme (Lag, ...) bestanden? 53'000ns ist ein Normalwert bei nicht-priorisierten Tasks, somit ist der Kernel auch nicht ueberlastet.

Bei RT besteht immer das Risiko dass der Kernel sich selbst unterbricht um die Pseudo-Echtzeit der Prozesse erfuellen zu wollen.
Da diese aber wieder staendig Kernelanfragen schicken welche von anderen unterbrochen werden ist das so eine Sache... =D
Allerdings sollte in einer solchen Schleife der IRQ hoeher sein und der 2. Test mit dem Latenz-Messer bedeutend "schlimmere" Werte ausgeben.

Ich kann zum Augenblick des atop's keine Probleme im System finden.
 
Back
Top