oos in c2c?
- Thread starter keldath
- Start date
Little to no OOS as long as the number of pipeline threads is reduced to 1 in the global defines XML (as that code has some non deterministic behavior in the order that units are created which unfortunately influences the unit IDs and therefore causes OOS).
I have been playing a direct IP game of C2C with a friend lately and entire evenings go by without a single OOS.
An approach to multithreading the city (and city AI) processing that Koshling added to C2C.
That significantly improves turn times on multi core processors (which are common nowadays) and for the most part is even safe for multiplayer but it does mess up the order of unit ids of newly created units so to make this work properly in multiplayer would need some more effort.
So the problems of simultaneous turns have been fixed mostly (if not completely)? Year or two ago it was impossible to play in MP due constant OoS errors.
Also maybe a detailed information could be made on how to make the MultiPlayer work for novices.
Also maybe a detailed information could be made on how to make the MultiPlayer work for novices.
TB has invested some serious effort in understanding them, tracking them down and fixing them.
Apart from that single global defines XML change I don't think there are any special things you have to do.
Well, there is one advice: If any OOS happens, both players need to restart the game and rehost/rejoin. Going to the main menu is not enough.
Apart from that single global defines XML change I don't think there are any special things you have to do.
Well, there is one advice: If any OOS happens, both players need to restart the game and rehost/rejoin. Going to the main menu is not enough.
Thunderbrd
C2C War Dog
In the C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\Caveman2Cosmos\Assets\XML\A_New_Dawn_GlobalDefines.xml you'll find NUM_CITY_PIPELINE_THREADS set to 4. All machines should turn this to 1.
There's still a few OOS errors lurking, some in pathing so the less automation and far sending of units the better (you can sometimes resolve these by deleting the unit that's just taken a position differing from what shows on another system or moving it back to the position the other system shows if you can in the same round.)
Also, never use the special preset build queues... those are a sure bet to cause OOS errors according to our playtesting.
On team play, wonder building can be a problem - although it may allow you to due to some caching issues, make sure before setting a World Wonder to build you check first that your team member isn't building it already. That'll spark an OOS as well.
But it should be pretty playable in Direct IP. Most of the OOS errors have been repaired. (Thanks for the props AIAndy!)
There's still a few OOS errors lurking, some in pathing so the less automation and far sending of units the better (you can sometimes resolve these by deleting the unit that's just taken a position differing from what shows on another system or moving it back to the position the other system shows if you can in the same round.)
Also, never use the special preset build queues... those are a sure bet to cause OOS errors according to our playtesting.
On team play, wonder building can be a problem - although it may allow you to due to some caching issues, make sure before setting a World Wonder to build you check first that your team member isn't building it already. That'll spark an OOS as well.
But it should be pretty playable in Direct IP. Most of the OOS errors have been repaired. (Thanks for the props AIAndy!)
Afforess
The White Wizard
Is there a reason C2C hasn't pulled in my change to auto-update the pipeline threads based on Cores present and whether the game is in MP? There is zero reason or excuse for making players fiddle with XML to make MP work.
Edit: Code included, below
Edit: Code included, below
Code:
CvPipeline* CvPlayer::createCityTurnPipeline()
{
SYSTEM_INFO sysinfo;
GetSystemInfo(&sysinfo);
DWORD numCPU = sysinfo.dwNumberOfProcessors;
int iMaxThreads = std::max(1, ((int)numCPU / 2));
int iThreads = (GC.getGameINLINE().isGameMultiPlayer() ? 1 : std::min(iMaxThreads, std::max(1, 1 + getNumCities() / 8)));
CvPipeline* pResult = new CvPipeline(iThreads);
...Thunderbrd
C2C War Dog
Well.... other projects were afoot. 
Thanks though. I'll try to get that in this weekend.
Thanks though. I'll try to get that in this weekend.The MP part of your change is OK for C2C but for the SP we need to change your code.
C2C is bloated like hell and needs more PipelineThreads compared with AND, everything below 4 is slower on my system.
AND is different because after reducing PipelineThreads from 4 to 2 it was faster.
Afforess
The White Wizard
I didn't bring up the SP change, I only was saying you should bring in the MP change.
As an aside though, setting the pipeline threads without respect to the users processor count is bad, and could make things slower, not faster. Extra threads that can not be handled in parallel are additional overhead.
Afforess
The White Wizard
Hyperthreading cores are counted by the system as individual cores. I have a quad core i7 with hyperthreading, my core count reported by the windows API call above is 8.
Was that the reason for numCPU / 2 ?
I have only a quad core i5 without hyperthreading that means only two cores are used by AND at the moment.
Afforess
The White Wizard
That and also consider that just because a system has 4 cores, does not mean all 4 cores are usable to every application. Consider that the OS is likely to use resources as well, plus any background applications. I think I might change it to numCPU -1 instead of / 2 but the idea still stands.
But my tests with C2C showed using all cores is still faster on my system.
I found a few other issues with the pipeline e.g. it is possible that AI players build the same wonder in multiple cities. But at least they can only finish it once.
Whether you want to map physical cores, or logical cores (will differ with hyper-threading), depends a lot on memory access patterns, since each physical core has it's own L2 cache, and switching between threads on a physical core, even if they are on different logical cores, can cause cache eviction if the working set union is greater than the cache size. This can lead to lower performance if you try to use all logical cores than if you just use all physical (i.e. - leave half the logical idle). Similarly allowing a thread to switch between physical cores when it is rescheduled can have nasty CPU cache implications, since it will have moved to a different L2 cache mid-way through what it was doing. For that reason some workloads behave better if you pin a thread to a particular core.
I do not know where the memory-access patterns of C2C put it in the spectrum, but if I had to guess, I would say the working set for city processing is actually reasonably small, so allowing full use of logical cores is probably best.
We did a lot of workload analysis to find the best settings in Sancho (and ended up finding different results worked best on different hardware, so made it configurable) - this is discussed a little here: Sancho multi-threading
I do not know where the memory-access patterns of C2C put it in the spectrum, but if I had to guess, I would say the working set for city processing is actually reasonably small, so allowing full use of logical cores is probably best.
We did a lot of workload analysis to find the best settings in Sancho (and ended up finding different results worked best on different hardware, so made it configurable) - this is discussed a little here: Sancho multi-threading
Iceciro
Special Ability: Decimate
Aside from the cores (which I set) what's the correct way to do things for a multiplayer, direct IP connection game when it comes to setting up BUG and the revDCM settings?
Afforess
The White Wizard
Unless C2C has changed it - the BUG and RevDCM settings sync themselves across all players. Options that should not be changed mid-game, or by non-host players are greyed out. Options that can be changed mid-game are available in MP. Changes to them in-game will sync across all machines.
That was written by me ages ago as part of RAND...2011ish probably.
Similar threads
