Full FM for AI, the benefits

[unreasonable]

36 minutes ago, Mac_Messer said:

Well uuuh...you know. As long as they`re not accounted for losses in mission debriefing, it`s ok. I think ?

 

They were really written off - sometimes the pilots survived. So sometimes I avoided the RTB crashes, or the fly along like a moron while you land crashes, by giving a "wait here" command before descending to the field.   If you gave a "wait here" order when you were flight leader with four AI in V formation behind you, the ones on your left would break off and circle to the left, the ones on your right to the right: all good so far....   then they would complete the circle and crash into one another.  

 

Sometimes I felt more like a toddlers play-group supervisor than a dashing squadron leader...  BoX is better, overall, I think.

[LukeFF]

46 minutes ago, Mac_Messer said:

Well uuuh...you know. As long as they`re not accounted for losses in mission debriefing, it`s ok. I think ?

 

No, it's not, because those planes are then out of action.

[=362nd_FS=Hiromachi]

On 8/6/2018 at 1:27 PM, SAS_Storebror said:

From the Patch 3.005c release notes I understand that some multiplayer performance related changes are to be evaluated by beta testers. Let's hope that they really found some significant improvements there and that it's working well without breaking too many other things.

 

On 8/6/2018 at 2:20 PM, SAS_Storebror said:

No sir.

What we have now is strictly single thread.

According to Jason in AMA https://docs.google.com/document/d/1uXBkq7U2MmcEwvNLkB2MkKNLkcAMl0em5Arq4Zn68bA/edit engine is actually using mutiple cores. But honestly I must say I've never seen that, even recently testing stability of my 2700X I saw only one core loaded beyong 50-80 %, rest was idle or lightly loaded (10-15 %). Also, it seems that multiplayer fixes, at least in regard to netcode, might see some love after Bodenplatte is delivered.

[SAS_Storebror]

I beg to differ.

Jason apparently talks about the game Client.

Maybe that one makes better use of Multiple Cores and Threads, didn't care too much so far.

What I'm talking about is the dedicated server aka "DServer.exe".

That one is multithreaded and as such makes use of multiple cores too, however take a look at this yourself:

 

How much multicore support or multithreading is there in DServer.exe when one thread consumes more then 92% of the total CPU power used by DServer?

The next biggest consumer is the network stack with 2%, anything else is just negligible.

 

@edit: Note that the CPU usage percentage is calculated for all (virtual) cores. Since the system depicted here uses an i7-4770 with 4 physical cores and hyperthreading, the real usage per virtual core is the given values times 8.

This means that the "big" thread from DServer in the picture above consumes 59% of the CPU power he can get from that core.

 

Mike

Edited August 8, 2018 by SAS_Storebror

[LLv34_Temuri]

1 hour ago, =362nd_FS=Hiromachi said:

Also, it seems that multiplayer fixes, at least in regard to netcode, might see some love after Bodenplatte is delivered.

They said the same for Kuban. I won't be fooled twice.

Edited August 8, 2018 by LLv34_Temuri

[=362nd_FS=Hiromachi]

31 minutes ago, SAS_Storebror said:

Jason apparently talks about the game Client.

As I said, I saw nothing like that when testing my own machine and only one core was used. I may repeat this tests today in the evening with MSI Afterburner and HWINFO. Maybe there is a better software to get more complete picture of cpu usage and proceses each core / thread is handling ?

 

 

[SAS_Storebror]

Get the Sysinternals suite from Microsoft Technet and crank up the Process Explorer (64 Bit Version).

Double-click your process (IL-2.exe for the Client, DServer.exe for the dedicated server) and open up the "Threads" tab.

That'll give you an idea.

 

Mike

[kalbuth]

Multithreading is not a magical tool that adds CPU cycle as soon as you attach one task to a specific thread. I can see why a network part can kind of kill multithreading AI calculation. Problem may very well be that Dserver.exe is simply mostly network stuff, AI offloading is doing is part then waiting for network thread.

As for multithreading network stuff.... well, I don't have so much knowledge in it, I guess it can very fast end up in a nightmare.

Edited August 9, 2018 by kalbuth

[SAS_Storebror]

Sorry but --- no.

The network part is covered by the 2% CPU load thread, not by the 92% one.

Furthermore, from a CPU usage (and hence performance) point of view, it almost doesn't matter how many clients there are connected to the dedicated server.

Almost means: If the CPU load is 65% with 10 users connected, it's 60% when no one is connected at all in the very same situation.

The key to successful multithreading is to get thread concurrency handled correctly, which means don't create any race conditions, but keep things independent on as many threads as possible.

This comes true to networking stuff in the very same manner like it does for anything else.

Truth is that a single bottleneck in synchronization can kill your whole concurrency concept.

 

Mike

Edited August 9, 2018 by SAS_Storebror

[kalbuth]

Network things can be done outside of the common network stack il2 is using. Sending dgrams is trivial, but "network" is more than that. Making sure all clients are sync (ie receive consistent information at time X) is not going to be handled by a generic network stack unaware of content. I still see this as a network stuff

We don't really know how they wrote their code, do we?

We basically agree, I was just pointing out that multithreading in itself isnt the magic cure. It must be done properly and a synchro issue can render all moot. Could be the case for dserver.

Imho you're making things confusing by claiming the game is single threaded while knowing it's technically multithreaded. So the problem is not that the game or dserver is not multithreaded.

[SAS_Storebror]

