spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

So habe das Projekt ein wenig umgebuat. Man kann nun den Client über die config.lua steuern. Wie man das ganze nutzt?
Man schreibt in die config.lua, was man gerne getestet haben möchte, startet lokal oder auf einen anderen Rechner den Server (wenn man RakNet und TCP testen will, muss man 2 getrennte Server starten. ggf. muss man eine Portweiterleitung einbauen usw.) . Der Port ist 5512 (sowohl für TCP als auch für RakNet). Während der test läuft, werden die aktuellen Messergebnisse ausgegeben und am Ende werden alle Testergebnisse nochmal zusammenfassend dargestellt.
Ich werde die Tage mich mal ran machen und entsprechende Messreihen aufnehmen. Ansonsten steht noch die Portierung auf Posix-Systeme aus. Auch könnte man die Ergebnisse vielleicht grafisch besser darstellen, aber dafür reichte erstmal die Zeit nicht. Interessant wäre auch eine Messung von der Systemauslastung und dem Datenverkehr, nur dafür habe ich noch keine portable Lösung parat.

Ich hoffe, dass das Progamm einigen weiterhilft. Wer Verbesserungen vorschlagen oder selbst was am Code machen will, braucht einfach nur bescheid sagen. Wer repräsentative Messungen macht, kann sie ja hier posten. Aber bitte mit entsprechender Berschreibung der Rahmenbedingungen.

P.S: Ich werde das ganze, wenn es Messergebnisse und Portierung gibt, dann unter zlib-Lizenz oder eine ähnliche Lizenz stellen.

Beispielwerte für eine belastete Leitung (Server adsl 1000, Leitung voll ausgelastet, Client adsl 2000, Leitung komplett frei)

Zitat

RakNet Pingtest (unreliable, interval 100, bytes per packet 50, packets 1100)
result: (831.963+-54.102 ms using 1096 values

RakNet Synctest (interval 100, instances 100, packets 1100)
result: (15525.3+-128.685) ms using 5660 values

Netlib Pingtest (no compression, synchronizied callback, interval 100, bytes per packet 50, packets 1100, nagle no)
result: (568.256+-15.0145) ms using 1100 values

Netlib Synctest (compression, synchronizied callback, direct update, sendinterval 100, updateinterval 5, instances 100, packets 1100, nagle no)

result: (186.048+-0.358305) ms using 5815 values
press key to exit

Beispielwerte für eine unbelastete Leitung (Server adsl 1000, Leitung fast komplett frei, Client adsl 2000, Leitung fast komplett frei)

Zitat

RakNet Pingtest (unreliable, interval 100, bytes per packet 50, packets 1100)
result: (671.486+-57.6465) ms using 1100 values

RakNet Synctest (interval 100, instances 100, packets 1100)
result: (648.212+-21.0289) ms using 5660 values

Netlib Pingtest (no compression, synchronizied callback, interval 100, bytes per packet 50, packets 1100, nagle no)
result: (94.7536+-1.499) ms using 1100 values

Netlib Synctest (compression, synchronizied callback, direct update, sendinterval 100, updateinterval 5, instances 100, packets 1100, nagle no)
result: (113.526+-1.13866) ms using 5706 values
press key to exit

Seltsam ist, dass die ersten Paket beim Raknet ping ewig brauchen. Ggf. erklärt das diese hohen Werte. Wenn jemand ne Idee hat, wie man diesesn "Anfanglag" wegbekommt, immer her damit!

Habe die Ausgabe nochmals überarbeitet. Sollte nun deutlicher zu sehen sein, was abgeht.

Da stimme ich dir nicht zu.
RakNet bietet ebenfalls die Option um die Reihenfolge und die Sicherheit abzuschalten. Wenn du dir die Ausgabe wirklich angeschaut hättest, solltest du das hier gesehen haben: "RakNet Pingtest (unreliable". Ob er auch die Reihenfolge achtet, müsste ich nochmal schauen. Das könnte durchaus ein Fehler von mir sein.
Außerdem handelt es sich bei weitem nicht um reines TCP, was eigentlich ein kurzer Blick auf die Quelltextdateien hätte verraten können.
ENet würde ich gerne mit in die in die Testreihe aufnehmen, nur dafür fehlt es mir an Kenntnissen. Ich hoffe daher einen ambitionierten ENet Nutzer zu finden, der ENet mit in den Test integrieren würde.
Die Tatsache mit dem Paketverlust stimmt bedingt, denn auch TCP hat da sehr gute Mechanismen, die man bei UDP entweder mühsam implementieren oder eben auf Netzwerkmodelle ausweichen muss, die mit Verlusten leben können (Quake ist ein sehr schönes Beispiel, wo was anders asl UDP nicht sonderlcih hilfreich wäre).

Und es gibt tausende von den Artikeln, nur keiner nennt harte Fakten! Ich habe hier echte Messergebnisse aus einer Anwendung, die einem Spiel ähnlich ist. Und ich glaube kaum, dass z.B. Blizzard solche Nasenbohrer sind und nur wegen Faulheit TCP nutzen.
Es stimmt das TCP seine Tücken hat. Wer z.B. nicht weiß, dass bei TCP standardsgemäß Nagle aktiviert ist, wird sich über hohe Verzögerungen ärgern ohne zu wissen woher sie eigentlich kommen.

Ich bin es leid ständig die gleichen Theorien ohne wirkliche belege zu hören. Deshalb enstand auch dieses Projekt, um Fakten zu schaffen. Oder liege ich mit meinen Argumenten voll daneben?

Update. Es gibt nun eine GUI welche am Ende ein Diagramm anzeigt. In jedemfall wird am Ende ein Diagramm und die Ergebnisse als Textform gespeichert. Ein Beispiel könnte ihr oben unter den Links finden.

Update. Gesamtkonzept ein wenig überarbeitet und per Sourceforge.net onlinegestellt. Würde auch gerne ne Rückmeldung bekommen, ob euch sowas überhaupt interessiert, wie intuitiv die Darstellung ist, ob ihr das für aussagekräfig haltet und was ihr von den Ergebnissen haltet (er glaubt, dass ich da rumfälsche, kann gerne den Source laden und nachprüfen/nachmessen).

Naja es gibt schon unterschiede in der Geschwindigkeit. Die Zusammenfassung befindet sich in den txt Dateien (ganz am Ende). Vielleicht sollte ich die Reihenfolge nochmal ändern. Der Traffic lässt sich leider nicht so ohne weiter messen, aber du kannst den Traffic ja einfach per Taskmanager nachverfolgen .
P.S.: Leider habe ich keine Idee, wie ich das mit dem Arbeitsaufwand zum Überprüfen minimieren kann (wohl garnicht).

In wiefern schöner? Die Testergebnisse von den Diagrammen habe ich mit Hilfe eines Rootservers erstellt. Sprich mein PC über Kabel am Router schickte Pakete an den Rootserver auf welchem dann die Server liefen und die Pakete wieder zurückschickten. Das Programm errechnet die benötigte Zeit und speichert diese.

Edit: meinst du wegem dem Traffic? Besser wäre eine "all-in-wounder" Lösung, denn es sollte möglichst einfach gehalten werden, sodass jeder die Tests selbst durchführen kann ohne vorher einen kleinen Netzwerkparkour aufbauen zu müssen.