Airrefueling in komplexen Einsätzen

    Zitat von Iceman

    Nachdem die saugeile Mission von Pitbull gestern ja auch leider einem Servercrash zu Opfer gefallen ist (*),


    (*) Pitbull => bloß nicht den Tanker wegreparieren! Ich bin auch der Meinung dass es sehr schade darum wäre. :8:


    Leider ist der spannende Einsatz "Pinpoint" in die Hose gegangen, weil das Game stehen blieb. Meiner Vermutung, dass es mit dem Tanken zusammenhängen könnte, wurde widersprochen. Das wunderte mich, weil dieses Ereignis schon relativ oft mit dem Tanken aufgetreten ist. Wunderte mich noch mehr, dass dies offensichtlich aus den Köpfen verschwunden ist, auch die anderen Anomalien, der Tanker fliegt plötzlich zu tief und zu langsam, gehören in dieses Schema. Es ärgert mich auch ein wenig, dass dieses Thema dann einfach mit einem Satz (glaube ich nicht, dass es daran liegt) beseite gefegt wird.


    Habe jetzt etwas interessantes bei den 1stGW gefunden. Da ist ein "Monsterflug", von dem wir nur träumen können, ganz offensichtlich aufgrund dieses Phänomens in die Hose gegangen. Was sehr ärgerlich ist.


    Bitte um Beachtung und das einfach mit ins Kalkül zu ziehen und nicht wieder einfach ignorieren. :5:


    Zitat

    ..... und meinem Luftbetankungs-Versuch die Online-TE ins digitale Nirvana geschossen hat :arghs:


    In BMS wird die Tanker-Instanz beim A2A-Refueling vom Server zum Client verschoben, der Client mutiert sozusagen zum Mini-Server. Und da ein BMS-Client ohne korrektem Portforwarding bekanntlich NICHT hosten kann ging in Folge die ganze Online-Mission den Bach runter ;(


    Das muss jetzt bei uns nicht auch der Fall gewesen sein, aber es ist ein Indiz, dass das Airrefueling in BMS immer noch ein Problem sein kann. Ich wünsche mir ganz einfach, dass wir bei hochkomplexen Missionen auf das Airrefueling verzichten. Hotpitrefueling ist eine spannende Alternative. ;)

    Ich glaube (hoffe :9: ) immer noch, dass das Refueling nicht das Problem ist. Sollte der Fehler dem entsprechen was im 1.GW Forum geschrieben wurde, würde ich vermuten, dass jedes Online refueling scheitern müsste und nicht nur sporadische Abbrüche zu verzeichnen wären.
    Da unser Server in der Vergangenheit öfter hängen geblieben ist, auch ohne refueling, gilt die Tankercrew für mich bis auf Weiteres als unschuldig.
    Nik, du hast natürlich Recht. Auszuschließen ist es nicht, aber solange keine konkreteren Vermutungen vorliegen...


    An Pitbull:
    Könnte man durch einen ausschließlichen Tanker- Testflug und deinen Verbindungstests hinsichtlich der Betankung ein aufschlussreiches Ergebnis vermuten?

    Zitat von Bumerang

    Ich glaube (hoffe :9: ) immer noch, dass das Refueling nicht das Problem ist. Sollte der Fehler dem entsprechen was im 1.GW Forum geschrieben wurde, würde ich vermuten, dass jedes Online refueling scheitern müsste und nicht nur sporadische Abbrüche zu verzeichnen wären.

    Das genau eben nicht, weil es mehr Clients gibt die Hosten können. Beim letzten Flug stimmt die These, ich (Hostfähig) habe mich abgemeldet und du warst der nächste. Exakt bei meiner Abmeldung blieb das Game stehen und das nicht das erste mal, bzw. der Tanker spielte verrückt. Außerdem sucht sich BMS irgendwie willkürlich einen neuen Host, haben wir in der Vergangenheit mehrfach festgestellt, wenn der ursprüngliche Host ausfiel. Es heißt ja nicht, dass der jeweilige Lead der Refuelinghost wird, kann durchaus der "hostfähige" Wingman sein und schon läuft das Game problemlos weiter.


    Alles deutet darauf hin, dass die Annahme (Reaper 1stGW) mit dem "Mini-Server" das Problem sein kann.


    Über die Aussage "konkrete Vermutungen kann ich nur müde grinsen. Wer und wie soll die erbracht werden?


    Habe nur geschrieben, weil ich es für alle schade finde, wenn ein Einsatz aufgrund einer vermeidbaren Nebensächlichkeit in die Hose geht. Komplexe Einsätze haben wir vielleicht in einem Verhältnis 1 : 10 und dabei auf das A2A Refueling zu verzichten, sehe ich als das geringere Übel an, als den Spielabbruch. Selbst wenn die These nicht die Ursache ist.

    Im BMS Forum hatte ich einen Tipp bekommen, wie man das Verhalten des Tankers loggen kann, um die Fehlersuche zu vereinfachen.
    Wenn man das Problem analysieren möchte, schlage ich diesen Weg vor:



    Put this in your config file: "set g_fXMonoprintFilter 512"


    Then add -mono to your command like arguments when you run the game. This will result in a file in the logs directory with a date and xlog text file name. Run this mission in MP with these settings for _ALL_ players. Go through the motions to see that the problem occurs and note the game time (look at clock in DED) when you see something unexpected. Write up what you did and when (again, use game time for reference) and include that with a copy of xlog files from _ALL_ player sessions. Upload that collection somewhere and post a link for it here. That should allow us to take a look and see in detail what is going on.

    Zitat von Rampage

    Wäre zumindest ein paar Experimente wert würde ich sagen.

    Ist das unterm Strich, was ich ausdrücken wollte, aber keine Experimente in komplexen Einsätzen. Habe aber jetzt keine Lust mehr wie auf einen lahmen Gaul einzureden. :5:


    Haben wir, es sind die mit der IPv6 Leitung oder mit einem zu geringen Upload. Wenn sich BMS einen davon aussucht, kann es zu Problemen kommen. In der Nachschau passt alles zusammen.

    Mein Vorschlag wär sich mit 4 Leuten zusammen zu tun und 3 der 4 Leute stellen Portweiterleitung so um das sie nicht hosten können.
    Damit müsste der Crash nachvollziehbar sein, evtl ist er ja so gut nachzustellen das man den Testaufbau an die BMS Devs geben kann.
    Wenn man es nachstellen kann stehen die Chancen nicht schlecht das man es beheben kann.

    Morgen Kollegen,


    ich möchte euch noch etwas mehr Info zu unserem/meinem Problem geben, vielleicht hilfts ja.


    Bei mir trafen am Dienstag zwei BMS-Stolperfallen zusammen: erstens kein korrektes Portforwarding / dubious connection durch Reserve-Router (dem guten Router wurde durch Zeus das Lebenslicht ausgeblasen) und zweitens sehr wenig Upload (mehr als 0.7 Mbit ist an meinem Standort leider nicht drinn).


    Ich hatte ja bereits vorher schon zwei- oder dreimal Bluetext am Schirm (Anzeichen für Geschwindigkeits-Probleme der Leitung) und der Mission-Crash fand exakt zu dem Zeitpunkt statt als ich als erster unseres Flight von der Pre-contact Position zum Boom ging. Bei mir laggte es wie Sau und meine Flightmember berichteten von wilden Warps meines Jets


    Falcon bzw. BMS ist eine extrem pingelige Diva was die Online-Performance anbelangt, dieser Fakt ist den Misssion-Hostern leider nur zur Genüge bekannt. Leider ist der Support von BMS nicht der schnellste / beste, damit müssen wir leben.


    Würde es TeamSpeak endlich mal schaffen IPv6-Unterstützung zu implementieren (das IVC-Modul basiert ja darauf und nur daran scheitert IPv6 in BMS soweit ich weiß) wären viele Probleme mit der Onlinestabilität gelöst IMO :9:

    Danke für all Eure Hinweise zu diesem Problem. Sie helfen mir enorm bei der Fehlersuche bzw. bei der Findung der Optimierungsvorschläge für die TE-Bauer.


    Was ich in der Vergangenheit beobachtet habe, ist dass derjenige, der gerade am Tanker ist, eine deutlich erhöhte Bandbreitennutzung zum Server hat. Allerdings behaupte ich, dass NUR die Verbindung zum Server deutlich mehr beansprucht wird und die Verbindungen zu den anderen Clients "normal" läuft. Auch würde ich nicht von einem Host-Wechsel während des Tankens sprechen. Mit "erhöht" meine ich, ca. 800 kbit/s und höher und das also im Upload für den entsprechenden Client (genauere Daten muss ich noch messen). Wenn da natürlich was auf dem Weg zum Server verloren oder in's Stocken gerät, merken das natürlich auch alle anderen Clients. Eine weitere Vermutung meinerseits, BMS ist, wie Reaper schon erwähnt hat, sehr pingelig (man könnte auch "histerisch" sagen) wenn es um Verbindungsstabilität geht und wirft bei der kleinsten Abweichung bereits das "blaue" Handtuch! Wenn also beim Tanken ständig Daten fehlen, könnte ich mir gut vorstellen, dass das früher oder später zum Crash führt.


    Leider hatte ich die letzten Tage wegen einer starken Erkältung keine Zeit, um meine Mission Bandbreiten-technisch zu messen.


    Mit dem super Hinweis von Hummer, werde ich diese Tests aber umgehend in Angriff nehmen und hier sicher wieder berichten, allenfalls natürlich auch im BMS-Forum.


    Gruss
    Pitbull

    Zitat von Pitbull

    Auch würde ich nicht von einem Host-Wechsel während des Tankens sprechen.

    Hi Pitbull,


    das ist tatsächlich so, siehe BMS-Manual S. 286:

    Zitat

    What happens during refuel is that the ownership of the tanker is transferred from the host to the successive clients. Consequently, when the client refuels, it becomes his responsibility to perform the tanker's "position updates". This clearly appears on this graph, created with 4.32. When the client refuels, there is a 15 Kbit/s "trade" of data between the server and the client, which corresponds to the tanker's position updates.

    Der Teil des Manuals von S. 280 bis 294 ist überhaupt extrem interessant für BMS-Serveradmins. Wer hätte z.B. schon gedacht dass Flares/Chaffs absolute Bandwidth-Killer sind :10:

    Hi Reaper


    Genau das meine ich. Während dem Refuel übergibt der Game-Host dem Tankenden den Tanker und dieser Client rechnet den Tanker selbst und übermittelt diese Daten wieder dem Server. Der Game-Host bleibt aber immer beim ursprünglichen Host/Server.


    Nach einer ersten Messung vermute ich allerdings, dass der Tanker nicht das Problem unseres Crashes von letzter Woche ist. Der Ansprung bei der Bandbreite hatte einen anderen Grund, nämlich der zeitgleiche SEAD-Angriff der KI im Zielgebiet.


    Die Bandbreitenbelastung beim Refuel ist vermutlich deutlich geringer, als ich ursprünglich angenommen habe. Ich habe da den Fehler gemacht, dass ich die Gesamtbelastung angeschaut habe.
    Ich bin gerne bereit, für genauere Messungen der Bandbreite während dem Refuel eine kurze Online-Session mit ca. 4 Piloten (plus mich) anzubieten. Eventuell habe ich am nächsten Montag ab 2100 Uhr Zeit.


    Gruss
    Pitbull

    Möchte mich jetzt nicht zu weit aus dem Fenster lehnen, da ich nur über ein gefährliches Halbwissen verfüge 8) !


    Für mich als TE-Bauer wäre es aber sehr Interessant zu wissen, wo ist die Grenze bei KI-Flights, was dürfen die in der Zeit wenn Humans online sind maximal machen etc.


    Da ich gerne viele KI-Flights einbaue und die ja auch Chaffs/Flares verwenden (Bandbreitenproblematik Reaper) oder Angriffe fliegen (Bandbreitenproblematik Pitbull).


    Vielleicht sollten wir mal eine Testgruppe von 4 Piloten oder mehr bilden und die Messergebnisse im Einzelnen beleuchten, damit man als TE-Bauer einen besseren Einblick bekommt, was geht und was ist no go!


    Salute
    Rabbit

    Ja, schon klar, das Game an sich bleibt beim Server.


    Allerdings ist es gefährlich die Bandbreite beim Tanken zu unterschätzen: der Tankende hat ja nicht den Upload zum Server sondern zu jedem einzelnen Client der sich in der Bubble befindet! Solange man alleine beim Tanker ist ist das ja kein großes Ding, aber das multipliziert sich dann ganz schön hoch wenn man an seine Flightmember und ev. andere Humans in der Nähe denkt.


    Mit nur einem zweiten Client als Wingie (in diesem Fall gleichzeitg der Gamehost) hat der Tankende einen Anstieg von 15 Kbit/s im Upload zu verzeichnen, sind dann noch drei weitere Humans im Flight und vielleicht auch noch weitere Clients in der Bubble mulitpliziert sich dass dann hoch. Bei wenig Upload wirds dann schnell mal eng :9: