Beiträge von Terrorkarotte

    Sowas ist mehr oder weniger Verarsche. Erstens brauch man niemanls mehr als 1000 fps, es bringt einfach nichts, und zweitens ist das so beschrieben Lan feeling von der Anbindung und nicht vom Kernel abhängig.
    Mit ein zwei Kniffen schaffen fast alle Standartkernel auf Anhieb 950-995 fps, je nachdem was für Hardware du hast.
    Da die Messung für die 15k FPS sehr Kurz ist ist davon auszugehen, dass a eine Lib genutzt wird, und b der auf Dauer nicht so konstant sein wird.


    ich nutze den BFS Scheduler, habe noch einige andere Sachen in der Kernelconfig angepasst und erreiche das hier:
    CS 1.6: http://www.fpsmeter.org/p,view;56589.html
    CSS: http://www.fpsmeter.org/p,view;60700.html
    DODS: http://www.fpsmeter.org/p,view;60401.html


    Die 15k FPS kann so ziemlich jeder erreichen: LD_PRELOAD=boosterlib.so ./srcds_run blablub


    Wenn du willst, kann ich dir eine genaue Anleitung etc. geben. Meine ICQ Nummer findest du in meinem Profil.

    Tja das problem bei Suse ist halt, dass die cfgs usw nie da sind, wo andere *nixe sie hinpacken. Am besten eine besser von Usern supportete Distro nehmen, die einem bei sowas dann schnell helfen. Debian, Ubuntu, Gentoo z.b.

    Als erstes solltest du den Server mal absichern. Wenn man starke Passwörter hat ist es zwar kein Sicherheitsrisiko die Standartports zu verweden, dennoch werden diese mit tausenden Anfragen bombadiert. Einfach mal die /var/log/auth.log öffnen. Wenn du dann vom kotzen zurück bist, weil dir so schlecht geworden ist, einfach den Port in der sshd_config abändern und den ssh server neu starten. Das ganze hält dir dann die ganzen Bots vom Hals und das Log bläht sich auch nicht mehr so auf.

    Bei Debianund Ubuntu solltest du nicht mit make arbeiten. Am besten legst du einen weiterenb User an, und installierts die Packete kernel_package und fakeroot. Mit dem User einloggen kernel Dateien runterladen und mit diesem compilen:

    Code
    fakeroot make-kpkg clean && fakeroot make-kpkg --initrd kernel_image kernel_headers


    Das erstellt dir zwei Packete image und headers im drüberliegenden Ordner. Diese kann man als root mit dpkg -i installieren. Auf diese Weise sind Kernel auch ganz einfach über apt-get remove linux-image-kernelnameundversion zu entfernen.


    PS versuch mal anstelle vom RT patch lieber den ck2 patch zum 2.6.32er Kernel. Die 2.6.33 Serie hat bei mir auf dem System rumgemuckt, egal welcher Patch.
    http://kernel.org/pub/linux/kernel/peop ... tches/2.6/

    In beiden Momenten werden sehr viele Daten gesendet, so dass wahrscheinlich die Bandbreite nicht dafür ausreicht -> choke
    Ist ja auch logisch:
    -Explodiert die Bombe fliegen viele Teile rum
    -beim Respawn werden alle zerbrochenen, beschädigten und was auch immer Teile (z.B. Scheiben) der Map wieder in den Ausgangszustand versetzt und die Spieler gerespawnt. Diese ganzen Informationen werden an die Spieler gesendet, was sehr viele Daten sein können.


    In beiden Fällen ist das für den Spielfluß aber nicht weiter tragisch, weil man ja eh keine Spieler bekämpfen kann. Wenn es dich stört erhöhe mal deine rate.

    Je mehr Plugins, desto größer die Chance, dass es zu FPS Drops etc kommt. Normalerweise braucht man nicht Eventscripts und Sourcemod zusammen. Such dir halt die Plugins für entweder Eventscripts, oder Sourcemod zusammen. Und auf gar keinen Fall Mani Admin nutzen, das ist extrem hackanfällig.
    Zum Server/Kernel. HL2 is single threaded, also kannst du mit dem Dual Core 2 Server ohne weiteres laufen lassen, ohne das sie sich beeinflussen. Da es nur 2x 2.20GHz sind, werden schon 32 Slots mit tick 100 und all den Plugins sicher nicht 100% stabil laufen.
    Bei der von dir anversierten Slotzahl solltest du eher mit 66er Tick arbeiten. Des Weiteren musst du beachten, dass nicht alle Maps genügend Spawnpunkte für die Slotzahl haben.
    Wenn du willst, kann ich dir eine .deb meines Kernels geben. Nur ist er dann nicht auf deine Hardware angepasst, sondern hat alles and Treibern und Modulen drinne, was auch der Debian Standart Kernel hat. Hier habe ich ihn z.B. auch auf einem Core 2 Duo eingesetzt: http://www.fpsmeter.org/graph/graph.php?id=32857

    Ich habe meine Kernel mit 100Hz am laufen und habe dennoch 1000fps ;)
    Der trick bei der Sache ist es den high resolution timer in der Kernel Config zu aktivieren "make menuconfig"
    Macht man dies nicht, sind die Server FPS von den Hz abhängig.

    2GB Ram ist auch etwas mit Kanonen auf Spatzen schießen oder? Zeig mir mal den Gameserver, der das auch verbraucht. ~500MB sind doch für hl2 mehr als genug?!
    Wenn ihr eure Hardware selber zusammenstellt und nicht mietet, kann man da doch viel Geld sparen?!

    Es ging nicht um Quelloffen oder nicht. Wenn etwas unter der GNU/GPL veröffentlicht wird, verplfichtet es alle, die das ganze oder Teile davon bei sich einbauen, sein Ergebnis unter selbiger zu veröffentlichen. Letzteres war jedenfalls das letzte mal, als ich nachgeschaut habe nicht der Fall.

    Wenn man Code der GNU/GPL nutz, muss man sein geschreibsel dann doch auch unter selbiger veröffentlichen?! Er hat es unter Berkley gehabt, der FPS Teil wurde unter GNU/GPL veröffentlicht, wenn ich da richtig gelesen hatte.


    Der Aktuelle CK Patch stellt keinen Zusätzlichen zur verfügung, der ersetzt den CFS "Complete Fair Scheduler" durch den BFS "Brain Fuck Scheduler" Bei hlds führen pb2 tic 2500 zu keiner Beschleunigung. pb3 und tic > 1100 ja. Ich habe die Server da entweder mit pb2 @ 2500 oder pb3 @ 1001 am laufen. Die FPS sind stabil, Beschwerden gab es keine einzige, auch nicht bei ESL Liga wars.

    Die Antworten sind Bröckchenweise in http://developer.valvesoftware.com versteckt
    Zusammengefasst:
    "Choke" ist ein reines Client Problem, so lange du nicht zu hohe Rates erzwingst. Choke tritt auf, wenn die maximale Bandbreite "rate" niedriger ist, als die cl_cmd/updaterate benötigt.
    "Loss" bedeutet, dass Daten auf dem Weg von deinem Client zum Server verloren gehen. Im Regelfall wird Loss durch Probleme in der Verbindung zum Server verursacht. Es kann aber auch bedeuten, dass der "rate" CVar höher ist, als die Clientbandweite. Dies hat zur Folge, dass der Client mehr Packete schickt, als die Verbindung verträgt. Um ein Clientproblem auszuschließen connecte auf einen anderen Server mit gleicher Spieleranzahl und Tickrate und überprüfe, ob auch hier "Loss" auftritt.

    Das nicht exat 1000 erreicht werden liegt daran, dass der Server nach jeder Berechnung einmal kurz in den Schlaf geschickt wird, um nicht 100% Auslastung zu verursachen. Aus diesem Sleep muss er dann wieder erwachen. Das kostet natürlich Zeit, wenn auch minimalst. Das sind dann die fehlenden FPS zu 1000. Wenn die Idler laufen wird diese Aufwachzeit etwas reduziert, weil das System nicht wirklich schläft, was zu etwas höheren FPS Werten führt. Weil das Ganze so minimal ist, merkst es aber auch niemand. Wer was anderes behauptet glaubt auch noch an den Weihnachtsmann ;) .
    Die verlinkte Libary enhält einen Lizenzbruch, weil er Teile einer anderen unter GNU veröffentlichten benutzt, weswegen es wahrscheinlich kein final release geben wird. Mal abgesehen davon, dass alles über 1000 nun wirklich keinen Sinn macht und nur eins bringt und das ist mehr Geld für die Anbieter, die das vermieten. Wenn man sowas benutzen will, reicht es auch, wenn du die reine FPS lib benutzt, die auch im Forum angeboten wird und von der der FPS Teil geklaut wurde.


    Du kannst anstelle vom RT Patch auch mal den ck Patch probieren, den es seit neuestem wieder gibt. Mit dem habe ich bisher sehr gute Ergebnisse. Vor allem kann man mit dem auf einmal hlds und srcds auf einer Kiste ohne Einbrüche hosten.


    Das Wichtigste ist aber, egal welcher Kernel oder path benutzt wird, das rescheduling, wodurch die Server den anderen Prozessen gegenüber bevorzugt werden.

    Gerade, da nun immer mehr Hoster auftauchen, die teuer Geld für Server mit mehr als 1000FPS anbieten (Auch wenn anderes behauptet wird es ist kein Kernel, sondern ein kleiner Serverhack, der unter der GNU veröffentlicht ist) hier mal eine kurze Erklärung:
    Eins vorne Weg, ich halte vor allem für Public Server FPS > 500 unnötig ;)


    Die ServerFPS geben an, wie oft in der Sekunde nach neuen Daten geguckt wird. Bilder werden wie bei Clients nicht berechnet.
    Damit ein flüssiges Spielgefühl aufkommt, es wichtig ist, dass die Server FPS stabil laufen und vor allem nicht geringer sind, als die eingestellte Tickrate, weil es sonst für die Spieler zu merkbaren Ruckler kommt. Man könnte jetzt meinen, dass man nicht mehr server_fps braucht, als die Tickrate eingestellt ist, wenn die updaterate und cmdrate gleich oder größer als die Tickrate sind. Das ist zwar nicht falsch, aber auch nicht ganz richtig.
    Da ein Server nicht immer 100% synchron mit den Clients das Weltbild berechnet, kommen die Informationen nie gleichzeitig also synchron zur Weltbildberechnung beim Server an. Sind die Server FPS nun niedrig eingestellt, kann es sein, dass eine Clientinformation etwas zu spät beim Server ankommt und erst für den nächsten Tick verwendet werden kann. Dies liegt daran, dass nur am Anfang jedes Frames gefragt wird, ob neue Daten vom Spieler da sind, nicht aber ständig innerhalb des Frames.
    Bei fps_max 300 kommen auf einen tick (bei tick100) 3 Abfragen nach neuen Daten bei 500FPS 5 Abfragen usw. Durch höhere ServerFPS erhöht man also die Wahrscheinlichkeit, dass die Clientdaten rechtzeitig zur Berechnung des Ticks vorliegen. In der Regel kann man aber keinen oder kaum einen Unterschied zwischen 500FPS und 1000FPS spüren, wenn die FPS stabil laufen, wohl aber, wenn der Server auf 1000FPS eingestellt ist und auf 500FPS oder weniger einbricht, weil der Server wieder stärker zu interpolieren anfängt und dass auch noch unregelmäßig. Deshalb sind auch stabile 500fps besser als eingestellte 1000fps, die aber ständig schwanken und einbrechen. Es gilt also, wie bei euch mit den Client FPS auch, dass Stabilität besser als ein Maximum ist, das nicht konstant gehalten werden kann.
    Im Bereich 100-500FPS kann man die Steigerungen im Gameplay deutlich merken. Darüber hinaus so gut wie gar nicht, bis überhaupt nicht. Noch ein Grund mehr lieber auf stabile FPS zu setzen.


    Mitlerweile gibt es Anbieter, die beliebig viele FPS anbieten und euch weiß machen wollen, der Server wird duch die höheren FPS besser. Diese Angebote sind dann in der Regel auch extrem teuer. Der hohe Preis kommt einerseits daher, dass es genügend Leute gibt die sich abzocken lassen, zum anderen, weil solche Server natürlich mehr Leistung verbrauchen.


    Um diese hohen FPS zu erreichen werden KEINE tollen Kernel benutzt, egal, ob der Anbieter dies dreißt behauptet, oder nicht. Es ist eine in C programmierte lib, mit der die FPS Berechnung des Servers gehackt wird. Mit ihr kann man dann die FPS Anzahl einstellen, die man möchte. Wenn euch ein Anbieter erzählt, er habe einen neuen Kernel entwickelt ist das eine Lüge. Zur Zeit sind zwei verschiedene libs im Umlauf, eine unter GNU eine unter Berkley Lizenz veröffentlicht, die eine solche Modifikation erlauben.
    Kann ein gehackter, außerhalb vom Hersteller vorgesehender Parametern Laufender Server besser sein? Nein! Wenn man schon keinen bis kaum Unterschied zwischen 500 und 1000 merkt, wie soll man darüber noch was merken. mal abgesehen davon, dass die Wahrscheinlichkeit, dass es zu FPS Drops kommt steigt, je mehr FPS eingestellt werden. Ohne den Leuten zu sagen, wie die Server nun genau eingestellt sind, habe ich sie um Vergleich von zwei Servern auf dem selben Root gebeten. Nicht einer konnte merken, dass einer auf 16200FPS, der andere nur auf ca. 990 lief. Es kam immer, "die sind doch gleich".


    Mehr als 1000 FPS bringen also nur eins und das ist mehr Geld für den Anbieter.


    Wer mir das nicht glaubt, hier habe ich eine Messung mit einer solchen Lib durchgeführt http://serverwiki.sp12.speed-hoster.eu/images/graph.jpg