Die große basic.cfg Diskussion

    Moin Moin in die Runde,


    viele von euch haben sicherlich mitbekommen, dass unser Event von der Arma Nacht gestern Abend durch Serverprobleme leider nicht stattfinden konnte.
    Inzwischen glauben wir das Problem weiter eingegrenzt zu haben und nun möchte ich gerne euren Input. (Ihr wollt wissen, was diese Basic.cfg ist? Hier entlang)


    Generell sind fast alle Netzwerkseitigen Probleme auf eine fehlerhafte basic.cfg zurück zu führen. Ich persönlich habe es als problematisch empfunden Informationen zu dem Thema zu finden und best practices - gerade bei sehr großen Missionsgrößen zu finden. Beispiele gibt es kaum - meist nur ein paar Informationen, die man via Google findet².



    Das große Problem an diesen Einstellungen ist, dass man diese Erfahrungen nur durch Trial and Error sammeln kann. Man muss eine recht große Spielerbasis haben um die Werte entsprechend zu konfigurieren - und um die Auswirkungen festzustellen. Aus diesem Grund möchte ich hier einmal dazu aufrufen die einzelnen Werte zu diskutieren und die basic.cfg's eurer Clans zu posten - damit wir alle aus den Erfahrungen lernen können.


    Ich mache mal den Anfang mit ein paar der Konfigurationen der letzten Arma Nächte.


    Das ist die Basic.cfg der 3. Arma Nacht und 5. Rocket Beans Arma Nacht:

    Spoiler anzeigen


    Hier die kaputte Basic.cfg, die wir auf dem Testserver verwendet hatten. (ACHTUNG, WICHTIGE LESSION LEARNED)

    Spoiler anzeigen


    Hier ist die Konfirguration, mit der wir das nächste AN-Event durchführen wollen:

    Spoiler anzeigen


    Hier ist die Konfiguration des AW-Teams für eines ihrer Events:

    Spoiler anzeigen



    Im Nachhinein ist man immer schlauer. Das Event hat 94 Spielern den Abend versaut - und das vermutlich durch effektiv zwei Konfigurationszeilen. Nun im Nachhinein so sehr die Hose hier herunter zu lassen ist sehr demütigend. Aber uns ist wichtig, dass andere aus unseren Fehlern lernen können. Wir möchten alle Events mit vielen Spielern spielen, das funktioniert aber nur mit Wissensaustausch. Lasst uns gemeinsam ein wenig näher zusammenrücken und uns gegenseitig helfen. Wir alle können einen Teil dazu beitragen dass die Missionen bei allen Spielern besser laufen.


    Unsere Lessions learned:
    1. Änderungen an der Basic.cfg immer Dokumentieren. Warum hat man eigentlich eine bestimmte Änderung vorgenommen?
    2. Missionstests können nicht alle Fehler aufdecken. Bis 60 Spielern lief alles mit dieser Konfiguration ohne nennenswerte Probleme.
    3. Uns fehlt noch ganz viel Wissen über bestimmte Teilbereiche von der Engine.
    4. BENUTZT NIEMALS EINE DEVELOPMENT CONFIG FÜR EIN EVENT.



    Ich habe einen Channel in unserem Arma Nacht Discord eröffnet, in dem es um die Serveradministration von Arma Servern geht. Lasst uns dort einen Austausch schaffen und uns gegenseitig weiter voran bringen.
    Discord:



    ² Hier einmal die Linkliste, der Dinge die man groß öffentlich zu dem Thema findet:
    https://forums.bohemia.net/for…=comments#comment-2355045
    https://www.reddit.com/r/armad…p/understanding_basiccfg/
    https://gist.github.com/vetera…262df808780fbcd4aeda0c03a (siehe auch den kommentar von https://armaworld.de/index.php?user/1663-dedmen/)

    Hier poste ich noch ein paar der Configs hinein, die ich von anderen Communities habe (natürlich nur mit Erlaubnis):


    Gruppe W:

    Spoiler anzeigen

    Diese config habe ich für meine co 106 benutzt
    war auch später die basis bei denn AW events haben es aber natürlich auf die server angepasst



    ist aber schon 2 jahre alt

    Hallo zusammen.


    Mir ist ein komisches Phänomen aufgefallen.


    Ich spiele gerne die Escape Mission (basierend auf der Arma2 Mission von Engima - portiert von NeoArmageddon und Scruffy - angepasst von mir).
    Diese Escape Mission läuft relativ gut auf den Vanilla und CUP Inseln.


    Nur bei der DLC Karte Weferlingen, sowie auf Livonia kommt es zu einem eigenartigen starken "Warp-Effekt".


    Hierbei werden nicht nur die KI sondern auch die Spieler in mehr oder weniger regelmäßigen Abständen zu ihrer aktuellen Position gewarpt.
    Je schneller die Positionsänderung erfolgt (Fahrzeug), desto stärker sichtbar.
    Die Basic.cfg ist jedoch die selbe.
    Eine Escape Altis zeigt zb. diesen Effekt nicht.


    Ich habe keine Ahnung warum die Netzwerkeinstellungen auf Weferlingen und Livonia schlechter funktionieren sollten als auf anderen Karten.
    Wenn jemand eine Erklärung bzw Lösung bzw die selben Erfahrungen gemacht hat, bitte ich um Aufklärung ;)


    Hier meine Basic.cfg:


    Hi,


    auf dem offiziellen ARMA Discord Server gibt es mehrere Channel, die sich mit diesem Thema beschäftigen. Da springt auch dedmen rum, der wirklich phantastische Hilfe und viel Insight liefert (wenn man einigermaßen gescheite Fragen stellt ^^;).
    Ich habe dort sehr viel mitgeholt und konnte dadurch den MSP-Server sehr performant gestalten (plus die tolle Arbeit von Elias).


    Grundsätzlich ist die wichtigste Einstellung die MinBandwidth. Diese ist aus Legacy-"Gründen" auf 131 KB/s gesetzt. Nehmt hier euren Wert für eure Verbindung. Ich habe eine Gigabit-Verbindung zum Server und bin auf Nummer sicher gegangen und habe 112,5 MB/s angegeben, da ich diese Geschwindigkeit auch unter allen Umständen garantieren kann.
    Die MaxBandwidth ist garnicht mal so wichtig und sollte, laut dedmen, auf einen Wert gesetzt werden, der realistisch nicht erreicht werden kann. In meinem Fall 120 MB/s


    Das nächste wäre die MaxMsgSend. Hier muss man etwas experimentieren. Der Wert multipliziert sich eben mit dem Teilnehmern, weil mit ihm eingestellt wird, wie viele Nachrichten/Tick (also pro Server fps) an die Spieler geschickt werden. Ich habe mit dem Wert 256 sehr gute Erfahrungen gemacht. Peak bei uns waren bisher "jedoch nur" 36 Spieler.


    Nächstes, wichtige Ding, wäre MinErrorToSend(Near). Ich kanns nicht mehr genau wiedergeben, aber es gibt effektiv die Distanz der KI wieder, die sie gehen muss, bis sie refresht. Hier muss sollte man sehr konservativ vorgehen, weil das die Einstellung ist, die dein Event so richtig zerfickt. Und mit zerficken meine ich mit Jetpack-Antrieb und ohne Gleitgel hinten rein!
    Ich habe sehr gute Erfahrungen mit 0,00(0)2 gemacht. Die Spieler berichteten, dass auch entfernte KIs sich sehr sehr sehr flüssig bewegten. Einen 0,00(0)3er Wert haben wir noch nicht ausprobiert. Beim 2er Wert updatet sich die KI nach 50m Distanz in 1km Entfernung. Bei einem 3er Wert müssten es schon nur 25 Meter sein. Hier sehr vorsichtig sein, weil das auch mit in die MaxMessagesSend reinspielt und man sich dadurch ggf. den Traffic so zumacht, dass man Desyncs wieder erzwingt ...


    Macht damit folgende Config derzeit:


    Code
    1. MaxMsgSend: 256
    2. MinBandwidth: 900000000
    3. MaxBandwidth: 1200000000
    4. MinErrorToSend: 0,002
    5. MinErrorToSendNear: 0,02


    Mindestens genauso wichtig, wie die MaxBandwidth Einstellung, ist in meinen Augen aber eine gute Headless Client-Unterstützung. Wir fahren 3 HCs, die über ACEX angebunden sind. Funktioniert wunderbar und hält die Ressourcen für die Spieler frei und lässt die KI extrem coole Dinge tun. Immer. Auch mit vielen KI Einheiten. Wichtig hier ist, dass Server und HCs Hyperthreading nutzen. Dann wird auch der Server schön ausgelasstet und auch 90+ Spieler sollten ein gutes Erlebnis haben.


    Als Best Practice haben mir einige Missionsbauer auf /r/armadev damals mitgegeben, dass man ab einer gewissen Größe die Leute zusammenhalten muss und auch so Sachen wie AmbientAnimals und ACE Cooking Off abschalten sollte. Auch Fahrzeuge mit sehr hoher Schussfolge (A10, ZSU, etc) vermeiden, oder ACE Balistik ausschalten, weil jeder einzelne Schuss voll berechnet wird.Das geht sehr stark auf die Server FPS.


    Speaking of: Schaut euch mal den Performance & Profiling Branch an. NIcht nur ist nun das Update draußen, mit dem man einstellen kann, wie lang der Mod-String sein soll (und damit (nahezu) beliebig viele Workshop-Mods bei vollem mod.cpp-Namen), man kann auch schon seit längerem die Server FPS unlocken. Standardmäig sind diese auf 50 gelockt. Damit rennt das Spiel nicht zwangsläufig schneller, sondern man kann wesentlich mehr Spieler aufnehmen, ohne, dass alles zusammenbricht. So können 90+ Spieler beispielsweise bei 40 - 60 Server FPS gut spielen, wenn man es auf ~800+ FPS gestellt hat. Da auch mal etwas mit größerer Gruppe versuchen/austesten.


    Hoffe etwas Insight geliefert zu haben. Hier nochmal das Plädoyer euch am Austausch auf dem offiziellen ARMA Server zu beteiligen. Vielleicht möchte auch jemand das ganze mal auf einen 2020er Dokustand bringen?



    Viele Grüße
    Ben

    Zitat von B.Miller

    Das nächste wäre die MaxMessagesSend. Hier muss man etwas experimentieren. Der Wert multipliziert sich eben mit dem Teilnehmern, weil mit ihm eingestellt wird, wie viele Nachrichten/Tick (also pro Server fps) an die Spieler geschickt werden. Ich habe mit dem Wert 256 sehr gute Erfahrungen gemacht. Peak bei uns waren bisher "jedoch nur" 36 Spieler.

    MaxMessagesSend ist kein valider wert in der config, der wert heißst MaxMsgSend. d.h. in deiner aktuellen config wird der default wert von 128 genutzt.


    Zitat von B.Miller

    Damit rennt das Spiel nicht zwangsläufig schneller, sondern man kann wesentlich mehr Spieler aufnehmen, ohne, dass alles zusammenbricht. So können 90+ Spieler beispielsweise bei 40 - 60 Server FPS gut spielen, wenn man es auf ~800+ FPS gestellt hat. Da auch mal etwas mit größerer Gruppe versuchen/austesten.

    Wenn der Server nicht auf normal einstellung performance halten kann wird er es auch nicht mit den limitFPS startup parameter himbekommen. hier bei wird nix anderes als die Maximale grenze des wertes überschrieben und ist kein "Magie" Startup parameter.

    Erst einmal Danke für den Feedback B.Miller,


    generell hatte ich noch nie Probleme mit dem Server bei < 60 Spielern. Danach wird es kritisch und es kommt auf viele Dinge an.
    Tatsächlich ist der einzige Wert, der tatsächlich bei den meisten Communities sehr unterschiedlich ist "MaxMsgSend".


    Die 101 spielt mit einem Wert von 2048, die W 1480, BI auf ihren eigenen Servern 640 und du mit 256. Dass die MinBandwidth wichtig ist, da sind wir uns glaube ich alle einig.



    Was ich aber sehr interessant finde ist, dass die meisten hier bit und byte verwechseln.


    Zitat von B.Miller

    ACE Cooking Off abschalten sollte.

    Das empfehle ich in jedem Fall auch jedem, der Probleme mit der Performance hat, wenn Panzer auskochen.


    Ansonsten schließe ich mich der Aussagen von joko an.

    Ich empfinde gerade jokohos Antwort als überaus toxisch. Bitte bei meiner Antwort entsprechend berücksichtigen. Danke :)


    Zitat von jokoho482

    Wenn der Server nicht auf normal einstellung performance halten kann wird er es auch nicht mit den limitFPS startup parameter himbekommen. hier bei wird nix anderes als die Maximale grenze des wertes überschrieben und ist kein "Magie" Startup parameter.

    Genau :)
    Wer mit einem Q6600 ankommt, wird auch mit einem FPS Unlock auch nicht mehr erreichen. Da ich aber davon ausgehe, dass man eine performante Maschine hat, wenn man 90+ Leute bespaßen möchte, habe ich das einfach mal vorausgesetzt.


    Zitat von Kohbrax

    Tatsächlich ist der einzige Wert, der tatsächlich bei den meisten Communities sehr unterschiedlich ist "MaxMsgSend".


    Die 101 spielt mit einem Wert von 2048, die W 1480, BI auf ihren eigenen Servern 640 und du mit 256. Dass die MinBandwidth wichtig ist, da sind wir uns glaube ich alle einig.

    OK, die Werte verwundern mich. Dedmen oder die (Antik™-)Doku sagte, dass der Wert nicht zu hoch gesetzt werden sollte. Interessant, dass man mit solchen Werten spielt. Teste ich mal mit rum. Danke für deine Anregung :)


    Zitat von Kohbrax

    Was ich aber sehr interessant finde ist, dass die meisten hier bit und byte verwechseln.

    Mein Fehler: 900000000 Bit sind natürlich 112,5 MB - habs oben ausgebessert!

    Zitat von B.Miller

    Mein Fehler: 900000000 Bit sind natürlich 112,5 MB - habs oben ausgebessert!

    Die Frage ist, ob eine Minimalbandbreite so knapp unter dem Maximum tatsächlich sinnvoll ist. Ich habe sie bei einem gbe immer auf 100mbit stehen. Die wenigsten Provider (und rechenzentren) können garantieren, dass du immer die volle Bandbreite an alle anliegenden Peers bekommst. Das sind eigentlich immer Mischkalkulationen.

    Die sind in einer server basic.cfg alle nutzlos und können getrost entfernt werden.



    Zitat von Kohbrax

    MinBandwidth = 131072;
    MaxBandwidth = 655360000;

    Das ist falsch.
    MinBandwidth ist die Bandbreite die Garantiert vom Server erreicht wird. Das heißt bei einer 100mbit Anbindung, schreibt man hier auch 100mbit hin.
    MaxBandwidth ist die Bandbreite die garantiert NICHT vom Server erreicht wird. Ich nehme da als "rule of thumb" 120% der MinBandwidth, aber da gibts keinen richtwert wie man das machen soll.



    Zitat von Kohbrax

    class sockets{maxPacketSize = 1300;};

    Das ist der standartwert, also nutzlos.



    Zitat von Kohbrax

    MaxCustomFileSize=100;

    100 bits!! ist so ziemlich nutzlos, entweder ganz oder garnicht. Würde sagen auf 0 setzen.



    Zitat von Kohbrax

    MinBandwidth = 131072;// Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded. Default: 131072
    MaxBandwidth = 10000000000;// Bandwidth the server is guaranteed to never have. This value helps the server to estimate bandwidth available.

    Da stehen schon die richtigen kommentare dran, aber diese wurden nicht befolgt.



    Zur MTU, eigentlich gibt es keinen Grund diese hochzusetzen. Also würd ichs default lassen.



    Zitat von Kohbrax

    In dieser Config wird pro Client mit einer Minimalen Bandbreite von 100mbit gerechnet. (Rechenweg: 1024*1024*100 = 104857600)

    Ja das is natürlich doof, die socket Einstellungen sind recht hart, wenn da steht, minBandwidth dann ist das auch gemeint, und jeder der das nicht erfüllt bekommt Probleme.





    Zitat von Kohbrax

    Hier ist die Konfirguration, mit der wir das nächste AN-Event durchführen wollen:


    Zitat von Kohbrax

    MinBandwidth = 768000;
    MaxBandwidth = 524288000;

    Immernoch falsch



    Zitat von Spiderman

    MinBandwidth=<bottom_limit>

    Nein, häufiger irrglaube, es ist eben NICHT das "bottom limit"



    Zitat von B.Miller

    Schaut euch mal den Performance & Profiling Branch an

    Danke für den ausführlichen post, da hab ich nichts zu beanstanden o7
    Übrigens ist in der Perf/Prof branch auch gerade ein ziemlich großer Performance fix beim Parsen von Netzwerkpaketen was bei Missionen mit vielen KI's 5-10% der frametime ausmachen kann.



    MaxMsgSend zu hoch angesetzt kann zu kurzen freezes/rucklern führen, wenn auf einmal eine große Anzahl an Messages auf dem Server anliegt, aber allgemein sind kurze lagspikes auf dem Server eher irrelevant. Wenn diese zahl jedoch zu niedrig ist, kann es einen Rückstau geben was auch mal in einem komplett freeze enden kann.



    Zitat von Kohbrax

    Die Frage ist, ob eine Minimalbandbreite so knapp unter dem Maximum tatsächlich sinnvoll ist. Ich habe sie bei einem gbe immer auf 100mbit stehen. Die wenigsten Provider (und rechenzentren) können garantieren, dass du immer die volle Bandbreite an alle anliegenden Peers bekommst. Das sind eigentlich immer Mischkalkulationen.


    Bandbreite pro spieler = MinBandwidth/SpielerAnzahl.


    Es wird sehr selten bzw niemals soviel Bandbreite vom Arma Server genutzt werden, aber durch eine hohe Minimalbandbreite können einzelne Spieler bei Bedarf hohe Burst-Bandbreiten bekommen.
    Wenn dann ein einzelner Spieler nur auf 5mbit hochgeht und alle anderen Spieler ruhig sind, hast du 5mbit Gesamtlast, auch wenn du allen Spielern 100mbit zur Verfügung stellst.
    Das alle Spieler gleichzeitig ihre volle Bandbreite auslasten kommt eigentlich nicht vor.

    Moin dedmen,


    erst einmal Danke für deine Antwort.

    Zitat von dedmen

    Das ist falsch.
    MinBandwidth ist die Bandbreite die Garantiert vom Server erreicht wird. Das heißt bei einer 100mbit Anbindung, schreibt man hier auch 100mbit hin.
    MaxBandwidth ist die Bandbreite die garantiert NICHT vom Server erreicht wird. Ich nehme da als "rule of thumb" 120% der MinBandwidth, aber da gibts keinen richtwert wie man das machen soll.

    Die Frage ist, ob eine Minimalbandbreite des Servers überhaupt realistisch ist. Nehmen wir mal Beispiel mal Hetzner oder OVH (bei keinem von beiden Hoste ist). Je nachdem in welchem Netzsegment und zu welcher Uhrzeit man schaut schwankt die verfügbare Bandbreite teilweise massiv. Wenn ich nun also theoretisch "garantierte" 1gbe habe, heißt das noch lange nicht, dass sie praktisch auch durchgeht. Die große Frage ist, wie verzeihend Arma bei dem Wert ist?



    Zitat von dedmen

    Das ist der standartwert, also nutzlos.

    laut BI-Wiki ist der Default-Wert 1400 nicht 1300. Eine 1400er MTU kann je nach verwendeten Tunneln (gehen wir mal vom Worst-Case aus, Hybrid + OpenVPN) durchaus unterschritten werden. Sobald man diesen wert jedoch unter 1400 stellt (was nebenbei gesagt bei UDP Paketen eigentlich eh NIEMALS über 1200 gehen sollte..) bekommt man Probleme mit seinen HCs.

    Code
    1. NetServer: trying to send a too large non-guaranteed message (len=1348/1372) to

    Ist nur eines der Probleme mit einer MTU von 1300. Anmerkung hier: Ein Wert von über 1450 sorgt wie oben beschrieben dafür, dass unitymedia-Kunden sich nicht mehr verbinden können.



    Zitat von dedmen

    Ja das is natürlich doof, die socket Einstellungen sind recht hart, wenn da steht, minBandwidth dann ist das auch gemeint, und jeder der das nicht erfüllt bekommt Probleme.

    Genau, das ist eine der "lessions learned".

    Zitat von dedmen

    Immernoch falsch

    Was hat denn eine zu niedrige Minimalbandbreite für Auswirkungen? Grundsätzlich estimated der Server ja augenscheinlich die verfügbare Bandbreite.


    Zitat von dedmen

    MaxMsgSend zu hoch angesetzt kann zu kurzen freezes/rucklern führen, wenn auf einmal eine große Anzahl an Messages auf dem Server anliegt, aber allgemein sind kurze lagspikes auf dem Server eher irrelevant. Wenn diese zahl jedoch zu niedrig ist, kann es einen Rückstau geben was auch mal in einem komplett freeze enden kann.

    Also ist ein Wert von 2k eine gute Größe? Die meisten Communities haben mit genau diesem Wert Probleme und eigentlich gibt es keine einheitliche Meinung.

    Zitat von Kohbrax

    NetServer: trying to send a too large non-guaranteed message (len=1348/1372) to

    hat nichts mit der eingestellten MTU zutun, das ist irgendein bug im message packing.



    Zitat von Kohbrax

    Was hat denn eine zu niedrige Minimalbandbreite für Auswirkungen?

    minBandwidth == verfügbare Bandbreite. Wenn du da eine zu niedrige angibst dann wird deine Leitung halt nie ausgelastet.
    Die maxBandwidth Angabe ist übrigens komplett irrelevant momentan.



    Zitat von Kohbrax

    Also ist ein Wert von 2k eine gute Größe?

    Denke schon. Ich hab 1k und bisher keine Probleme gehabt.

    Zitat von dedmen

    Die maxBandwidth Angabe ist übrigens komplett irrelevant momentan.

    Danke! Das ist mal eine relevante Information. Dann stelle ich den MinBandwidth-Wert auf einen guten Wert und alle sind Glücklich.



    Zitat von dedmen

    hat nichts mit der eingestellten MTU zutun, das ist irgendein bug im message packing.

    MaxPacketSize hat für mich ein Equivalent einer MTU. Ich finde deine Aussage aber spannend, da du vor ein paar Monaten das hier auf github geschrieben hast: https://gist.github.com/vetera…262df808780fbcd4aeda0c03a


    Tatsächlich habe ich von mehrere Personen gehört, dass sie diesen Post als Grundlage verwendet haben.



    Zitat von dedmen

    Denke schon. Ich hab 1k und bisher keine Probleme gehabt.

    Sehr Gut! Dann werde ich mal schauen, dass wir das nächste Event damit fahren.



    @dedmen: Gibt es die Möglichkeit die send/recv queue zu vergrößern via config?



    Again, lessions learned:
    - MaxBandwidth ist recht irrelevant, wird momentan nicht verwendet
    - MinBandwidth kann höher als das "normale" Minimum liegen, da es sowieso nur bei Peaks verwendet wird. Beispiel: garantierte Hetzner 1000mbit sind nicht immer 1000mbit.
    - Ein höherer MaxMsgSend kann Probleme vorbeugen, wenn man mit vielen Spielern spielt.

    Zitat von Kohbrax

    MaxPacketSize hat für mich ein Equivalent einer MTU.

    Es ist ja auch genau das. Aber es fixed den "trying to send a too large non-guaranteed message" fehler nicht, der wird verursacht weil die engine irgendwie die limits nicht richtig einhält.
    Höhere MTU -> selber Fehler mit größeren Zahlen.



    Zitat von Kohbrax

    Gibt es die Möglichkeit die send/recv queue zu vergrößern via config?

    Soweit ich weiß nicht, zumindest nicht in den dokumentierten einträgen