HX3 Foren

HX3 Foren (https://hx3.de/)
-   Multiplayer Community (https://hx3.de/multiplayer-community-136/)
-   -   Armaserver unter virt. System? (https://hx3.de/multiplayer-community-136/armaserver-virt-system-15390/)

Mr.g-c 26.10.2008 21:56

Armaserver unter virt. System?
 
Hi, hat schonmal jemand versucht den Armaserver unter Wine order per VmWare laufen zu lassen - sprich die Windows-Version unter Linux?
Wie stark wird ca. der Performanceverlust ausfallen?

burns 26.10.2008 22:30

Laut Atomic funzt OFP seit kurzem erst auf Wine.
Bei ArmA würd ich also nicht von ausgehen das es schon geht, er meinte aber das käme wohl bald.

Performance, kA.

Linux rult bittedanke :)

Mr.g-c 26.10.2008 22:47

Ok laut WineHQ geht es "fast":p Wine AppDB - Armed Assault 1.x European
Server muss man halt testen. Frage ist brauche ich eine GUI oder kann ich alles per Konsole verwalten?

anders^on 26.10.2008 23:02

Zitat:

Zitat von Mr.g-c (Beitrag 199050)
Wie stark wird ca. der Performanceverlust ausfallen?

Wenns läuft, dann nur soviel Verlust wie sich VMWare & Windows eben nimmt.
Durch Wine hast du prinzipiell keine Geschwindigkeitsnachteile. Flickflack hatte
schonmal Wine benutzt, wenn mich nicht alles täuscht. Vielleicht kann er dir
da helfen.

Mr.g-c 27.10.2008 09:53

Hi, werd es in einer Virtuellen Maschine KVM+QEMU laufen lassen. Der "Verlust" soll in der Kombo bei ca. 1-3% liegen - lachhaft bei 4GHZ E8400.

Danke euch nochmal - werde berichten sobald es was neues gibt. :daumen:

flickflack 27.10.2008 10:04

Also WINE geht imho nicht. Haben wir zumindest nie zum laufen bringen können. Da gings nur bis OFP 1.96c (.exe), dass WINE mit dem Server klar kam. Wir haben dann den VMWarePlayer hergenommen, nen Win2k in einer VM installiert und ArmA rauf. Ging, allerdings semi-schön, eher langsam. Besonders der Datenverkehr war nicht wirklich schnell, ich glaube mehr als 15 Mann konnten wir damit auch nicht lagfrei betreiben. Nun gibt's Linuxserver, also haben wir uns leichten Herzens von der VM-Lösung verabschiedet. Nen Versuch ist es allemal wert, sofern der Server (physisch) genug Pepp unterm Kessel hat und mit vielen Cores der VMWare (oder sonstigem) zeigen kann, wo der Frosch die Locken hat. Viel Erfolg ;)

Mr.g-c 27.10.2008 11:50

Der VMware player ist bullshit im vergleich zur Hardware Virtualisierungslösung die ich im obigen Post genannt hatte.

flickflack 27.10.2008 12:31

Das mag so gewesen sein, allerdings unterstützt VMWare mittlerweile in unseren ESXs die VTs der Intel-Cores. Du wirst recht haben, dass QEMU da sinnvoller arbeitet, weil es Emulation und Virtualisierung afaik getrennt beherrscht (in Kombi mit KVM), VMWare hier aber beides gleichzeitig durchwürfelt. Wir hatten damals (2006) einfach was probiert, wenn Du jetzt auf schnellere Lösungen kommst, toll. KVM stellt Infrastruktur, QEMU emuliert. In den allseits beliebten Foren war damals die Rede von "QEMU kommt an VMWare ran" (Emu-Speed), da wir atm kein Bedarf an virtualisierten ArmA-Servern haben, haben wir auch nicht weiter nachgeforscht...wozu auch...und von diesem Stand hab ich berichtet. Das war weder ne Empfehlung noch sonstwas.

Mr.g-c 27.10.2008 13:03

Ich weiss... war ja nur auf den VmWare player bezogen.
DU scheinst dich damit ja ganz gut aus zu kennen. Frage, denkst du es ist möglich ein WinXP image hier zu erzeugen, den IDE Treiber-Reset von MS anzuwenden (nutzt man bei Mainboard wechsel), das image zu packen, auf den server zu laden und von dort aus zu mounten+ zu starten?

flickflack 27.10.2008 14:26

Ne die Gurus für VMs sitzen woanders ;)

Wir hatten die VM zu Hause vorbereitet und dann übers Internet von lokal auf Server das OS installiert. Kommt sicher auch auf die Virtualisierungslösung an, aber bei VMWare bin ich mir recht sicher, dass es geht. Wenn Du bei dir zu Hause die VM vorbereitest und dann darin das passende OS installierst, sollteste die VM nehmen können, die hochladen und auf dem Server mounten können (eventuell Konvertierung wegen ESX pipapo), und eigentlich auch ohne IDE-Reset. Die Treiber für die virtuelle Hardware sind schon in die VM eingebacken. Oder habe ich Dich falsch verstanden?! Willst Du von Deinem Server-OS nen Image ziehen (plus anderen Kram) und das inne VM packen?! Weil dass ginge afaik mit VMWare auch. Du machst aus Deinem aktuellen System nen Image und importierst es in eine VM - will nix falsches sagen, aber imho geht das. Bei KVM+QEMU müsstest Du allerdings wirklich nen Profi ranziehen, der dir das en detail und vor allem 100% korrekt sagen kann ;)

