Die große basic.cfg Diskussion

  • Sonstiges

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • 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

    language="English";
    adapter=-1;
    3D_Performance=1.000000;
    Resolution_W=0;
    Resolution_H=0;
    Resolution_Bpp=32;
    terrainGrid=25;
    viewDistance=3000;

    MinBandwidth = 131072;
    MaxBandwidth = 655360000;

    MaxMsgSend = 512;

    MaxSizeGuaranteed=384;
    MaxSizeNonguaranteed=256;

    MinErrorToSend = 0.001;
    MinErrorToSendNear = 0.1;

    MaxCustomFileSize=100;

    class sockets{maxPacketSize = 1300;};

    Spoiler anzeigen

    Hier war einer der Fehler, die jedoch erst bei einer späteren Mission aufgetreten ist, dass die MTU (maxPacketSize) zu klein war.
    Der folgende Fehler ist später aufgetreten, was aber den Server nicht zum disconnecten aller peers gebracht hat:
    NetServer: trying to send a too large non-guaranteed message (len=1348/1372) to



    Hier die kaputte Basic.cfg, die wir auf dem Testserver verwendet hatten. (ACHTUNG, WICHTIGE LESSION LEARNED)
    Spoiler anzeigen
    // These options are created by default
    language="English";
    adapter=-1;
    3D_Performance=1.000000;
    Resolution_W=800;
    Resolution_H=600;
    Resolution_Bpp=32;

    terrainGrid=25;
    viewDistance=3500;

    // These options are important for performance tuning

    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.

    MaxMsgSend = 128;// Maximum number of messages that can be sent in one simulation cycle. Increasing this value can decrease lag on high upload bandwidth servers. Default: 128
    MaxSizeGuaranteed = 512;// Maximum size of guaranteed packet in bytes (without headers). Small messages are packed to larger frames. Guaranteed messages are used for non-repetitive events like shooting. Default: 512
    MaxSizeNonguaranteed = 256;// Maximum size of non-guaranteed packet in bytes (without headers). Non-guaranteed messages are used for repetitive updates like soldier or vehicle position. Increasing this value may improve bandwidth requirement, but it may increase lag. Default: 256

    MinErrorToSend = 0.001;// Minimal error to send updates across network. Using a smaller value can make units observed by binoculars or sniper rifle to move smoother. Default: 0.001
    MinErrorToSendNear = 0.01;// Minimal error to send updates across network for near units. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well. Default: 0.01

    MaxCustomFileSize = 0;// (bytes) Users with custom face or custom sound larger than this size are kicked when trying to connect.

    class sockets{
    maxPacketSize = 1480;
    initBandwidth = 6250000; // 50 mbit undocumented
    MinBandwidth = 10485760;
    MaxBandwidth = 104857600;
    };
    Spoiler anzeigen

    Hier gab es mehrere Punkte, die es zu lernen galt. Aber dafür müssen wir zuerst einen kleinen Abstecher Richtung Netzwerktechnik machen.
    Die Default-MTU einer normalen Netzwerkverbindung ohne Konfigurationsänderung beträgt 1500 (bytes). Soll heißen, jedes Netzwerkpaket, welches diese Größe überschreitet wird durch den Router in kleinere Pakete aufgespalten. Bei TCP geht das über einen MSS-Fix, bei UDP wird das einfach hart gemacht, da die Pakete sowieso nicht garantiert in der Reihenfolge und/oder der Größe ankommen.

    Nun ist es so, dass durch diverse Tunnel, die fast jede Consumer-Internetleitung hat die MTU reduziert werden muss. Das ursprüngliche Datenpaket wird in ein anderes Datenpaket eingebettet, wodurch die Daten von dem neuen größeren Paket trotzdem in die 1500er MTU passen müssen. Hier ein Beispiel der Telekom mit Hybrid (MTU von 1440).

    Lustigerweise haben nicht alle Provider ein Problem damit. Normalerweise wird das Paket aufgespalten und der Client bekommt davon erst einmal nichts mit.
    Hier gibt es aber Probleme bei Unitymedia (inzwischen Vodafone in West-Deutschland). Aus einem nicht erkennbaren Grund konnten Spieler dort sich nicht mehr verbinden.

    Solltet ihr das Problem haben, dass einzelne Spieler zwar in die Slotliste kommen, dann aber beim Durchladen die Mission-File nicht herunterladen können. Schaut euch die MTU an.


    Der Zweite Punkt:
    In dieser Config wird pro Client mit einer Minimalen Bandbreite von 100mbit gerechnet. (Rechenweg: 1024*1024*100 = 104857600)
    Puh. Das war ganz schön dumm konfiguriert. Es stellte sich heraus, dass ich von einem Test mit einem unserer Teammitglieder eine Dev-Config übernommen hatte und diese nicht wieder durch unsere ursprüngliche ersetzt hatte.


    Hier ist die Konfirguration, mit der wir das nächste AN-Event durchführen wollen:
    Spoiler anzeigen
    language="English";
    adapter=-1;
    3D_Performance=1.000000;
    Resolution_W=800;
    Resolution_H=600;
    Resolution_Bpp=32;
    terrainGrid=25;
    viewDistance=2500;


    MinBandwidth = 768000;
    MaxBandwidth = 524288000;

    MaxMsgSend = 640;

    MinErrorToSend = 0.001;
    MinErrorToSendNear = 0.01;

    MaxCustomFileSize=0;

    class sockets{
    maxPacketSize = 1420;
    initBandwidth = 1250000; // 10 mbit
    MinBandwidth = 65536;
    MaxBandwidth = 10485760;
    };


    Hier ist die Konfiguration des AW-Teams für eines ihrer Events:
    Spoiler anzeigen
    MinBandwidth=107374182;
    MaxBandwidth=1073741824;
    MaxMsgSend=384;
    MaxSizeGuaranteed=512;
    MaxSizeNonguaranteed=256;
    MinErrorToSendNear=0.022;
    MinErrorToSend=0.004;
    MaxCustomFileSize=0;
    adapter=-1;
    3D_Performance=1;
    Resolution_W=0;
    Resolution_H=0;
    Resolution_Bpp=32;
    Windowed=0;
    serverLongitude=9;
    serverLatitude=50;
    serverLongitudeAuto=9;



    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:
    forums.bohemia.net/forums/topi…=comments#comment-2355045
    reddit.com/r/armadev/comments/2zkw7p/understanding_basiccfg/
    gist.github.com/veteran29/ef08068262df808780fbcd4aeda0c03a (siehe auch den kommentar von 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

    Quellcode

    1. MaxMsgSend = 1480;
    2. MaxCustomFileSize = 150000;
    3. class sockets {
    4. maxPacketSize = 1444; // was 1444 (Fast for most, but not Toiton), 1480 killed it.
    5. initBandwidth= 2000000; // 16 Mb max
    6. MinBandwidth = 64000; // 512 Kb lowest DSL (value in bytes)10485760;
    7. MaxBandwidth = 2000000; // 16 Mb average DSL (value in bytes) - Previous 104857600 (dedmen 900mb);
    8. };
  • 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


    Quellcode

    1. MaxMsgSend = 2048;
    2. MaxSizeGuaranteed = 1024;
    3. MaxSizeNonguaranteed = 512;
    4. MinBandwidth = 107374182;
    5. MaxBandwidth = 1073741824;
    6. MinErrorToSend = 0.003;
    7. MinErrorToSendNear = 0.02;
    8. MaxCustomFileSize = 1310720;
    9. adapter=-1;
    10. 3D_Performance=1;
    11. Resolution_W=0;
    12. Resolution_H=0;
    13. Resolution_Bpp=32;
    14. terrainGrid=25;
    15. viewDistance=3500;
    16. Windowed=0;
    17. MaxPermanentCraters=200;
    Alles anzeigen
    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:

    Brainfuck-Quellcode

    1. // These options are created by default
    2. language="English";
    3. adapter=-1;
    4. 3D_Performance=1.000000;
    5. Resolution_W=800;
    6. Resolution_H=600;
    7. Resolution_Bpp=32;
    8. terrainGrid=25;
    9. viewDistance=2000;
    10. // These options are important for performance tuning
    11. /*
    12. MaxBandwidth=<top_limit>;
    13. Bandwidth the server is guaranteed to never have (in bps).
    14. This value helps the server to estimate bandwidth available.
    15. For 1 Gbps connection: 1073741824
    16. */
    17. MaxBandwidth = 1073741824;
    18. /*
    19. MinBandwidth=<bottom_limit>;
    20. Bandwidth the server is guaranteed to have (in bps).
    21. This value helps server to estimate bandwidth available.
    22. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded.
    23. Default: 131072
    24. For 1 Gbps connection: 107374182
    25. */
    26. MinBandwidth = 12800;
    27. /*
    28. MaxMsgSend=<limit>;
    29. Maximum number of packets (aggregate messages) that can be sent in one simulation cycle ("frame").
    30. Increasing this value can decrease lag on high upload bandwidth servers. lower by 256 until it's ok
    31. Default: 128
    32. */
    33. MaxMsgSend = 512;
    34. /*
    35. MaxSizeGuaranteed=<limit>;
    36. Maximum size (payload) of guaranteed packet in bytes (without headers).
    37. Small messages are packed to larger packets (aggregate messages).
    38. Guaranteed packets (aggregate messages) are used for non-repetitive events like shooting.
    39. lower by 64 until it's ok
    40. Default: 512
    41. */
    42. MaxSizeGuaranteed = 448;
    43. /*
    44. MaxSizeNonguaranteed=<limit>;
    45. Maximum size (payload) of non-guaranteed packet in bytes (without headers).
    46. Soldier or vehicle movement.
    47. Small messages are packed to larger packets (aggregate messages).
    48. Non-guaranteed packets (aggregate messages) are used for repetitive updates like soldier or vehicle position.
    49. Increasing this value may improve bandwidth requirement, but it may increase lag.
    50. increase by 16 until it's ok
    51. Default: 256 ...320
    52. */
    53. MaxSizeNonguaranteed = 240;
    54. /*
    55. class sockets{maxPacketSize = <limit>;};
    56. Maximal size of packet sent over network.
    57. This can be set for both client-to-server AND server-to-client(s) independently!
    58. Default: 1400
    59. Use please only in case Your router or ISP enforce lower packet size and You have connectivity issues with game
    60. Desync might happen if used MaxSizeGuaranteed/MaxSizeNonguaranteed values over the maxPacketSize.
    61. maxPacketSize default reduced from 1490 to 1400 since 1.60, thus MaxSize... values over 1300 could be affected negatively.
    62. */
    63. class sockets{maxPacketSize = 1400;};
    64. /*
    65. MinErrorToSend=<limit>;
    66. Minimal error to send updates across network.
    67. Using a smaller value can make units observed by binoculars or sniper rifle to move smoother at the trade off of
    68. increased network traffic.
    69. Default: 0.001
    70. */
    71. MinErrorToSend = 0.001;
    72. /*
    73. MinErrorToSendNear=<limit>;
    74. Minimal error to send updates across network for near units.
    75. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well.
    76. Default: 0.01
    77. */
    78. MinErrorToSendNear = 0.01;
    79. /*
    80. MaxCustomFileSize=<size_in_bits>;
    81. Users with custom face or custom sound larger than this size are kicked when trying to connect.
    82. 100000 bytes = 100kb
    83. 500000 bytes = 500kb
    84. 800000 bytes = 800kb
    85. 1000000 bytes = 1000kb = 1mb
    86. */
    87. MaxCustomFileSize = 500000;
    Alles anzeigen
  • 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 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.

    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:

    Quellcode

    1. MaxMessagesSend: 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
    MilSim Publicserver
    Schnell - Immersiv - Gemeinschaftlich

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von B.Miller ()

  • B.Miller schrieb:

    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.

    B.Miller schrieb:

    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.
    Wer Rechtschreibfehler findet darf sie behalten
    ACE3 Core Developer
    CBA A3 Developer
    Developer of Lambs Danger, Dynasound, Enhance SoundScape, Immerse, Suppress and Align
  • 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.

    B.Miller schrieb:

    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 :)

    jokoho482 schrieb:

    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.

    Kohbrax schrieb:

    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 :)

    Kohbrax schrieb:

    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!
    MilSim Publicserver
    Schnell - Immersiv - Gemeinschaftlich
  • B.Miller schrieb:

    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.
  • Kohbrax schrieb:

    anguage="English";
    adapter=-1;
    3D_Performance=1.000000;
    Resolution_W=0;
    Resolution_H=0;
    Resolution_Bpp=32;
    Die sind in einer server basic.cfg alle nutzlos und können getrost entfernt werden.


    Kohbrax schrieb:

    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.


    Kohbrax schrieb:

    class sockets{maxPacketSize = 1300;};
    Das ist der standartwert, also nutzlos.


    Kohbrax schrieb:

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


    Kohbrax schrieb:

    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.


    Kohbrax schrieb:

    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.




    Kohbrax schrieb:

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


    Kohbrax schrieb:

    MinBandwidth = 768000;
    MaxBandwidth = 524288000;
    Immernoch falsch


    Spiderman schrieb:

    MinBandwidth=<bottom_limit>
    Nein, häufiger irrglaube, es ist eben NICHT das "bottom limit"


    B.Miller schrieb:

    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.


    Kohbrax schrieb:

    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.

    dedmen schrieb:

    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?


    dedmen schrieb:

    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.

    Quellcode

    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.


    dedmen schrieb:

    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".

    dedmen schrieb:

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

    dedmen schrieb:

    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.
  • Kohbrax schrieb:

    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.


    Kohbrax schrieb:

    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.


    Kohbrax schrieb:

    Also ist ein Wert von 2k eine gute Größe?
    Denke schon. Ich hab 1k und bisher keine Probleme gehabt.
  • dedmen schrieb:

    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.


    dedmen schrieb:

    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: gist.github.com/veteran29/ef08068262df808780fbcd4aeda0c03a

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


    dedmen schrieb:

    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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Kohbrax ()

  • Kohbrax schrieb:

    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.


    Kohbrax schrieb:

    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