Archiviert

Dieses Theme ist nun archiviert und für weitere Antworten gesperrt.

Lotte

BF1942 Linux Gameserver auf Dualcore Systemen

Recommended Posts

Hallo Leute,

zum verzweifeln, wir bekommen mit den neueren Linux Distris einfach keinen gescheiten BF42-Server mehr aufgesetzt.

Vielleicht kann jemand helfen bzw. kennt dieses Phänomen und weiß Rat ?

Zunächst zum System:

Hetzner Root, AMD 5600 dual, 4GB

Ausprobiert mit Debian minimal 4.0 32bit, Ubuntu 32 bit, Suse 10.3 32 bit

Debian 64 bit haben wir auch schon probiert, aber damit ließ sich BF42 gar nicht erst starten.

Folgendes passiert:

ich starte den Server mit BFSM/BFRM. Zunächst läuft alles nach Plan und absolut sauber.

Es connecten die ersten Leute. Dabei merkt man, das mit jedem Connect oder Disconnect ein 1/100 sec. kurzer Ruckler bei allen Spielern auftritt, aber man kann ungestört zocken.

Nach dem 3. oder 4 Mapwechsel wird es dann plötzlich unspielbar.

Man läuft durch die Maps als wenn man an einem Gummiband hängt und kommt praktisch überhaupt nicht mehr vorwärts.

TOP zeigt an, dass die CPU-Last permanent über 60% liegt (normal ist unter 20%). RAM 1,5 von 4,0 GB used.

Mit Debian hatten wir dasselbe, jedoch kam da hinzu, dass einige an "diesem Gummiband" hingen und andere Spieler wie Speedy Gonzales durch die Map rasten, also quasi 8x so schnell wie normal.

Wir haben dieses Problem mit EoD 0.80 und geanu dasselbe mit FH 0.7.

Auch ohne BFSM/BFRM, ebenso mit und ohne Firewall, mit und ohne Bots usw. usw.

Habe schon alles möglich durchprobiert, da ich seit 5 Jahren die Server für unseren Clan mache.

Das Google bringt leider auch keine gescheiten Weissagungen, deshalb hoffe ich, dass hier jemand helfen kann, ihr seid die letzte Hoffnung :)

Da ich die MOD (EoD 0.80) selbst gemacht habe, bin ich sicher, dass es nicht an Bugs usw. liegt. Der Debugger läuft nämlich anstandslos durch und im LAN auf einem dedicated Server gibt es absolut keine Probs.

FH-2 mit 64 Slots oder CS:Source laufen auf diesem Server einwandfrei.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hiho,

wir versuchen seit einigen Wochen ein ähnliches Problem mit einem neu angemieteten Server (Athlon X2 4400+ 2 GB / Debian) in den Griff zu bekommen. Wenn ich raten müßte, würde ich von einer Inkompatibilität von BF1942 und neuer Hardware / Betriebssystem ausgehen.

Schau doch bitte einmal in den bfsmd.log-files nach, ob Du gehäuft die folgende Meldung bekommst:

Couldn't send message to console! Ressource temporarily unavailable (11).

Darüberhinaus lohnt es sich, per

top -d 0.2

sich die Prozessorlast mit hoher Updaterate anzusehen, um zu überprüfen, ob der BF1942-Prozeß ggf. den Prozessor voll belastet.

Konfigurationen, die über Jahre hinweg auf langsamerer Hardware problemfrei liefen, verweigern nun die Mitarbeit.

Schöne Grüße

Birdie

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Couldn't send message to console! Ressource temporarily unavailable (11).

Die Meldung haben wir auch.

Aber selbst ohne BFSM läuft es ja nicht.

Die Prozessorlast ist beim Neustart des Servers optimal, erst nach ein paar Mapchanges und insbesondere dann wenn viele Spieler drauf sind taucht das "hängen" auf.

Das sind keine normalen "Lags" !

Hab heute nochmal Debian 64 bit probiert und den Server ohne jeglichen Zusatz gestartet. 30 Min einwandfrei, dann geht die CPU-Last immer höher bis es zum Matrix-Zeitlupeneffekt kommt.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Unser Problem konnte gelöst werden, indem der BF1942-Prozeß fest auf eine einzelne CPU gebunden wurde. Wahrscheinlich wurde der Prozeß nach jedem kurzem Wait einer anderen CPU zugeordnet, so daß interne Counter, die aus dem Prozessor ausgelesen wurden und für die Synchronität notwendig waren, auf verkehrten Werten standen.

Es reicht, wenn der BFSM einmalig auf die korrekte CPU eingestellt wird. Child-Prozesse übernehmen automatisch die CPU-Affinität des aufrufenden Prozesses. Um nun noch den Start des BFSM enstprechend zu automatisieren, genügt es folgenden Code (oder eine enstprechende Abwandlung) zu verwenden:

#!/bin/bash



# Waehle die richtige CPU-Affinitaet aus

# Bitmuster:

# CPU ID 1 2 3 4

#        X - - - => 1

#        - X - - => 2

#        - - X - => 4

#        - - - X => 8

#        - X - X => 10

#        X X X X => 15

PROZESSOR=01



PID=$$



echo ""

echo "Setze CPU-Affinitaet fest auf Maske $PROZESSOR"

echo ""



#

# Bei debian ist "taskset" ein Bestandteil des "schedutils" Pakets

#



taskset -p $PROZESSOR $PID



