Crosshair verzieht beim Connecten eines Spielers

[cl4ym4n]

Sers....

Ich habe auf einem unserem Server - speziell: unserem Sniper-Server (Jaymod 2.1.7) - mittlerweile bereits zum zweiten Mal eine merkwürdiges Ereignis vernommen. Wenn ein bestimmter Spieler connected, verzieht es bei allen restlichen Spielern das Crosshair nach oben oder unten.

Es ist im Prinzip so, als ob man die Maus arg verreisst und dann in Richtung Himmel/Boden schaut.
Für 1-2 Sekunden lässt sich die Maus nicht bewegen
Es tritt momentan auch nur auf, wenn ein spezieller Spieler connected, ansonsten funktioniert das alles einwandfrei.

Wir können uns nicht erklären, was dafür verantwortlich ist, dass ein einzelner Spieler auf so eine seltsame Art und Weise in das Servergeschehen eingreift und auch die Suche bei Google hat leider nichts Hilfreiches zu dem Problem geliefert.

Hat irgendjemand von euch vllt. auch schon mal diese Erfahrung gemacht oder ansatzweise eine Idee, was dafür verantwortlich sein könnte?

[silver]

hab ich ehrlich gesagt noch nie gehört. sehr merkwürdig. cheater könnt ihr ausschließen?

[WoodSTokk]

Dieses Verhalten kenne ich, ist mir aber nie aufgefallen, daß das passiert wen ein Spieler connected.
Ein Cheat kann es nicht sein da jeder Spieler beim connecten eine eindeutige Challenge bekommt, mit der jedes Paket der Verbindung signiert wird. Es ist nicht möglich das ein Spieler die Challenge eines anderen Spieler irgendwie bekommt.
Das heisst aber auch, daß die Pakete die die Spieler nach ober/unten sehen lassen, wirklich vom Server kommen (und ich dachte immer es liegt am Maus-Treiber).
Wenn es also am Server liegt, kann es nur die Software (ET) oder die Hardware sein.
Nachdem es euer Server ist, kannst du uns da etwas über die Hardware und Config sagen?
Welche CPU ist verbaut?
Wie stark ist die CPU belaset?
Wieviel Speicher bekommt ET beim starten?
Wie schnell ist der Server am i-net angebunden?
Welches OS läuft am Server?
Wieviel Prozesse laufen sonst noch drauf?
Wie hoch ist die durchschnittliche Last?

Ich denke da an das Szenario wenn ein Spieler connected (challenge berechnen, Gamestate übertragen, etc...), das kurz eune Spitzen last an der CPU anliegt, oder der TCP-Stack kurz überläuft, oder oder oder .....

Ist es immer der selbe Spieler (selbe UID) oder immer der 20 Spieler der connectet?

hmmm, da ist echt alles möglich

mfG WoodSTokk

[cl4ym4n]

Silver... Hacks schliesse ich mal - rein vom Zuschauen her - aus, da der Spieler weder auffällig lange irgendwelche Wände angeschaut, noch übermäßig viel/gut getroffen hat....stinknormaler Durchschnittsspieler, der vermutlich nichtmal ahnt, dass er da den Server auf den Kopf stellt...^^

Das heisst aber auch, daß die Pakete die die Spieler nach ober/unten sehen lassen, wirklich vom Server kommen (und ich dachte immer es liegt am Maus-Treiber).

Im Jaymod-Forum habe ich vorhin auch noch einen Beitrag entdeckt, der genau dieses Problem behandelte...
Dort wurde ebenfalls auf die Maustreiber hingewiesen, was ja aber wohl recht hinfällig ist, wenn es bei allen Spielern auftritt.

Welche CPU ist verbaut? -> Intel Core2Quad E6600 - 4*2400 MHz, 4Gig DDR-2 RAM Kingston reg. ECC
Wie stark ist die CPU belaset? -> Beim Sniper-Server um die 7 Prozent
Wieviel Speicher bekommt ET beim starten? -> Hunkmegs 512MB, Zonemegs 120MB
Wie schnell ist der Server am i-net angebunden? -> 100Mbit FD
Welches OS läuft am Server? -> Linux Debian 4.0 64 Bit (Etch)
Wieviel Prozesse laufen sonst noch drauf? -> Inkl. der Debian-Prozesse insgesamt rund 135...
Wie hoch ist die durchschnittliche Last? ->

