Dedicated Client / Headless Client feedback (dev branch)

[gabberxxl 9]

​

Is it normal that my HC's have only 25 CPS max?

 

 

 

It's at 25 CPS even with 0 AI.

 

​Other mission, same issue. CPS on the hc are low and sometimes bounce up and down. Never had this before...

​

​

​

​

[omon 19]

Hi Dwarden,

We running BECTI Seattle server, and planning to switch from windblows to Linux.

Linux server runs perfect and smooth as butter, but headless client has problems.

 

HC will not work on more than 1 cores. If you don’t assign it -coreCount=1 it will crash in 2 min.

There is another guy on Redit having exact same issues.

I tried the latest PREF server “arma3server_performance_154_134149_v15_linux.zip, didn’t help.

 

Its running on Ubantu 14

Here is HCs startup parameters

./arma3server -client -connect=10.10.0.108 -name=HC2 -world=empty -nobenchmark -high -noSound -mod=startup/@hc -password=1 -cpuCount=1

 

Any ideas?

[Dwarden 1125]

ok, will check into that

question: got any core-dump from HC crash on Linux ?

just for your information "-high is non-existent command-line parameter (typical urban myth from Windows OS /HIGH parameter for CMD)

note, there're several known issues with HC on Linux

with calculating hashes from many .bisign files (WIP)

when over (500-512+) addons then something breaks (investigated)

[onefox 1]

@omon, @dwarden

 

Check out the ticked, i guess its exactly that problem.

http://feedback.arma3.com/view.php?id=27172

 

The thing is that you will get just an:

"Player headlessclient: Signature check timed out"

error in the server rpt log. So no crash.

 

[Dwarden 1125]

ok, that should be wip

[omon 19]

@omon, @dwarden

 

Check out the ticked, i guess its exactly that problem.

http://feedback.arma3.com/view.php?id=27172

 

The thing is that you will get just an:

"Player headlessclient: Signature check timed out"

error in the server rpt log. So no crash.

 

Yep! Thanks for clarification! Cant wait for fix  :)

[TimeXtreme 1]

Hello,

 

i have got the same problems with the linux dedicated server and headless client. Yesterday i updated the server and the headless client is kicked directly even with cpuCount=1. The version before (from primary EDEN update) was able to connect for 2h, than i get a verify signature timeout. Now the HC is kicked directly:

 

18:24:46 BattlEye Server: Verified GUID () of player #0 headlessclient
18:24:46 BattlEye Server: Player #0 headlessclient - Owner GUID: XXX
18:24:50 Player headlessclient: Wrong signature for file /srv/arma3/@life_hc\addons\life_hc.pbo

On windows i got no problems with verifySignature=2. 

life_hc isnt loaded on server process but signed with registered bikey in the /srv/arma3/keys folder. And its only one bikey here with the default a3.bikey.

 

Should i migrate to windows? 

It would be the best to deactivate the signature check only on the HC... 

[anoX666 0]

I can only confirm what TimeXtreme reported.

 

Ran a Linux Server couple of weeks ago. Had performance issues so I switched over to headless client. Then the signature fails started. Never figured out what caused the problem. Is Linux headless even officially supported??

[doveman 7]

Dear BI

 

I understand that altering A3 to make it use more than 2 cores would be very hard. What I don't understand is why you can't do the following.

 

If A3 (SP client or server) is launched with -cores=4, automatically launch a HC process as well as the client or server. Then have A3 automatically transfer AI to the HC process, without missions having to be scripted to do this. This would improve performance/allow higher AI missions in SP and MP, without users or authors having to faff about. Surely it can't be that hard to change the A3 code to achieve this, perhaps by having it dynamically insert the necessary scripts (i.e. the ones authors currently have to add manually) into the mission before running it (although I daresay there might be a better way of doing it)?

 

Perhaps this could even be scaled up, so if launched with -cores=6 or =8, automatically launch 2 or 3 HC processes and intelligently divide the AI/scripts amongst however many HC's there are?

[omon 19]

Dear BI

 

I understand that altering A3 to make it use more than 2 cores would be very hard. What I don't understand is why you can't do the following.

 

If A3 (SP client or server) is launched with -cores=4, automatically launch a HC process as well as the client or server. Then have A3 automatically transfer AI to the HC process, without missions having to be scripted to do this. This would improve performance/allow higher AI missions in SP and MP, without users or authors having to faff about. Surely it can't be that hard to change the A3 code to achieve this, perhaps by having it dynamically insert the necessary scripts (i.e. the ones authors currently have to add manually) into the mission before running it (although I daresay there might be a better way of doing it)?

 

Perhaps this could even be scaled up, so if launched with -cores=6 or =8, automatically launch 2 or 3 HC processes and intelligently divide the AI/scripts amongst however many HC's there are?

keep dreaming dude..

after 14 years not much has changed, hope BIS will spend less time on DLC's and spend more time on improving the game and making it 64 bit and multi core! 