Saying that a program is singlethreaded as an abbreviation for a program that technically uses multiple threads, but puts all the CPU heavy tasks into a single one, is quite common.

If it wasn't, then IL-2 1946 was a multicore winner 

Nevertheless, let's agree on "all the main work is done in a single thread", okay?

 

Concerning net replication: Sure, we don't know how it's being done.

Nevertheless it's no rocket science.

For instance, we know how network replication is being done in IL-2 1946 (well at least I do).

The key to success is that the server doesn't need to care for whether or not the client receives it's packets.

You send a stream of packets together with an auto-incrementing index.

If everything goes well, the client receives them all within a reasonable timeframe.

If not, the client goes out of sync and has to wait until the next "key" datagram drops in, which contains all the data required to get everyone back in sync again.

Clients connecting to the server have to wait for the next key datagram as well, for the very same reason.

That key datagram can come e.g. every 10 seconds, that's absolutely sufficient.

 

Both of these tasks can be completely decoupled from the remaining server logic, since in the opposite direction it works exactly the same way (clients send key datagrams every 10 seconds and inbetween, just small update packets).

The Server has five completely independent threads:

One deals with the server-internal logic.

One simply receives and forwards any client update packet to all other clients, fire and forget, and puts them in a local stream for the internal server logic.

One processes the update packet stream and applies it to the server's world.

One takes snapshots of the current world as the server has it, every 10 seconds.

One sends a key datagram with the latest world snapshot to all clients, every 10 seconds.

 

Mike

[=362nd_FS=Hiromachi]

On 8/8/2018 at 10:18 AM, SAS_Storebror said:

Get the Sysinternals suite from Microsoft Technet and crank up the Process Explorer (64 Bit Version).

Double-click your process (IL-2.exe for the Client, DServer.exe for the dedicated server) and open up the "Threads" tab.

That'll give you an idea.

Not sure how to read this, but I had to switch game to 1920x1080p in window mode to get accurate picture:

Also no clue whether changing to lower res and running in windowed mode can have any impact. Still, thats how it looks. 

[SAS_Storebror]

Since you have a Ryzen 7 with 8 cores and 16 threads, the numbers in the "CPU" column multiply by 16 in order to represent the corresponding load on a single (virtual) core.

We have 4 threads with significant CPU load, adjusted to single virtual core load:

1. 88.16% on Thread ID 9428, which according to the start address seems to be some internal 2D rendering engine from IL-2, based on the Autodesk Scaleform GFx C++ API.
2. 25.92% on Thread ID 23608, according to the start address this could be some internal logic from IL-2 (AI or whatever).
3. 15.68% on Thread ID 2464, apparently 3D related, NVidia API mapped into IL-2 process space.
4. 14.24% on Thread ID 25252, again some internal logic from IL-2.

All other threads are in the 1% range or below.

Obviously the Client with it's 3D rendering stuff utilizes more than just one (virtual) core because the load per virtual core exceeds 100% (all in all we're at about 150% here).

It's a bit surprising to see how much CPU load the Scaleform stuff causes - this is a 2D vector graphics rendering engine used for HUD stuff, map display etc.

The real 3D work is probably mostly in the 3rd Thread, the Nvidia one.

The load on Thread 1 and 3 is Client specific as DServer doesn't has such rendering stuff.

 

It's uncertain which of these threads are to be interlocked with each other and therefore are limited to the capabilities of one (virtual) core.

Most likely the rendering has lots of sync points, which would also explain why activating the HUD causes such a massive FPS drop often times - as you can see from your numbers, Thread 1 and 3 alone already exceed 100% on one virtual core, therefore if these are to be synced a lot, it's likely that the virtual core with the biggest load is capped at 100% already, thereby limiting the possible frame rate and representing a bottleneck.

 

Any more interpretation of those numbers would drift away into reading tea leaves.

 

Mike

Edited August 16, 2018 by SAS_Storebror

[=362nd_FS=Hiromachi]

I will take picture online just to see if multiplayer and singleplayer create any differences. As for 2d, that may be the case indeed. Any time I switch to map or launch stats online massive stutter occurs for a split sec., which is quite unpleasent.

Either way, it seems to me that use of resources is far from optimal in this situation.

[=362nd_FS=Hiromachi]

Here is the multiplayer:

I jumped on Berloga to get into quick action and results are not vastly different. Total usage is about the same and primary source is still that Scaleform eating about 74.88 % of resources. However 3d usage increased to 34.24 %, followed by ucrtbase.dll with 19.68 % and fmodex64.dll with 14.72 %. So total usage is 143.52 %. Not sure if that reflects the usage of more than one physical core or more than one logical. I assume the latter. 

[ACG_KaiLae]

I'll point out that VR users turn off the hud to get a large increase in framerate, which combined with the information above, would indicate that whatever they're using there isn't doing them a lot of performance favors. 

[ZachariasX]

5 hours ago, =362nd_FS=Hiromachi said:

Total usage is about the same and primary source is still that Scaleform eating about 74.88 % of resources. 

But isn‘t that what Adobe does on *any* system?

[=362nd_FS=Hiromachi]

Im no expert mate, it's possible. 

 

1 hour ago, No.615_Kai_Lae said:

I'll point out that VR users turn off the hud to get a large increase in framerate, which combined with the information above, would indicate that whatever they're using there isn't doing them a lot of performance favors. 

Oh yes, I also kill UI when flying online. Smooth gameplay is most important and every single FPS matters.