Code: Alles auswählen

top - 01:22:29 up 19 days,  6:01,  1 user,  load average: 1.26, 0.66, 0.41 
Tasks: 133 total,  1 running, 132 sleeping,  0 stopped,  0 zombie 
Cpu(s):  6.5%us,  0.3%sy,  0.0%ni, 93.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st 
Mem:  2827800k total,  2809348k used,    18452k free,    36860k buffers 
Swap:  987956k total,    11504k used,  976452k free,  724296k cached

(Achja: der zeigt nicht die vollen 4Gig RAM an, weil ein Asus-Board verbaut ist, das nicht die kompletten 4Gig zuweisen kann.)

Ist es immer der selbe Spieler (selbe UID) oder immer der 20 Spieler der connectet?

Bei diesem Spieler habe ich da nicht so drauf geachtet...
Vor mehreren Wochen hatten wir aber auch bereits so einen Kandidaten und bei ihm war es so, dass es - unabhängig von der Anzahl der Spieler - immer dann passierte, wenn er connected ist...
Dürfte sich bei dem jetzigen wohl auch so verhalten.

[Mad Max(GER)]

Du meinst, wenn jemand bestimmtes connectet guckt man in die Luft und vll. tritt man noch dazu ?!?

Code: Alles auswählen

Spieler mit extended ASCII-2 Zeichen hatten beim Verbinden einen Kick oder Hans-Guck-In-die-Luft Bug verursacht.

kein Cheat/Hack.... die auf eurem Server befindliche Version kommt damit net klar!

Mfg
Mad Max

[RTCW-zocker]

ich hatte das jetzt auch paar mal in letzter zeit versuch mal eine andere maus ich habe mir eine neue geholt und seit dem
zieht das crosshair nicht mehr nach oben :>

Aber es kann auch sein bei manchen maps sind kleine bugs z.b. cortex sprängt man die große tür zieht das corsshair auch nach oben und man schießt automatisch

[cl4ym4n]

Du meinst, wenn jemand bestimmtes connectet guckt man in die Luft und vll. tritt man noch dazu ?!?

Code: Alles auswählen

Spieler mit extended ASCII-2 Zeichen hatten beim Verbinden einen Kick oder Hans-Guck-In-die-Luft Bug verursacht.

Äusserst interessant.
Der Bug war mir noch nicht bekannt.

Nichtsdestotrotz stell sich mir die Frage, welches Zeichen dafür verantwortlich sein soll: _.*.Name.*._
Zumal es ja nicht unbedingt ungebräuchliche Zeichen sind, die der Spieler im Namen verwendet.

kein Cheat/Hack.... die auf eurem Server befindliche Version kommt damit net klar!

Die Version von was...?
...von ET?
...des OS?
...der Map?

Interessant ist, dass ich einen meiner Squaddies dazu genötigt habe, mit haargenau dem selben Namen zu connecten.
Seltsamerweise passierte dann absolut nix... kein Verziehen, kein Schuss, kein gar nichts...

Deswegen stellt sich mir die Frage, warum das nun so ist, zumal ja dann wohl noch weitere Faktoren dafür verantwortlich sein müssen, wenn es nicht allein am Namen liegt?

[silver]

vermutlich wirds ein zeichen für das färben des namens sein. da gibts ja ein paar zeichen die die selbe farbe erzeugen.

[WoodSTokk]

Hmmm, das mit dem ASCII-Zeichensatz klingt blausibel.
Es kommt hier nicht auf den Namen an, sondern auf die Einstellung des Servers und des Clients.
Hast du mal nachgesehen auf welchen OS der Spieler spielt der das Problem verursacht?

Die Einstellung vom Server siehst du mit 'locale'.
Hier zum Beispiel meine Ausgabe:

Code: Alles auswählen

woodstokk@woodstokk:~$ locale
LANG=de_AT.UTF-8
LC_CTYPE="de_AT.UTF-8"
LC_NUMERIC="de_AT.UTF-8"
LC_TIME="de_AT.UTF-8"
LC_COLLATE="de_AT.UTF-8"
LC_MONETARY="de_AT.UTF-8"
LC_MESSAGES="de_AT.UTF-8"
LC_PAPER="de_AT.UTF-8"
LC_NAME="de_AT.UTF-8"
LC_ADDRESS="de_AT.UTF-8"
LC_TELEPHONE="de_AT.UTF-8"
LC_MEASUREMENT="de_AT.UTF-8"
LC_IDENTIFICATION="de_AT.UTF-8"
LC_ALL=