[doveman 7]

keep dreaming dude..

after 14 years not much has changed, hope BIS will spend less time on DLC's and spend more time on improving the game and making it 64 bit and multi core! 

You're missing the point of my request. I know it's too hard for them to make A3 64-bit and multi core compatible (maybe A4, we can live in hope!), what I'm suggesting is that they adapt the HC functionality that is already available to automatically use the extra cores for the AI and scripts in every mission, instead of authors and users having to jump through hoops to make that happen.

[B1acksh33p 1]

I was able to overcome the "signature check failing" on linux by starting the hc with

 

./arma3server -cpuCount=1 -client -nosound -connect=127.0.0.1 -port=2302 -mod=@exile;@A3XAI_HC -profiles=hclogs

 

This way I am observing now that the HC disconnects with a signature check failure after 150 minutes "only". Basically the -cpuCount=1 did the trick. I could not see any difference using the perfromance or standard build of arma3server.

 

 @Dwarden: Is this topic actively under investigation? Meanwhile I see that several postings handling this issue. My workaround is now to restart the HC every 150 minutes via cron job.

 

Regards,

Blacksheep

[B1acksh33p 1]

I can only confirm what TimeXtreme reported.

 

Ran a Linux Server couple of weeks ago. Had performance issues so I switched over to headless client. Then the signature fails started. Never figured out what caused the problem. Is Linux headless even officially supported??

 

 

 

Hello,

 

i have got the same problems with the linux dedicated server and headless client. Yesterday i updated the server and the headless client is kicked directly even with cpuCount=1. The version before (from primary EDEN update) was able to connect for 2h, than i get a verify signature timeout. Now the HC is kicked directly:

 

18:24:46 BattlEye Server: Verified GUID () of player #0 headlessclient
18:24:46 BattlEye Server: Player #0 headlessclient - Owner GUID: XXX
18:24:50 Player headlessclient: Wrong signature for file /srv/arma3/@life_hc\addons\life_hc.pbo

On windows i got no problems with verifySignature=2. 

life_hc isnt loaded on server process but signed with registered bikey in the /srv/arma3/keys folder. And its only one bikey here with the default a3.bikey.

 

Should i migrate to windows? 

It would be the best to deactivate the signature check only on the HC... 

 

 

From my observations your issues are moire related to the signature of the HC than to the HC itself. Check your key directory if there is a key for your HC. If not, check the HC distribution for life_hc.

 

Regards

Blacksheep

[Dwarden 1125]

yes, we working on the limit ,

afaik this will be via setrlimit() yet the ceiling default is 4096 (better than now 1024)

and unfortunately using ulimit to raise it beyond that works only on some Linux systems ;(

next what's being discussed is server.cfg option to disable verifySignatures for Headless Client completely

yet , there might be more bugs to slay in process, stay tuned

[B1acksh33p 1]

Thank you for this clear feedback.

 

IMHO disabling sig check for HCs would be a good workaround while disabling sig checks in general is not that good idea (for those who think about or already did it). 

 

Just for the records:

 

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63010
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1048576
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1048576
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
 

Running (well) in a docker container on top of Ubuntu 14.04 while the host is running debian 8. By the way: If you feel bored I can send you some cores from a debian 8 server where arma3server crashes frequently :-D (just kidding, I don't have really a need for this since meanwhile all is running fine within docker).

[B1acksh33p 1]

@dwarden: Is there any chance to get a prototype of a headless client for the stable branch which allows to disable the sig check for HC's? It is a little bit frustrating that the missions (e.g. FuMS) working for 1-2 hours only until the the hc failing the sig check. While the HC for A3XAI can reconnect the HC for FuMS waits infinite for a server token after a restart in the middle of the game. I am assuming that the server token is never send again when the HC was already connected successfully. I have no clue how much work it is but this could really improve the stability of the HCs. Just a kind feature request...

 

I am willing to test this and provide feedback / data if needed...

[etzu 4]

After much testing, it appears that the headless client does not adhere to the new "skip waypoint" trigger. However all other triggers seem to work correctly. Can anyone else confirm?

[Dwarden 1125]

@b1acksh33p see the 1.56.135357 performance binary for Windows & Linux https://forums.bistudio.com/topic/160288-arma-3-stable-server-156-performance-binary-feedback/page-68?p=3005240#entry3005240

 

as I explained elsewhere, first there is fix related to maximum of opened files increasing it as much as possible (cause it's simple to do)

 

the ability to disable signatures (be it op*tin or opt-out is just detail) for headless-client isn't as easy (and shall be there for testing/QA at minimum)

[B1acksh33p 1]

@dwarden: Thanks, but the latest performance build was already in place since 7th April. My conclusions:

 

1.) Running the latest performance build as server AND client

A] Server with cpuCount=7 and client cpuCount=1 -> Sig check failing after initial hc connect

B] Server with cpuCount=6 and client cpuCount=2 -> Sig check failing after initial hc connect

 

