Slowdowns on extremely high-end systems on advanced missions (Baltic Breakout)

[jpinard]

I'm starting to wonder if some of the slowdown issues we're having are due to too much RAM or SLI? Currently it makes no sense that a system as powerful as mine could have an issue in the game. Qith the slowdown I"m expewreiencing, it would mean people with an non-OC'ed computer would have the game run at 1 fps in Baltic Breakout. For myself, everything starts smoothly, and when the Russians start to get "actively" involved in this scenario the game starts to stutter so bad it became intolerable. My thought is sometimes with high-end systems and too much RAM a game actually gets worse - this has happened a few times over the years.
So does everyone experience this?

My specs:

* Intel 2700k OC'ed to 5.1 GHz (hyperthreading off)
* Watercooling via Corsair H100.
* 16 Gigs (4 sticks of 4 Gig) Corsair Doninator RAM @ 1866 MHz
* Windows 7 - 64-bit on Corsair SSD Hard Drive.
* Game installed on Western Digital Caviar Black 1.5 TB via Steam.
* 2 Gigabyte Nvidia GTX 680's in SLI.
* Creative Labs X-Fi Fatality Pro

DXDIAG: DxDiag1.txt

Steamlog (I snipped out preceding days from the steamlog as it had too much IP information in it): steam.log.txt

Outputlog: output_log.txt

Output play logs from My Documents (from play sessions affected): TTG_NAVALWAR_LOG2012-04-22.txt and TTG_NAVALWAR_LOG2012-04-24.txt

[Registered55]

you clearly don't understand how game engines work, game engines do benefit from powerful resources, but at some point you reach a point of "Diminishing Returns", in other words it's no longer the question of available resources, but problems with the code (there are bottlenecks in the game code , which then effects the rest of the code) unfortunately that usually means the game still needs some optimizing done.

most games are 32bit only, so the game can use at MAX 3gb, so your ram theory doesn't quite pan out,
SLI can cause issue, usually it's best to have that off, unless you need it on, this type of games should definitely not need SLI,


NOTE: only concern however is you said 1fps......... at that speed is the game would be unplayable, the game would practically be paused.... have you confirmed that it is 1fps as you have claimed.... using something like Fraps.

it's still early days,. many more patches will be coming so these things will be dealt with soon enough.

[Radioshow]

I have had slowdowns on my modded Keflavic scenario with more aircraft and ships added. Most of the slowdowns are due to large amounts of missiles in the air and the accompanying radars. I have not done Baltic breakout yet, but my scenario has ALOT of units and stuff flying around, 50 or more at a time with missiles everywhere once in a while. That is the only time I really get slowdowns and then it is often a quick pause/warping as it stutters a bit with the calculations.

Best bet is to not have all radars on. Use your AWACS and larger search radars for detections and use the datalink for targeting. Often just activate the radars on a few aircraft and keep other off for stealth. The more active sensors you have the more calculations and they build up exponentialy apparently.

My system is a AMD X3 3 core, 4gb, 9500gt 512mb with win7 64bit, not a hefty machine but works fine on medium/high at 1920x1080. I often lower the resolution a little but seems to run fine either way.

Atleast the devs are talking to us. Most game's they ignore us and say it all in our heads ie. Modern Lagfare 3

[jpinard]

you clearly don't understand how game engines work

I've worked with game engines in the past... so yes, I DO understand them. I'm just trying to troubleshoot here and knock out any oddball items such as the game crashing from too much RAM. There have been This has happened in the past and it was due to game code not expecting to see numbers over 2 or 4 Gigs. For example, one older program I used went nuts as it based its loading assets on % of RAM available. Expecting to hit 90% at 4 Gig, when it didn't, it started loading more than the developers intended which caused problems in the application. The only way we helped them track ti down was looking at system specs and the same thing kept popping up. Everyone with more than 4 Gigs of RAM had the same issue.

I'm sure it's not the case here, but one never knows... and it can't hurt to check.

[JanH]

We're working on improving how the missile sensors operate, which should make the game run much more effectively.

[Rear Commander]

I have the same problem and have definitely noticed that once lots of missiles start to fly the game performance just melts. Ragnorak Armada, with 4 naval groups, 4 airbases, and tons of bombers, is impossible to finish even on easy because once anti ship missiles or bombs get launched at my ships I can't control the counter measures. But if I manage to destory all the bombers before they launch enmasse the game runs a little more smoothly than it would have otherwise.
JPinard, have you noticed a correlation between number of units in play and performance?
I have your problem but I don't have a high end computer. Since we have the same issue but I have 6 gigs and one card I'll bet your hypothesis is wrong, but maybe not. I also use 64 Windows 7, and everyone I've seen on here who has this problem has either not mentioned their OS or has listed 64 bit W7.

[Ours]

I have a decent but old gaming PC and it's very obvious that when lots of missiles are in the air things bog down. It's great for the suspense because I can't control my units at the most critical moment .

I get everything from 30 second freezes to warping planes.

[jpinard]

I have the same problem and have definitely noticed that once lots of missiles start to fly the game performance just melts. Ragnorak Armada, with 4 naval groups, 4 airbases, and tons of bombers, is impossible to finish even on easy because once anti ship missiles or bombs get launched at my ships I can't control the counter measures. But if I manage to destory all the bombers before they launch enmasse the game runs a little more smoothly than it would have otherwise.
JPinard, have you noticed a correlation between number of units in play and performance?