Interessant wäre auch die ausgabe von:
--> cat /proc/cpuinfo
--> uname -a

Das mit dem Speicher lässt sich beheben, indem man einen Kernel mit BIGMEM-Erweiterung verwendet.
Mit dieser Erweiterung kann Linux auch unter 32Bit bist zu 64GB-Ram adressieren.

Nun zu deiner Top-Ausgabe:

Code: Alles auswählen

load average: 1.26, 0.66, 0.41

Die Belastung ist niedrig, das kann es also nicht sein.

Code: Alles auswählen

Tasks: 133 total,  1 running, 132 sleeping,  0 stopped,  0 zombie

Im Speicher sind zwar einige Tasks, es läuft aber nur einer, was auch die niedrige load wiederspiegelt.

Code: Alles auswählen

Cpu(s):  6.5%us,  0.3%sy,  0.0%ni, 93.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Auch hier sieht man, daß sich die CPU langweilt.

Code: Alles auswählen

Mem:  2827800k total,  2809348k used,    18452k free,    36860k buffers 
Swap:  987956k total,    11504k used,  976452k free,  724296k cached

Hier wird es aber interessant.
Der RAM-Speicher ist ziemlich voll und es wird bereits geswaped!
Es ist zwar nicht viel, aber swapen ist immer ein Performanceeinbruch.

Versucht mal einen Kernel mit Bigmem-Erweiterung, damit auch der Rest des Speichers verwendet werden kann.

mfG WoodSTokk

[cl4ym4n]

Hast du mal nachgesehen auf welchen OS der Spieler spielt der das Problem verursacht?

Bisher nicht... er war seitdem auch nicht mehr auf dem Server.
Eine Lösung hier wäre da aber trotzdem nicht schlecht, zumal es ja durchaus sein kann, dass irgendwann andere Spieler connecten, die das selbe Problem verursachen...

Die Einstellung vom Server siehst du mit 'locale'.

Code: Alles auswählen

debian:~# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

--> cat /proc/cpuinfo

Code: Alles auswählen

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 4802.49
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 4799.95
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 4800.03
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 4800.03
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

--> uname -a

Code: Alles auswählen

Linux debian 2.6.22.1 #1 SMP Thu Aug 30 16:47:06 CEST 2007 x86_64 GNU/Linux

Das mit dem Speicher lässt sich beheben, indem man einen Kernel mit BIGMEM-Erweiterung verwendet.
Mit dieser Erweiterung kann Linux auch unter 32Bit bist zu 64GB-Ram adressieren.
[...]
Der RAM-Speicher ist ziemlich voll und es wird bereits geswaped!
Es ist zwar nicht viel, aber swapen ist immer ein Performanceeinbruch.

Versucht mal einen Kernel mit Bigmem-Erweiterung, damit auch der Rest des Speichers verwendet werden kann.

Den Kernel upzudaten is ja wohl ne heikle Angelegenheit... was muss man dabei unbedingt beachten , um sich nicht gleich den komplette Root zu schrotten? Gibts da vllt. irgendwo brauchbare Tutorials/FAQs zum reibungslosen Update des Kernels?

Und an dieser Stelle vllt. noch die Frage...
An sich hat der Root, denk ich, ausreichend Potenzial, was ja u.U. gar nicht richtig ausgereizt wird...
Gibts noch andere/weitere Optionen/Tricks/Kniffe, um den Root für die ET-Gameserver zu optimieren?

Danke auf jeden Fall erstmal soweit für die Antworten.

[WoodSTokk]

Hehehe, jetzt weis ich warum sich die CPU langweilt, das is ja ein Quad-Core

