Dserver To Utilize More Than One Core?

[[TWB]Pand]

Is there a configuration file or something we can edit to configure DSERVER to utilize one core?  

 

Watching CPU usage, it appears to be only utilizing 1 of our 12 cores that are available.

 

Thanks in advance!

Edited March 2, 2015 by [TWB]Pand

[SYN_Blackrat]

You can set the cores either in a shortcut or as we do using a batch file to start the dserver, we found using physical cores only proved the best result as using a hyperthreaded second core on the same physical core was less efficient.

 

Check here for how http://www.eightforums.com/tutorials/40339-cpu-affinity-shortcut-program-create-windows.html

 

[[TWB]Pand]

You can set the cores either in a shortcut or as we do using a batch file to start the dserver, we found using physical cores only proved the best result as using a hyperthreaded second core on the same physical core was less efficient.

 

Check here for how http://www.eightforums.com/tutorials/40339-cpu-affinity-shortcut-program-create-windows.html

 

Thanks for the info, will look to use a physical core so it doesn't randomly land on a hyperthreaded one.

 

Does anyone know if there are plans for dserver to utilize more than one core---seems like a server process like this would be perfect candidate for multithreading.

[[TWB]80hd]

It would be nice to get a dev response/explanation on this if possible...

 

It's a lot easier to get the AI to make runs in a formation of He-111s, not to mention to come back over and over again after getting savaged, than it is to convince players to do the same thing.

 

This does take some system resources, however, and if we could get the program to utilize modern computing resources available (or, I dunno, separate AI processing into its own process?) the overall enjoyment factor of complex missions that allow players to interact in a more seemingly living.breathing environment would be awesome.

 

MP servers live and die by the how many players are on at any given time... all you need are a few to kindle the flames... once that fire starts burning, 4 or so on each side, the snowball effect kicks in.  When you have clearly defined tasks for the player such as "Hey! Panzers are rolling on Grishin!" or "Bombers are inbound to Shkolniy!" it triggers a reaction... some players want to go attack/defend, some players want to go attack the attackers/defenders... emergent gameplay... it's catching on...  once you hit that critical mass and that same AI bomber strike comes back around again, but this time it draws a dozen or so players into that fray... well, that my friends is magic.

 