2.) Running the latest performance build as server and the common build as client

A] Server with cpuCount=7 and client cpuCount=1 -> HC's connects and runs for a while (up to 150 minutes) until failing sig check. A3AIX HC can reconnect when HC's are restarted, FuMS not

B] Server with cpuCount=6 and client cpuCount=2 -> Sig check failing after initial hc connect

 

Let me know if I can collect some data for you.

 

Menwhile I will be patient and wait for the version which as the option to disable sig checks for HCs. But I am willing to test it on my own risk as soon you have a prototype ;) I have a testing environment which can be rebuild in seconds using snapshot technology.

 

[Edit & Update]

After a complete server restart it seems that the HC's does not disconnects anymore with option "2. A]". Will monitor this for the next arma3server restarts and report back at 4 PM CEST

 

[Edit & Update 2]

Nope, just a wet dream... HC's are still disconnecting:

12:00:11 Dedicated host created.
12:00:14 BattlEye Server: Initialized (v1.210)
12:00:14 Host identity created.
12:00:14 Game Port: 2302, Steam Query Port: 2303
Arma 3 Console version 1.56 : port 2302
12:00:14 Mission Exile.Altis read from bank.
12:00:14 Roles assigned.
12:00:14 Reading mission ...
12:00:22 Mission read.
...
12:00:32 headlessclient uses modified data file
12:00:32 BattlEye Server: Player #0 headlessclient (127.0.0.1:2316) connected
12:00:32 Player headlessclient connecting.
12:00:33 Player headlessclient connected (id=HC27986).
12:00:33 BattlEye Server: Verified GUID () of player #0 headlessclient
12:00:33 BattlEye Server: Player #0 headlessclient - Owner GUID: 8539e01499f87083b3a25eb30041261c
12:02:03 headlessclient uses modified data file
12:02:03 BattlEye Server: Player #1 headlessclient (2) (127.0.0.1:2328) connected
12:02:03 Player headlessclient (2) connecting.
12:02:04 Player headlessclient (2) connected (id=HC28032).
12:02:04 BattlEye Server: Verified GUID () of player #1 headlessclient (2)
12:02:04 BattlEye Server: Player #1 headlessclient (2) - Owner GUID: 8539e01499f87083b3a25eb30041261c

...
14:30:52 Player headlessclient: Signature check timed out
14:30:53 Player headlessclient disconnected.
14:30:53 BattlEye Server: Player #0 headlessclient disconnected
14:32:27 Player headlessclient (2): Signature check timed out
14:32:27 Player headlessclient (2) disconnected.
14:32:27 BattlEye Server: Player #1 headlessclient (2) disconnected

[pierremgi 4875]

If you could do something for that: At least make Headless client as a "logic" instead of "man":

https://forums.bistudio.com/topic/190256-headless-clients-strange-men/

[BetterDeadThanZed 16]

I'm having an issue with a HC set up with an A3 Epoch server. The HC connects to the server but it doesn't get past the lobby. In my mission.sqm, I added this for the HC:

		class Item105
		{
			dataType="LOGIC";
			class Vehicles
			{
				items=1;
				class Item0
				{
					position[]={1127.307,148.41647,10095.988};
					id=0;
					dataType="LOGIC";
					vehicle="HeadlessClient_F";
					player="PLAY CDG";
					leader=1;
					skill=0.60000002;
					text="HC";
					forceHeadlessClient = 1;
				};
			};
		};

This is the output from the HC window when it connect to the server:

16:49:32 Dedicated client created.
16:49:45 Client connected: 127.0.0.1:2302
16:49:46  > Player headlessclient connecting
16:49:46  > headlessclient uses modified data file
16:49:46  > Welcome to Esseker.
16:49:48  > Player headlessclient connected

Any suggestions? Is my code in the mission.sqm wrong?

[tpmccusker 12]

So, I've been working with the headless client for about 6 hours now, and it is one of the most brilliant things I've ever seen in game servers.

 

I think the biggest problem is that the HC cannot connect to a Client hosting a game over the web, which almost undermines part of the success. It works on LAN, but that only kind of helps.

 

Still, extremely grateful, its an amazing little system!

[Dwarden 1125]

HC was made to work with dedicated server within LAN/localhost not for remote clients ...

there're several logical reasons it's done this way

[AdirB 18]

i have problem with HC it show me for a split a second that the HC is ready and back to hourglass icon any idea? i running the werthless headless module

its on the same machine do i need to open port? firewall? use "-port" on different port then the server?

[retromann 10]

HC was made to work with dedicated server within LAN/localhost not for remote clients ...

there're several logical reasons it's done this way

 

So it is not possibile to run the HC trough data center to data center? In my scenario I want to use a separate dedicated root server from another server provider. Thats not possibile, right? - Just for my understanding.