Das mit dem Kernel kannst du vermutlich sein lassen, da ist schon ein 2.6.22.
Ich vermute dein Rechenzentrum hat da einen eigenen Kernel gebaut speziell für die Kiste.
Im Debian 4.0 stable (Etch) ist momentan der 2.6.18 drin, oder ein 2.6.22 über BPO.
Im Debian testing (Lenny) ist ebenfalls ein 2.6.22.
Aber in keinen der beiden gibt es einen 2.6.22.1.
Auch das Speicherproblem (Mem: 2827800k total obwohl es 4GB sein sollen) deuten auf ein selbst kompilierten Kernel hin.
Das Kernelpaket das ich meinte wäre in deinem Fall linux-image-2.6.22-4-686-bigmem.
Aber ich vermute das Rechenzentrum hat sich dabei etwas gedacht.
Du könntest sie aber mal kontaktieren ob dieser Kernel sein muss (wegen spezieller Hardware) oder ob du einen anderen einspielen darfst (oder ob sie dir das gleich machen).
Vieleicht ist aber nur schon länger kein Uptade gemacht worden.
Der Kernel wurde am 30 August 2007 gebaut.
Die installierte Debian-Version siehst du mit:

Code: Alles auswählen

cat /etc/apt/sources.list

Da stehen die Server drin, von wo sich dein Debian die Updates holt und am Ende jeder Zeile steht die Release.
Ein Update machst du mit:

Code: Alles auswählen

aptitude clean
aptitude update
aptitude upgrade

Wenn da ein neuer Kernel installiert wird, macht Debian selber alles damit er beim nächsten Reboot läuft.
Nur den Reboot musst du selber händisch anstossen mt:

Code: Alles auswählen

shutdown -r now

Als Zeichencodierung verwendest du UTF-8, das ist okay so ... ist Standard unter Linux.
Win2K/XP/Vista unterstützen diesen auch (obwohl sie ihn IMHO selber nicht anwenden).
Sollte es also tatsächlich am Zeichensatz liegen, kann es nur ein altes Win98/ME sein.
Diese DOS-gemurkse verstehen UTF-8 nicht.
MacOS kann ich mit Sicherheit ausschliesen, da es UNIX ist (so wie Linux).

mfG WoodSTokk

[cl4ym4n]

Was den BIGMEM-Kernel bzw. das 4Gig-Problem angeht, schrieb uns der Support:

[...] da fehlt lediglich ein remapping im Bios vom System damit die 4GB angezeigt werden, sonnst nix, da es ein 64 Bit System ist braucht man kein Bigmem Patch, das hat man vielleicht vor 2 Jahren gebraucht, ist also vollkommen veraltet. [...]

Seitens des Supports wurde das Remapping auf Montag angesetzt.
Die Frage ist ja, ob das letztlich was bringt, denn auch, wenn die 4Gig im System nicht angezeigt werden, müssten sie ja theoretisch trotzdem komplett verwendet werden, was ja momentan genauso wenig der Fall ist: es sind ja nur rund 2.7 Gig...
Mal sehen, was das bringt... die Werte werd ich, als Vergleich, hier dann mal posten.
Eventuell muss man dann ja ne Speicher-Aufrüstung in Betracht ziehen...

Wir hatten auch in Erwägung gezogen, von 64Bit u.U. zurück auf 32Bit zu gehen, weil wir gelesen haben, dass 32Bit-System wohl stabilere - und vorallem auch mehr - FPS liefern...
Laut der Aussage des Supports ist das ja aber wohl hinfällig, oder?

Die installierte Debian-Version siehst du mit:

Code: Alles auswählen

cat /etc/apt/sources.list

Code: Alles auswählen

 debian:~# cat /etc/apt/sources.list
#
deb http://ftp.de.debian.org/debian/ etch main
deb-src http://ftp.de.debian.org/debian/ etch main

deb http://security.debian.org/ etch/updates main contrib
deb-src http://security.debian.org/ etch/updates main contrib
debian:~#

-----
-----

Zum Swap-Problem hier die Antwort vom Support:

Das swappen des Speichers kann man mit regelmäßigen restarts des kompletten roots vermeiden, (einmal die woche oder so) aber das verursacht kein laggen und die cpu langweilt sich, wie auch die user im forum bestätigen, ergo ein reines config problem und deshalb leider nicht mehr unser part. das remapping des speichers habe ich für montag veranlasst.

Mit 'reines config problem' kann er ja wohl nur die Configs unserer ET-Server meinen.
Nur können wir uns da nicht so wirklich vorstellen, was damit jetzt gemeint ist - zugewiesener Speicher vllt.?

Hier mal die Start-Parameter für unseren NoQuarter (64 Slots) und unseren Jaymod Sniper-Server (32 Slots):