If you guys spend the time and resources to enhance the Dedicated Server to more fully utilize system resources (specifically, multiple CPU cores), you will in turn enhance our ability to allow those critical first few players to accomplish some things/enjoy themselves (case in point, busting AI tanks or buffs while waiting for others to say "Hey! There are people on that server! Let's go!) then I promise your player-base (and therefore BoM's player base, etc, etc) will expand accordingly.  The combination of fun/fear/excitement and adrenaline causes people to share those experiences, and you simply cannot market sincerely exuberant word of mouth into existence. 

 

Right now, we seem to be CPU bound and the ability to support complex missions and more AI is therefore hampered.

 

If there are other things that we can do to improve dserver performance, please let us know!

Edited March 5, 2015 by [TWB]80hd

[[TWB]Pand]

FYI ---- we disabled hyperthreading and performance has improved, thanks for the insight.

 

To any developers, where did this land?   Seems inefficient to have a crazy awesome server that we can only utilize 16% of the total processing power.

 

Do developers actually read this forum or does anyone know how to get in touch with them to find out?

[BlackDevil]

As the Dserver is written for one core, I would guess, that making it use more cores would need a total new dserver program. 

[[TWB]80hd]

As the Dserver is written for one core, I would guess, that making it use more cores would need a total new dserver program. 

 

Highly possible.  

 

Not sure what the feasibility of such a rewrite would be from a time/complexity standpoint, and your average player isn't even going to know what it means so we're not going to easily get a grass-roots campaign that'll attract the ear of the dev team... but if we can get more horsepower utilization, we can get more complex objectives, enhanced AI, and therefore a much more compelling gaming experience.

 

I don't personally  know a single person that wouldn't love flying the CURRENT SP campaign with friends... and while we can't facilitate that, our team is driving toward that goal within the limits of the current multi-player environment.  I can't speak from experience as to the specific limitations we're hitting, but as AbortedMan has been immersed in this for quite some time, and has produced consistently compelling MP scenarios, I take him at his word.

 

I may bag on AI in the SP campaign, but as soon as you put them into the MP environment, they become a thing of beauty.  They fly in formation.  They follow orders. They never complain.  Also, they don't mind getting savaged in He-111s over and over again.  They just keep coming back.

 

Players still fly bombers, but the constant AI strikes breathe life into the server... it took me awhile to really comprehend the impact, and once I did the opportunities and possibilities just kind of run rampant... until you get to the resource limitations.

 

I'm glad we're having a discussion about this.  I know the devs are busting their asses... if you predicted the sweeping, welcome changes and fixes in 1.010 back in October, I would have been skeptical. We can only see what is presented to us, and even then this community is just as Porridge-Is-Too: (HOT/COLD/UNDERMODELED) as every other sim community... can't please most of the people any of the time here hahahaha

 

I just truly believe, with a fervent passion, that enhancements made to the dserver can cause a massively beneficial ripple in the community.  We're getting more and more SP only pilots that are popping in and trying the dynamic MP campaign.  The experience (when you get past the moderate learning curve/work in progress states) is completely unique.

 

We (the entire community) could greatly benefit not just improved resource utilization but an ongoing dialogue with the person(s) responsible for dserver/mission editor development.  Even if it's simply a blog of some sort.

 

Delivering a living, breathing battlefield... where any player can join, select from a variety of objectives, and then execute that objective with tangible results/impact on the overall mission, which in turn we hope will be able to drive a dynamic, branching series of maps - all based upon who won the last map... that's never been achieved inside of an environment with anywhere near this level of freedom and fidelity.

 

What if, building upon this, instead of a mission outcome (and therefore progression) being determined by an eventual, simple binary win/loss state, we could dynamically drive the overarching war on a more granular scale... (Let me give an example)

 

Right now, current map, XIV Corps are assaulting Stalingrad. The main drive consists of Panzer columns assaulting along several pre-determined corridors.  The exact starting location, path, and specific corridor are randomized.  In support of this, flights of HE-111s bomb supply depots near XIV Corps objectives: Rynok, Schkolniy, Southern Stalingrad, Beketovka.  Karpovka starts out as neutral, and capturing it is a player-only objective, which gives the German team a forward base. The bases around Stalingrad can be captured, but not used as bases (mainly because of our inability to disable the GPS radar at any/all fields.  Russian recon-mission flights have been created to allow players to spot (and temporarily tag on the map) XIV Corps movements.

 

Now, within the above objectives (currently, all WIP and subject to change), players are free to interact as they wish.  The HE-111s will ask for escort (or players can fly a bomber along with them, or simply bomb the same objectives on their own) objective bases will call out enemy presence (air or ground), recon players are notified of successes, etc.  

 

However, as it stands right now, the win/loss conditions are limited to which side achieves the objective the fastest.  Germans win, next map will be loading a pre-built, static file where they are assaulting across the Volga.  Russians win, load a pre-built, static file where the Germans are pushed back and the counteroffensive begins.  If the Russians are 2 minutes away from destroying the last tank, but the Germans capture the last base, the outcome would be exactly the same as if the Russians had done nothing (and vice versa).

 

What if we could dynamically build the next map based upon a more complex, granular set of objectives and triggers?  What if, in the north, the Germans are decimated at Rynok, and they are never allowed to take Karpovka?  However, in the south they protect their tanks, suppress AT defenses, and annihilate Russian logistics resulting in the capture of Beketovka, Southern Stalingrad, and now threaten Raygorod?

 

Instead of being a static file, east vs west, the next map reflects all of the above?  Emergent situations... never before considered, strategically or tactically.  Do the Russian players consolidate their gains in the north and play defensively in the south?  Do the Germans ease the attack on Stalingrad to ensure Karpovka does not become a flanking nightmare?

 

Wow, sorry for the book haha!  Just really starting to see the potential in this sim.

 

[[TWB]otavio]

So, where is a dev response from the OP's question? It's been almost a month this thread's been up and it concerns pretty much everyone in the community. I just can't believe a team as "experienced" as they huh... say they are, would develop a game using an old dx9 engine that happens to have a dserver that supports only ONE core... that's just depressing.

Edited March 23, 2015 by [TWB]otavio

[Dakpilot]

Is it a prerequisite to be a Twb member, to be generally rude and demanding when posting in forums, lol

 

Cheers Dakpilot

[[TWB]otavio]

Is it a prerequisite to be a Twb member, to be generally rude and demanding when posting in forums, lol

 

Cheers Dakpilot

 

Honestly, i don't really know how business management works in Russia, but in the general capitalist world, CUSTOMERS get to be DEMANDING. I don't know why you're trying to be condescending here, but i don't appreciate your ironic tone, since my so called "demands" are beneficial to the whole community. Please refrain from trying to derail this thread.

Edited March 23, 2015 by [TWB]otavio

[Dakpilot]

Oh dear "buddy" proves my point exactly...

 

Cheers Dakpilot

[BlackDevil]

Realtime multithreading is not as trivial as you might think. There ares tasks, that can´t be multithreaded at all in any useful way. A simulator has different tasks, that can be easier seperated. But I don´t know, what the dserver has to do. So I am not able to judge, wether it can be usefully multithreaded. How can you guys judge this ? Do you have deeper knowledge of the dserver program ?

[[TWB]80hd]

Is it a prerequisite to be a Twb member, to be generally rude and demanding when posting in forums, lol

 

Cheers Dakpilot

 

Once again, if you have a problem with someone or what/how they post, please feel free to take it up with a moderator to address it.

 

I do appreciate you taking the time to take a squat on our entire squad, however.  That's some class right there.  Internet High Five!

 

 

Realtime multithreading is not as trivial as you might think. There ares tasks, that can´t be multithreaded at all in any useful way. A simulator has different tasks, that can be easier seperated. But I don´t know, what the dserver has to do. So I am not able to judge, wether it can be usefully multithreaded. How can you guys judge this ? Do you have deeper knowledge of the dserver program ?

 

"Us guys" aren't judging this.  In fact, here's a direct quote from what I wrote, above: 

 

"Not sure what the feasibility of such a rewrite would be from a time/complexity standpoint"  <-- I wrote this specifically to indicate that I was neither an expert, nor trying to armchair quarterback.

 

We're looking for a response from someone who can judge this. If the answer is "It cannot be done" or whatever, fine.  The issue is, we've hit a hard-cap on what we can do on our end to facilitate multiplayer operations with complex AI routines.  (Which, as an interesting aside, I've never seen Dakpilot even play online...)

 

So now, back to your statement of  "So I am not able to judge, wether it can be usefully multithreaded."

 

Why are you even contributing to this thread then?

[[TWB]Ewertsp]

Plz, check this out...
https://docs.google.com/presentation/d/1ArgaWyOFB2s0EqzmXaL0i9AVxlva5Z-iQr2ldA0Ea1w/edit#slide=id.p26
http://forums.bistudio.com/showthread.php?153010-The-urgent-debate-about-headless-client-in-A3-(and-HC-general-info)


It's about a workaround for the AI problem. This guys run servers with 40-80 people with more than a 1000 AI. Of course our limits here are much much tighter for unknown reasons but still, it's just unbelievable we can't have something that works at an acceptable level of performance even if it's not multithreaded.

[BlackDevil]

@ 80hd:  Sorry, if you felt offended.That was not my intention. 

 

PS: when I studied computer science 30 years ago, multithreading was a big subject. It needed another 20 years, until the first duo core processor came out for PC. The Prof did talk about new chips, where CPUs and memory are melted, but he said, the software to control it, will need some more years  

Edited March 23, 2015 by BlackDevil

[[TWB]Ewertsp]

well, we are waaaaaaaaaaaaaaaaaay past those "some more years"...

The problem here is not lack of know-how. It seems to me that there are other "more important" things to be done before we get a DECENT dserver and the last news we got this month just confirm it. 

[[TWB]80hd]

@ 80hd:  Sorry, if you felt offended.That was not my intention. 

 

PS: when I studied computer science 30 years ago, multithreading was a big subject. It needed another 20 years, until the first duo core processor came out for PC. The Prof did talk about new chips, where CPUs and memory are melted, but he said, the software to control it, will need some more years  

 

I didn't mean to come off as offended... and I bet your 30 year-old knowledge is probably more viable than what I know right now, on a technical level, because I'm autodidact network/security/sysadmin generalist, not a programmer.

 

My point was just that *I* am not trying to be rude, or come off like I know it all... what I am seeing is that we simply don't have any viable options to enhance performance and therefore add players, even by throwing more hardware at it.... part of the query is in the fact that we think (from all measurable sources, and believe me, Pand is measuring the expletive out of all system performance indicators, and I have pretty good network metrics going as well) that the problem is related to that single-core utilization issue.

 

Considering when RoF was developed, it makes sense... 

 

But either way, we really just want some more information... someone said we just need to run this out of a datacenter... and we're ultimately fine with that, but until we can get some hard information on why (i.e., if it's only going to use ONE core, is our only recourse to get the best damned core possible?)

 

If this is a dead-end, i.e., no plans to allow for larger servers and more complex server-side processing... then we'd like to know that as well, so we are creating a comprehensive roadmap to a land that is ultimately make-believe.

 

I mean, if I had to run a SEPARATE server, that locally connected to the actual dserver, and all it did was handle the AI stuff... I would totally do that... in other words, the AI would connect in just like another player, albeit on a low-latency connection?  In a heart beat.  Give us that ability, and I'll create a new rig for it.  Heck, I'd buy another damned copy of the game if I had to hahahaha

 

Anyway, TL;DR: Just looking for any information/plans or as I stated previously, even a "This is it for now, guys" so we know.  As it stands, we're going back to RoF forum posts from 2009 to try to make heads/tails out of the current dserver config options hahaha...

[CaK_Rumcajs]

If only there was a possibility to start an AI only process that would connect to a dserver as a client. Like the game is already able to spawn some AI planes a fly them. All is needed is to provide a way to run a client without the graphical UI. A client process could easily be a dserver in fact. Fancy a cluster of dservers. Then there may be as many client processes as it is feasible. Each client process would have its own AI planes to control and its own scripts. No need to rewrite the dserver for more threads. If the dserver only takes care of communication and all AI are handled by client processes the need to have it multithreaded fades away. On top of that the client processes could run on different machines. Complexity of mission design would probably be higher because the creator would have to split the mission between as many client processes as used.

[[TWB]Pand]

If only there was a possibility to start an AI only process that would connect to a dserver as a client. Like the game is already able to spawn some AI planes a fly them. All is needed is to provide a way to run a client without the graphical UI. A client process could easily be a dserver in fact. Fancy a cluster of dservers. Then there may be as many client processes as it is feasible. Each client process would have its own AI planes to control and its own scripts. No need to rewrite the dserver for more threads. If the dserver only takes care of communication and all AI are handled by client processes the need to have it multithreaded fades away. On top of that the client processes could run on different machines. Complexity of mission design would probably be higher because the creator would have to split the mission between as many client processes as used.

This is thinking outside the box... like it.