#

# Dieses Shell-Skript wird nun nur auf den Prozessoren ausgefuehrt,

# die laut PROZESSOR-Variable erlaubt sind. Diese Affinitaet wird an

# alle Prozesse vererbt, die von diesem Skript aus aufgerufen werden -

# also auch an den BFSM und den BF1942-Prozess

#

#

# Fuege hier den Code zum Starten des BFSM ein, z.B.:

#

cd /home/foo

./bfsmd -start -restart -ip XX.XX.XX.XX -port 14667 -daemon -noadmin -nodelay - adminlog -path /home/foo/bf1942

Da es sich bei Eurem Server auch um eine Mehrprozessormaschine handelt, kann ich mir gut vorstellen, daß sich das Problem damit auch lösen lassen könnte. Ich hoffe jedenfalls, daß es hilft.

Schöne Grüße,

Birdie

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Also scheint es unter Linux die gleichen Probleme mit Mehrprozessor-CPUs zu geben, wie unter Windows.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Das wäre zu schön um wahr zu sein.

Mit Taskset habe ich das schonmal probiert, allerdings den Prozeß von bf1942_lnxded einem Kern zugewiesen.

Das funktionierte leider nicht.

Werde es gleich mal mit BFSM probieren ! :)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Genau das selbe Problem habe ich auch. Das Skript habe ich Probiert. Muss man da noch was anpassen? Wie kann man feststellen ob es auf einem Kern läuft? Das ist echt zum Verzweifeln. Die Maschine ist übrigends auch ein Debian 64bit (Etch)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Es funktioniert !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Jemand sollte das "sticky" aka "gepinnt" machen.

Evtl. noch den Titel ändern in BF1942 Linux Gameserver auf Dualcore Systemen.

Das dürfte alle BF1942 Mods betreffen.

Vielen vielen Dank @ Birdie !

Tobias, Du kannst sehen ob es klappt wenn Du in TOP den betr. Prozessor anzeigen lässt ("F" drücken und dann "J"=Last used cpu).

Beim Dualcore gibt es 0 und 1.

Der BFSM Prozess muss auf einem Kern laufen und auf diesem bleiben, dann läuft alles wie auf einem Single Kern, nämlich prächtig.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Die gleichen Probleme hatten wir auch mit unserem Windows-Server, jedoch konnten wir es in unserem Fall mittels eines AMD-Patches lösen. Vielleicht gibt es sowas ja auch für Linux. Übergangsweise hatten wir die Gameserver auch den einzelnen Kernen zugewiesen aber das ist natürlich im Hinblick auf die Lastverteilung nur suboptimal.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich werde es morgen mal ins Wiki und den Thread mit der Anleitung für einen Server mit übernehmen. gepinnt ist es ja.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ok, wenn das bei euch geht, muss das bei mir ja auch gehen..

Irgendwas stimmt glaube ich nicht. Grade war wieder so ein Lag.

Laut "TOP" passt das aber (sieht zumindest so aus)

# Waehle die richtige CPU-Affinitaet aus

# Bitmuster:

# CPU ID 1 2 3 4

- - - => 1

# - X - - => 2

# - - X - => 4

# - - - X => 8

# - X - X => 10

# X X X X => 15

PROZESSOR=01

Hab ich da was Falsch? (Die Kiste ist übrigends auch eine AMD Prozessor)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

@Lotte: Es freut mich, daß das Problem auch bei Euch gelöst ist. Mich hat es einige Nerven gekostet, dieses Problem einzukreisen, da sollen andere eine wenig die Nerven schonen können. Besonders ärgerlich war in meinem Fall, daß ich bereits kurz nach Installation des Servers die Prozesse richtig zugeordnet hatte, aber taskset nicht fest in die Startskripte eingebunden. Als ich dann einmal den BFSM gekillt hatte, um andere Server zu installieren, trat plötzlich das Problem wieder auf ...

@Tobias:

# Waehle die richtige CPU-Affinitaet aus

# Bitmuster:

# CPU ID 1 2 3 4

- - - => 1

# - X - - => 2

# - - X - => 4

# - - - X => 8

# - X - X => 10

# X X X X => 15

PROZESSOR=01

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hat leider nicht zu Funktioniert. Immer noch der Gummibandeffekt da.

#!/bin/bash



# Waehle die richtige CPU-Affinitaet aus

# Bitmuster:

# CPU ID 1 2 3 4

#- - - => 1

# - X - - => 2

# - - X - => 4

# - - - X => 8

# - X - X => 10

# X X X X => 15

PROZESSOR=01



PID=$$



echo ""

echo "Setze CPU-Affinitaet fest auf Maske $PROZESSOR"

echo ""



#

# Bei debian ist "taskset" ein Bestandteil des "schedutils" Pakets

#



taskset -p $PROZESSOR $PID



#

# Dieses Shell-Skript wird nun nur auf den Prozessoren ausgefuehrt,

# die laut PROZESSOR-Variable erlaubt sind. Diese Affinitaet wird an

# alle Prozesse vererbt, die von diesem Skript aus aufgerufen werden -

# also auch an den BFSM und den BF1942-Prozess

#



#

# Fuege hier den Code zum Starten des BFSM ein, z.B.:

#



./bfsmd -restart -ip hier steht eine ip -daemon -adminlog

Fehler drin?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

  • Wer ist Online   0 Benutzer

    Keine registrierten Benutzer online.