Code: Alles auswählen

PARAMS="+set vm_game 0 +set net_port 27964 +set fs_basepath /home/nqpublic/server9 +set fs_game omnibot +set fs_game noquarter +exec server.cfg +set com_Hunkmegs 768 +set com_zonemegs 120 +set sv_punkbuster 1"

PARAMS="+set vm_game 0 +set net_port 27962 +set fs_basepath /home/sniper/server3 +set fs_homepath /home/sniper/server3 +set fs_game omnibot +set fs_game jaymod +exec server.cfg +set com_Hunkmegs 512 +set com_zonemegs 120"

Gibt es da irgendwelche empfohlenen Richtangaben, was das Verhältnis von Slots zu zugewiesenem Speicher angeht?
Wir haben vorhin mal die Speicherwerte aller unserer Server zusammengezählt und kamen da (zu unserer eigenen Überraschung) doch leicht auf etwas über 4Gig, die in den Startparametern insgesamt zugewiesen werden. Wir haben 9 Server: 3 davon sind passwortgeschützt (Test-/Warserver, eigtl. durchweg unausgelastet), 2 davon eigentlich kaum benutzt und der Rest sind halt die anderen Public-Server, auf denen - bis auf den Trickjump-Server - überall Bots laufen.

Insofern ist zwar mehr zugewiesen, als tatsächlich vorhanden ist, jedoch wird der Speicher von den Servern nicht ansatzweise so sehr ausgelastet, wie sie - laut den Startscripten - zur Verfügung hätten.....insofern kann das doch eigentlich keine Auswirkungen auf die Performance haben, oder?


-----
-----

Und dann noch eine Frage (und ne halbe ) zum Schluss...
Über das Kundeninterface des Roots können wir direkt die Server einrichten (was wir aber nicht gemacht haben).
Das Seltsame daran ist jedoch, dass hinter der Portzuweisung offensichtlich ein System steckt.
So könnten wir, wenn wir bspw. 3 Server über das Interface installieren würden, nicht die Ports 27960, 27961 und 27962 benutzen, sondern lediglich 27960, 27966 und 27972....

Im Klartext: Die Ports lassen sich nur in 7er-Schritten festlegen.
Eine durchgängige Port-Liste, wie wir sie im Moment haben, wäre über das Interface also gar nicht möglich gewesen.
Wir haben uns mal ein bisschen schlau gemacht und stellenweise rausgelesen, dass diese Abstände in den Ports durchaus empfehlenswert sind, da hierdurch die Performance der einzelnen Server auch noch ein wenig gesteigert werden kann... Ist da was dran, oder alles nur Humbug?

Und falls ja (hier die halbe Frage ):
Würde es noch mehr Performance bringen, wenn wir uns zusätzliche IPs für den Root kaufen, sodass zumindest unsere großen Pubs auf einzelnen IPs laufen und vllt. die Masse an Paketen nicht über eine einzige IP, sondern über mehrere geleitet wird?

-----
-----

An dieser Stelle nochmals: Danke für die Antworten.
Wir wissen deine Hilfe ehrlich zu schätzen! :]

[WoodSTokk]

Bezüglich BIGMEM:

Ich dachte mir schon daß es eigendlich ein Intel Xeon ist. Also eine 64-Bit CPU.
Wenn man diese CPU mit einem 64-bit Kernel betreibt, braucht man natürlich keine BIGMEM-Erweiterung, da der Kernel selbst schon bis 64GB-RAM Adressieren kann.
Diese BIGMEM-Erweiterung wird nur vom 32-bit Kernel verwendet wenn er mehr als 3,2 GB-RAM verwalten soll.
Nachdem deine CPU als 'model name: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz' erkannt wird, nehme ich an es handelt sich um einen 32-bit Kernel.

Wie auch immer, warten wir mal Montag ab ob sich was tut.

Code: Alles auswählen

deb http://ftp.de.debian.org/debian/ etch main

Alles klar, es handelt sich hier um ein Debian 4.0 stable (Etch).
Der Kernel muss daher entweder selbst kompiliert sein, oder es ist ein alter BPO-Kernel.

Das swappen des Speichers kann man mit regelmäßigen restarts des kompletten roots vermeiden, (einmal die woche oder so) aber das verursacht kein laggen .....