Yep. In Baltic Breakout it's when the Tupolov's come en masse and (maybe) launch a bajillion missiles. It had been hard to say if it was "missiles only" or "# of active air units" as it takes me so long to get to that point I couldn't pare it down. I didn't realize the scearios were simple xml so maybe I'll create a test scenario to check this out.

[Radioshow]

With almost all of my radars off, except for awacs and land based, I still have the slowdowns. It really does seem to be more weapons related. Torpedoes or missiles same effect. Add to that they often fire off their whole lot in one salvo. And you cant really limit your number of missiles too much as you need lots of missiles at once . I often have multiple flights from different approach angles. With all the harpoon/JSM and S300's flying at them, it slows to a crawl.

[JanH]

Missiles cause excessive slowdowns when there are, quite literally, hundreds of them. This is due to the sensors on the missiles; the work load increases geometrically with the number of sensors trying to detect units. We should have improved this dramatically for the next patch. We also have some good ideas for improving it even further for later updates.

[Radioshow]

Good news JanH. Thanks for keeping us informed!

[jpinard]

Post patch the game doesn't lock-up, but it still slows way down to a crawl at times. I still think there's an issue with sending the sound and message about each event as that is when it is the worst and will pause the longest. Whatever generates the script to export the message and the sound (when a lot is going on) just crushes the program. I'd be interested to try a build where there is no "blunk" sound command being sent as I doubt just deleting (or blanking) the reference sound file would make a difference.

[albone20]

Missiles cause excessive slowdowns when there are, quite literally, hundreds of them. This is due to the sensors on the missiles; the work load increases geometrically with the number of sensors trying to detect units. We should have improved this dramatically for the next patch. We also have some good ideas for improving it even further for later updates.

I have experienced the big freeze most often when i click on a large pack of incoming enemy missiles.
its starting to look like the Devs are closing in on the problem. Thanks janH for all your efforts

win7 64bit
E8500 clocked at 3.8G
4G Ram
GTX570

[jpinard]

Wow, I just checked out my log file from my last play session and yikes! 806k log file as there was a lot not quite going right. 5,000 repeated lines of this probably didn't help performance:

Error - 11:51:16 PM.84 ** TerrainReader->GetHeightM failed. Invalid Seek Offset
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.Seek (Int64 offset, SeekOrigin origin) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.set_Position (Int64 value) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.ReadHeight (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.GetHeightM (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0 
Error - 11:51:16 PM.85 ** TerrainReader->GetHeightM failed. Invalid Seek Offset
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.Seek (Int64 offset, SeekOrigin origin) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.set_Position (Int64 value) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.ReadHeight (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.GetHeightM (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0 
Error - 11:51:16 PM.86 ** TerrainReader->GetHeightM failed. Invalid Seek Offset
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.Seek (Int64 offset, SeekOrigin origin) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.set_Position (Int64 value) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.ReadHeight (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.GetHeightM (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0 
Error - 11:51:16 PM.87 ** TerrainReader->GetHeightM failed. Invalid Seek Offset
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.Seek (Int64 offset, SeekOrigin origin) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.MemoryMapping.MapViewStream.set_Position (Int64 value) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.ReadHeight (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0 
  at TTG.NavalWar.NWData.Util.TerrainReader.GetHeightM (TTG.NavalWar.NWData.OrderSystem.Coordinate coordinate) [0x00000] in <filename unknown>:0

latest log files.zip

[JanH]

A failure in MemoryMapping.MapViewStream.Seek strongly indicates that the system was unable to allocate the necessary memory for the terrain data.

[jpinard]

A failure in MemoryMapping.MapViewStream.Seek strongly indicates that the system was unable to allocate the necessary memory for the terrain data.

I have 16 Gig of system RAM, lots of hard drive space, and 4 Gig of video RAM. Are you suggesting my system RAM is unstable? I can run Prime95 for hours without an issue so I don't think it is but I'll do some more tests if you really think it's on my end.

[JanH]

I don't think there is anything wrong with your hardware; it would appear that some other processes have eaten up your RAM, or that something else has gone wrong so the system doesn't free up allocated memory. While very interesting, I have to say this is the only occurrence of this error I have seen in any log posted here. So, yeah, something weird is going on.

[sertore]

Missiles cause excessive slowdowns when there are, quite literally, hundreds of them. This is due to the sensors on the missiles; the work load increases geometrically with the number of sensors trying to detect units. We should have improved this dramatically for the next patch. We also have some good ideas for improving it even further for later updates.

Hello Jan,
just to give you some hints, one of major complain of simulation experts here is the lacking of FireSalvo (maximun number of missiles or any other weapon fired at the same time from a single unit) and ReloadTime (time necessary to reload the fired or changed weapons on a single unit): introducing these restrictions, maybe in database variables, you should be able to improve the simulation quality and the game performances, reducing the number of active weapons on air in the same time.

Hope this help.

[JanH]

We indeed have both in the game. What we're missing is 1) having these restrictions per weapon/unit as opposed to pet weapon class; 2) having weapons share resources (like some torpedo tubes used for multiple weapons).

Several small launches as opposed to one large salvo makes the game run slower, not faster.

[sertore]

...

Several small launches as opposed to one large salvo makes the game run slower, not faster.

Not too good to hear that: I was thinking the opposite due to a lower number of weapons on air in the same time, but seems that I was wrong.