Sibolo

Eliteness did the job very well, Thanks.

There seems to be some problem with your pbo, can't extract files with cPbo or PboView.

Could you also share your mission so we can see what you mean. Thanks.

@Party3AH: Yes, the config could be very useful.

Looking at these I believe that you do have a CPU bottleneck (although it might not be the only problem). Basically my understanding is this: Your overall CPU is divided in 8 cores (4 real and 4 logical due to Hyperthreading). To use your entire CPU power the programs you are running should be able to spread the workload on all cores generating and using enough threads. This does not appear to be the case of the Arma server. From what I have seen on our server and on our mission, only 3 threads (out of about 15 created by the server) where actually using CPU power. One was maxing out it's assigned core, the other two where only using a fraction (around 10-20%) of their assigned cores. This basically sums up to what you point out to be 145% CPU load (on a 800% maximum). But I believe that the mistake in it's interpretation is that it's not using more CPU power, not because it doesn't need it, but because it is not capable of doing it. So you end up using only a small amount of your overall CPU but experience low FPS. Infact, in general, one thread can only be executed on one core, so if an application would generate only one thread it would never be able to use the remaining 7 cores, even if it was struggling for CPU cycles. My advice is to disable HT as this has shown to give better performance (almost a 100% increment in FPS) by not splitting the cores. The main thread will run on a complete core and so will have more CPU power assigned to it raising your FPS. But in my experience this has not been enough, we are still having quite low FPS on large player count, and have disabled BE because when the server occasionally lags (freezes) many players are kicked out by BE and have a hard time rejoining. Also having 20-30 people disconnecting at once and trying to reconnect is very hard on the server and makes things even worse. Good luck.

I'm trying to improve my mission optimization knowledge by studying other well known missions like the Valhalla (from Dao.nu) or the AAS series especially for large player count games. I am focusing on how the code is structured through the mission when you need to launch several scripts that will be running for the entire game. The way this is done in those missions is that all the scripts are sqf files that are precompiled at game start and stored into functions. Then you have a main thread (big loop) that calls (or spawns) those functions in sequence throughout the whole game. Something like: _a =precompile a.sqf; _b =precompile b.sqf; _c =precompile c.sqf; ... //Main thread while {true} do { call _a; call _b; call _c; ... }; Opposed to this style of mission creation, often you find simply calling the scripts in sequence, and each script is an infinite loop. Something like: _a= execvm "a.sqf"; _b= execvm "b.sqf"; _c= execvm "c.sqf"; ... where each script contains its loop: while {true} do { blah; blah; blah; ... }; I would like to discuss the pros and cons of these two styles and how important it is in terms of difference in mission performance. Thank you.

Good!!! (Although it is in fact a 100% improvement :cool:) As far as mission optimization that some of you mentioned, basically I inherited the mission file from the previous campaigns where we didn't have so many problems even with a higher player count (50vs50). I did change many things, but always trying to do my best to keep it optimized. Most of the scripts are running only client side, variables are sent through the network only if really needed and so on. Mission dimension is not always the most important fact (although big missions are often overbloated) as you can write only one line of code and if it's done wrong it will mess everything up. But there is always a lot to learn on this topic.

I can recognize the core usage pattern (at least for this mission) involving mainly 3 threads in three different cores. I'm also quite sure that disabling HT is going to give it a boost, but I don't know how much that will be in terms of FPS. Anyway I think the server managed the game quite well even with those 2 FPS, didn't see anything too strange and at the very end both vehicles and infantry units were moving smoothly. Did any of your guys complain about lags? There was only one point in time that I disconnected and couldn't see the server on the list and someone was asking me if the server was stuck, but it was only for a few seconds. I then reconnected succesfully and didn't have any problems for the rest of the game.

I understand that it does work in many cases to exit fom scripts and so it is widely used, but are there any alternatives? Maybe ones that will work inside EH?

Is there any circumstance a [left][color=#007700][font=monospace]while {[/font][/color][color=#0000BB][font=monospace]true[/font][/color][color=#007700][font=monospace]} do { [/font][/color][color=#007700][font=monospace]... ... }; [/font][/color][/left] loop will break out...some times I've seen it used like this: //Script.sqf while {true} do { waitUntil {somecondition}; code; code; code; }; execVM "script.sqf"; if (true) exitWith {}; and I interpret this that to be sure the script will always be active you put that execvm at the end just in case the loop breaks.

I often come across this line in scripts: if (true) exitWith {}; especially at the end of the script as the last line of code. Wouldn't the script end anyway? Why is it added? Other times this command is used in the following way: if (!isServer) exitWith {}; to limit the rest of the execution of the script only on non server machines. Reading from the Biki about the Exitwith command it is clearly stated that: exitWith exits the execution of a loop defined by one of commands do, for, count or forEach. When you use exitWith not inside a loops, the behaviour is undefined - sometimes it may exit the script, sometimes some other scope, but this is not intended and designed behaviour of this command, and it is not guaranteed to work reliably. It exits the loop only, not the script. So why is this so widely used, and what would be the "correct" way to end script execution? Thank you.

I am analyzing some script's performance and have come across this situation a few times. Basically in some scripts you need to wait for a specific condition to be true then execute the code and get back to the start waiting for the condition to be true again. Many times I see it solved in this way (only an example): Wait for condition; execute code; call script again; //Script.sqf waitUntil {somecondition}; code; code; code; execVM "script.sqf"; if (true) exitWith {}; I would like to know the pros and cons, and if this could be improved or done in a completely different manner that will give better performance as this script is going to be ran several times. Thank you.

Yes, we run CO so that setting may need to be adjusted.

Ok so based on informations from this thread I've written a new server config file: This is because it is intended for an 80 people PvP, with no AI, on a 100mbit connection. The mission usually runs at 10-15 FPS (even lower) so the math I applied was this: CLIENTS x MAXMESS x PACKETSIZE x FPS = BANDIWTH REQUESTED 80 x 64 x 1024 x 15 = 78643200 I still have to test this config but please comment it.

How about client side? Do we need to do this math too? Usually home connections don't have big upload bandwidth, so is there the need to set these parameters too?