Von wem stammt den diese Aussage???
Programme die nur Daten in den Speicher laden und gelegendlich lesen, macht Swap überhauptnichts aus.
Ein ET-Server läuft aber die ganze Zeit aktiv und muss schnell lesen können.
Wenn dann Teile seines Speichern ausgelagert sind, kann er die Daten nicht mehr so schnell lesen wie er sie braucht.
Zum Vergleich:
Der Zugriff auf Platte hat eine Latenz (Zeitverzögerung) von etwa 5ms (Millisekunden)
Der Zugriff auf den RAM hingegen nur etwa 5µs (Mikrosekunden)
Vom RAM kann als 1000x schneller gelesen werden als vom Swap.
Programmen die nicht Zeitkritisch arbeiten (Web-Server, Mail-Server, Datenbanken, etc...) macht das nichts aus.
Ein Game-Server ist aber voll auf Performance ausgelegt und er muss die Daten so schnell wie möglich liefern können. Das ist eine Zeitkritische Anwendung.

mfG WoodSTokk

[cl4ym4n]

So...sry für die späte Antwort...war bissl stressig die letzten Tage...

Von wem stammt den diese Aussage???

Die Aussage kam vom Support des Root-Anbieters.

Das Remapping wurde auf Grund von irgendwelchen Problemen in deren Admincenter noch nicht durchgeführt.
Allerdings hat uns der Support ein anders Angebot gemacht:

[...] würde dir den Server komplett neu aufsetzen und nen kernel basteln und dann mit dir gemeinsam testen und das umsonst [...]

Klingt erstmal gut... das Angebot werden wir so auch annehmen.
Wenn wir aber schon dabei sind, wärs interessant, zu wissen, ob sichs nicht u.U. lohnen würde, den Rest auch noch direkt mitzumachen...

Im Klartext hatten wir überlegt, dann eventuell im gleichen Zug noch weitere IPs dazubestellen (wie in meinem letzten Post bereits erläutert) und u.U. noch nen weiteren Riegel RAM dazuzukaufen. Wenn danach dann die Performance-Probleme weiterhin bestehen, stellt sich die Frage, was da letztlich noch zu machen ist...


Die ganze Aktion ist für Mitte nächster Woche angesetzt...
Hast du bis dahin vllt. noch irgendwelche Infos/Ratschläge bezüglich der IP/Port/Startparameter-Geschichte aus meinem letzten Post?

Thx in advance.

[WoodSTokk]

Ja, hab noch einige Ideen ... leider habe ich selber wenig Zeit und konnte nicht alles in meinem Posting schreiben.

Hier mal die Start-Parameter für unseren NoQuarter (64 Slots) und unseren Jaymod Sniper-Server (32 Slots):

Code: Alles auswählen

PARAMS="+set vm_game 0 +set net_port 27964 +set fs_basepath /home/nqpublic/server9 +set fs_game omnibot +set fs_game noquarter +exec server.cfg +set com_Hunkmegs 768 +set com_zonemegs 120 +set sv_punkbuster 1"

PARAMS="+set vm_game 0 +set net_port 27962 +set fs_basepath /home/sniper/server3 +set fs_homepath /home/sniper/server3 +set fs_game omnibot +set fs_game jaymod +exec server.cfg +set com_Hunkmegs 512 +set com_zonemegs 120"

Gibt es da irgendwelche empfohlenen Richtangaben, was das Verhältnis von Slots zu zugewiesenem Speicher angeht?
Wir haben vorhin mal die Speicherwerte aller unserer Server zusammengezählt und kamen da (zu unserer eigenen Überraschung) doch leicht auf etwas über 4Gig, die in den Startparametern insgesamt zugewiesen werden. Wir haben 9 Server: 3 davon sind passwortgeschützt (Test-/Warserver, eigtl. durchweg unausgelastet), 2 davon eigentlich kaum benutzt und der Rest sind halt die anderen Public-Server, auf denen - bis auf den Trickjump-Server - überall Bots laufen.

Insofern ist zwar mehr zugewiesen, als tatsächlich vorhanden ist, jedoch wird der Speicher von den Servern nicht ansatzweise so sehr ausgelastet, wie sie - laut den Startscripten - zur Verfügung hätten.....insofern kann das doch eigentlich keine Auswirkungen auf die Performance haben, oder?