Mr.g-c 27.10.2008 14:36

Hi danke für die Antwort...
Also wir haben einen Server der logischerwise im Rechenzentrum steht - nur SSH zugang (Konsole), also kein Desktop.
Also, ich habe hier einen zweitrechner, auf dem würde ich Linux installieren, KVM+QEMU installieren, eine Virtuelle Maschine starten, darauf Windows XP Intsallieren, Remotedesktop einrichten, diese Virtuelle Maschine, also die Virtuelle Partition dann packen, auf den Server im Rechenzentrum schieben, dort ebenfalls KVM+QEMU einrichten, die Virtuelle partition mit XP starten, und mit Remotedesktop connecten.:naughty::naughty:

flickflack 27.10.2008 16:58

Joar guter Plan ;) Schubs das mal an und berichtet mal wie sich die Kiste unter Last verhält. Is eigentlich ne schön schlanke Lösung!

Edit: Darf ich fragen, weshalb Du nicht direkt den Linuxserver wählst? Wolltest Du einfach mal profilen?

Mr.g-c 27.10.2008 19:19

Wir haben schon lange einen Linuxserver laufen.... "arma-rpg.com".
Problem ist für unser neues Missionstechnisches "Ding", brauchen wir eine anbindung von der Arma Engine an eine Datenbank. Und nur Armalib von Kegetys kann das - läuft NUR unter Windows und wird nach kontakt mit ihm NIEMALS für Linux rauskommen.:rolleyes:
Klar jetzt könnte man sagen, lass doch vom Hoster gleich Windows Server 2003 od. 2008 aufsetzen - wollen wir aber nicht da auf dem Server ebenfalls ein Webserver mit mehrern Seiten/Foren läuft, der nur unter Linux so performant (mit. div. PHP-Opcode caches) und zuverlässig läuft. Windows als Apache/PHP/MySQL Webserver ist einfach Müll.
Deshalb kann man nur per Virtualisierung zur Lösung kommen.
Das ist der Grund

Performance: Intel Core2Duo E8400 @ 2x4.0GHZ, 4GB DDR2-1066, 2x 500GB SATA2 Platten. Solte da Arma nur Single-Core optimiert ist, so ziemlich einer der schnellsten/der schnellste Arma-Server da draussen sein.
Vergleich in Server-FPS: Alter Server war ein Athlon X2-5600+ (2.9GHZ), 2GB RAM DDR2-800. FPS bei Sahrani-Life:Reloaded mit ~32 Spielern 2FPS - mit battleye manchmal nur 1 FPS.
Mit neuem Server selbe Mission 32 Spieler: niemlas unter 6FPS (beinahe 3 mal so schnell unter maximaler Auslastung/Spieledauer)
Brits XR-Server - QX6xxx @3.5GHZ (Brit-XR alias Robert war lange teil unserer community) ist langsamer.

Lester 28.10.2008 09:13

6FPS und schnell bei einem derartigen Server ?
Bei dem Wert würde eine KI schon in den Dauer-brotzeit-siesta-modus gehen das da sich die Betonwände schneller bewegen. :rolleyes:

Schon mal überlegt die Scripte der Mission *räusper* "etwas" zu optimieren ?
Das ist ja wohl alles noch sqs oder wie schafft man es sonst einen derartigen Server dermaßen auszubremsen ? :stupid:

Mr.g-c 28.10.2008 09:37

Zitat:

Zitat von Lester (Beitrag 199312)
6FPS und schnell bei einem derartigen Server ?
Bei dem Wert würde eine KI schon in den Dauer-brotzeit-siesta-modus gehen das da sich die Betonwände schneller bewegen. :rolleyes:

Schon mal überlegt die Scripte der Mission *räusper* "etwas" zu optimieren ?
Das ist ja wohl alles noch sqs oder wie schafft man es sonst einen derartigen Server dermaßen auszubremsen ? :stupid:

Sahrani-Life player vs. Player keine AI - Muss ich mehr sagen? :lol:
Die Mission läuft manchmal 1-2 Wochen am stück und da werden massiv Variablen genutzt, gespeichert, geupdated, etc... kann man mit NICHTS anderem Vergleichen. Ok Warfare und CTI werden einen Server warscheinlich noch mehr Lahmlegen.
Brit hatte mal gesagt das das OFP CTI was die nutzen den "anderen" Server (Q6600 - 4gb RAM) auf 1FPS brachte - permanent

Ich werde dich mal ein Bisschen aufklären zur Server-FPS :confused::

Die "alte" FPS-Methode (pre-1.15 Server):

Ein Arma-Server läuft "schnell genug" bis ca. 3 FPS (zumindest ohne AI). Ab 2 FPS merkte man das leichte LAGs zunehmen (und JIP LAGs verheerend werden) und der Server plötzlich "Zeit" braucht gewisse Dinge zu tun. Trotzdem noch absolut Spielbar in PvP und wenn man den Server dann "locked" bleiben auch die LAGs aus.
Wir haben das immer an einem Pop-Up Ziel getestet - ab 2 FPS braucht es plötzlich deutlich länger bis es wieder hochgeklppt ist, ebenfalls "hängt" dann das hochklappen 2mal, während es bei 3FPS noch in einem bis zwei zügen geschieht ( das tut es auch bei 50+ FPS).
Achja mit dem Neuen Server haben wir Werte die es eigentlich nicht geben sollte - also mit ca. 10 Spielern am Anfang der Mission kommen wir bis auf 64FPS :confused::ugly::zahn:... obwohl 50 das maximum sein sollte... die CPU Auslastung liegt dann in der Linux Prozessübersicht bei 15% :lol:
Zum Vergleich: Beim alten Athlon X2-5600+ hatte wir bei der selben Mission direkt am Start mit nur EINEM Spieler connected, max. 48FPS und Prozessorauslastung bei 65-75%.
Also der E8400 bei 4GHz ist DEUTLICH schneller, mehr als doppelt so schnell würde ich fast sagen. Auf beiden lief/läuft Debian 4.0 64bit

Mal ein alter Screen mit bis zu 61FPS (E8400 4GHZ):
http://img368.imageshack.us/img368/3...nfpsrm9.th.jpghttp://img368.imageshack.us/images/thpix.gif


Die "neue" FPS-Mehtode (ab 1.15 Server):

Bleibt abzuwarten....:zahn:
Suma sagte das der Momentane weg die Server "FPS" Zahl zu bekommen "falsch" sei (seit OFP nehme ich mal an)..... und Server die 5FPS anzeigen in wirklichkeit bei 50FPS+ liefen. Nur dadurch das die Falsche FPS-Zahl momentan noch zur Bandbreiten-Verteilung/Verwaltung der Clients & zw. Server & Clients genutzt wird, entstehen diese tollen JIP-Lags.
Also wird wohl die FPS-Zahl generierung bei den neuen Dedicated Servern ganz anders aussehen, daher das man die FPS nicht mehr aus dem Rendering-System abliesst wie bisher (obwohl der Server eigentlich garnichts rendern sollte).:komisch:

Zitat Suma:
Zitat:

For bandwidth control the game needs to know approximate frame duration, so that it knows how much information it should try to send in one frame. What we do is we ask rendering subsystem to tell us average fps for last 16 frames, as this is something rendering already knows. Now the problem is on the dedicated server there is no rendering done at all, and the fps returned by the rendering subsystem is wrong - often numbers like 5 seconds are returned when in fact server is running at 50 fps. We will fix this by not relying on rendering when quering fps for this purpose. We are convinced this fix should not only greatly reduce the JIP caused lag and desync, but hopefully improved bandwidth control and balancing overall.

Lester 28.10.2008 12:19

Zitat:

Zitat von Mr.g-c (Beitrag 199318)
Sahrani-Life player vs. Player keine AI - Muss ich mehr sagen? :lol:

Ich kenn (offensichtlich zum Glück) Sahrani-Life nicht, ich hab da nur einiges drüber gelesen.
Aber lass mich raten ... viele SQS Scripte ?
Gerade wenn es nur PvP ist, dann wird ohnehin der Großteil der Arbeit aus Lokalitätsgründen den Clients aufgelastet werden müssen.

Zitat:

Zitat von Mr.g-c (Beitrag 199318)
Die Mission läuft manchmal 1-2 Wochen am stück und da werden massiv Variablen genutzt, gespeichert, geupdated, etc... kann man mit NICHTS anderem Vergleichen.

Aha ... und wo ist jetzt das Problem ?
Egal wie häufig man Variablen benutzt oder updated ... das hat keinerlei negative Einflüsse.
Außer natürlich ein "Held" schafft es massiv Variablen zu generieren diese aber nach Gebrauch nicht zu vernichten, dann wird es irgendwann eng werden.

Allerdings kenn ich nicht das ArmA-Verhalten inwiefern die Routinen über einen solchen Zeitraum laggy verhalten.
Fragen wir mal so, in welchen Zeitraum brechen die Serverframes dann unter 20 ein ?

Jedenfalls ist die Menge der gesendeten Daten ja eher sehr gemütlich mit durchschnittlich 300KBPS.;)

Mr.g-c 28.10.2008 12:30

Zitat:

Ich kenn (offensichtlich zum Glück) Sahrani-Life nicht, ich hab da nur einiges drüber gelesen.
Aber lass mich raten ... viele SQS Scripte ?
Gerade wenn es nur PvP ist, dann wird ohnehin der Großteil der Arbeit aus Lokalitätsgründen den Clients aufgelastet werden müssen.
Nein, sind ca. 200 sqf scripte. Alleine die Scripts sind über 2mb. Kein einziges sqs.
Die mission ist wirklich extrem optimiert und ressourcenschonend aufgebaut, aber bei all den möglichkeiten die man in der mission hat ist das kein Wunder.

Zitat:

Aha ... und wo ist jetzt das Problem ?
Egal wie häufig man Variablen benutzt oder updated ... das hat keinerlei negative Einflüsse.
Außer natürlich ein "Held" schafft es massiv Variablen zu generieren diese aber nach Gebrauch nicht zu vernichten, dann wird es irgendwann eng werden.
Richtig, die werden NIEMALS gelöscht, da jeder spieler der nach Trennung wieder joined, sein exaktes Geld wieder auf der Bank hat, all sine Lizenzen (wie führerschein, Waffenschien, etc.) wieder bekommt und auch den schlüsselbund mit Fahrzuegschlüsseln wieder hat + andere Dinge wie kills, tode etc um die dynamische Respawnzeit zu generieren.

Zitat:

Allerdings kenn ich nicht das ArmA-Verhalten inwiefern die Routinen über einen solchen Zeitraum laggy verhalten.
Fragen wir mal so, in welchen Zeitraum brechen die Serverframes dann unter 20 ein ?
Kann man Pauschal nicht sagen. Bei SL:R 1.01 war es mit 28-32 spielern nach ca. 5 Stunden unter 20FPS. Je mehr verschiedene Spieler joinen und das Spiel wieder verlassen desto mehr Variablen muss der Server für diese Spieler zwischenspeichern. Die 6 FPS kommen wirklich erst nach mehreren Tagen (ich sag mal ab 1.5 Tagen - 36 Stunden), da wie bereits angedeuted für 100derte Spieler die ganzen Variablen gespeichert wurden.

Übrigens ist das auch der grund warum wir genau diese Variablen nun in einer SqLite Datenbank mittels ArmaLib speichern werden.

Zitat:

Jedenfalls ist die Menge der gesendeten Daten ja eher sehr gemütlich mit durchschnittlich 300KBPS
Hi, ja in dem Screen waren das evtl. 5 Spieler - ich weiss es nimmer....

Lester 28.10.2008 15:17

Zitat:

Zitat von Mr.g-c (Beitrag 199326)
Hi, ja in dem Screen waren das evtl. 5 Spieler - ich weiss es nimmer....

Nuja, wir haben dann schon mal deutlich höhere Werte, allerdings laufen da auch noch "einige" KI's rum.

Mr.g-c 28.10.2008 15:38

Zitat:

Zitat von Lester (Beitrag 199335)
Nuja, wir haben dann schon mal deutlich höhere Werte, allerdings laufen da auch noch "einige" KI's rum.

Jop, kann ich mir gut vorstellen....:zahn:
Bei 32 Spielern haben wir auch gute 2-3MBIT Upstream & ca. 0.8Mbit Downstream auf em Server (wenn ich mich recht erinnern kann)


Alle Zeitangaben in WEZ +1. Es ist jetzt 08:47 Uhr.

Angetrieben durch vBulletin, Entwicklung von Philipp Dörner & Tobias


SEO by vBSEO 3.2.0 ©2008, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119