Genau da liegt der Hase im Pfeffer.
Mit '+set com_Hunkmegs' sagst du dem Server wieviel Speicher er sich nehmen soll.
Und das tut er auch, auch wenn er ihn nicht braucht.
Die Slots sind dabei unerheblich. Der Server braucht den Speicher nur um die Collision-Map zu laden (3D-Welt).
Da dem Server egal ist ob ein Spieler seinen Kopf gegen Watte oder Beton schlägt, läd er keine Texturen.
Der Server muß nur wissen wo ein Hindernis (Objekt) ist, damit er weiß, wann ein Spieler wo dagegen läuft.
Der Server läd auch keine Sounds (es hört ihm sowieso niemand zu).
Deshalb braucht ein Server viel weniger Speicher als ein Client.
Ein ETmain-Server kommt mit 32MB-Ram völlig aus.
Mehr braucht er nur, wenn große Costum-Maps geladen werden, die eine grössere Collision-Map haben.
Wieviel Speicher jetzt noch der Mod und die Bots brauchen, weiß ich leider nicht, kann aber nicht viel sein.
Vieleicht findest du was in der Doku zu den Mods und Bots.
Ich würde empfehlen, du startest mal die Server mit 64MB-Ram und schaust ob sie starten.
Wenn sie laufen, lade mal die grösste Map die du am Server hast.
Sollte es zuwenig Speicher sein, stürtzt der Server sowieso ab und hinterlässt einen Eintrag im Log.
Wenn das passiert, dann erhöhe den Speicher in 2MB oder 4MB-Schritten, bis er die Map ohne murren läd.

WICHTIG: Der Speicher muß immer eine gerade Zahl sein!
Setze 'com_Hunkmegs' niemals auf einen ungeraden Wert (65 oder so). Die Engine mag das garnicht!

Nochwas fällt mir auf.
Du setzt 2x 'fs_game' beim starten. Das ist unnötig.
'fs_game' musst du nur auf den Mod setzen. Der Mod läd die Bots selber nach, da es in seiner Config so angegeben ist.

Code: Alles auswählen

PARAMS="+set vm_game 0 +set net_port 27964 +set fs_basepath /home/nqpublic/server9 +set fs_game noquarter +set com_Hunkmegs 64 +set com_zonemegs 16 +set sv_punkbuster 1 +exec server.cfg"

PARAMS="+set vm_game 0 +set net_port 27962 +set fs_basepath /home/sniper/server3 +set fs_homepath /home/sniper/server3 +set fs_game jaymod +set com_Hunkmegs 64 +set com_zonemegs 16  +exec server.cfg"

Und dann noch eine Frage (und ne halbe ) zum Schluss...
Über das Kundeninterface des Roots können wir direkt die Server einrichten (was wir aber nicht gemacht haben).
Das Seltsame daran ist jedoch, dass hinter der Portzuweisung offensichtlich ein System steckt.
So könnten wir, wenn wir bspw. 3 Server über das Interface installieren würden, nicht die Ports 27960, 27961 und 27962 benutzen, sondern lediglich 27960, 27966 und 27972....

Im Klartext: Die Ports lassen sich nur in 7er-Schritten festlegen.
Eine durchgängige Port-Liste, wie wir sie im Moment haben, wäre über das Interface also gar nicht möglich gewesen.
Wir haben uns mal ein bisschen schlau gemacht und stellenweise rausgelesen, dass diese Abstände in den Ports durchaus empfehlenswert sind, da hierdurch die Performance der einzelnen Server auch noch ein wenig gesteigert werden kann... Ist da was dran, oder alles nur Humbug?

Davon hab ich noch nie gehört und kann es mir auch nicht vorstellen.
Versuch es doch aus

Und falls ja (hier die halbe Frage ):
Würde es noch mehr Performance bringen, wenn wir uns zusätzliche IPs für den Root kaufen, sodass zumindest unsere großen Pubs auf einzelnen IPs laufen und vllt. die Masse an Paketen nicht über eine einzige IP, sondern über mehrere geleitet wird?

Glaub ich auch nicht, daß das was bringt.
Die Pakete kommen ja sowieso über eine Leitung rein.
Wenn die dann nur anders adressiert sind, macht der Netzwerkkarte, dem Host und den Server nichts aus.

mfG WoodSTokk