3 seconds of lag ever 15 seconds

[Griogre]

Some motherboards share m2 channels with hard drive or other channels. I have one like that. If you have another non m2 drive you might try installing FG to it and seeing if it makes any difference.

[nephranka]

Some motherboards share m2 channels with hard drive or other channels. I have one like that. If you have another non m2 drive you might try installing FG to it and seeing if it makes any difference.

Ok. So I tried the on board SSD and I tried a SDcard. What I found was the card reader sees a much bigger spike in activity than the SSD drive, so clearly the SSD is faster. In both cases the GPU still drops and it is definitely tied to the saving action. It happens every autosave and even if I /save. The bigger the db file the longer the down time on the GPU.

No noticeable effect on a small test campaign (400 KB db file). I can see a little dip but not detectable to the eye in game. I have one campaign with a db of 10 MB and I get 2-10 secs drop on the GPU. One additional factor is any images being open and activity on the screen. More of that gets me closer to 10 secs.

It appears that HD speed is not the issue, nor location. It looks like something with the CPU and the GPU?

I guess I am back to that it is the specs of my machine. The video card specifically. (for the record it happens in windows and Linux. All video drivers are updated and one is open source (Linux))

[damned]

As far as I can tell the db.xml file is saved every 5 minutes. No idea if there are specific events that make it save in between?!

every 5 mins plus any manual events kicked off with /save

[Psycholiquid71]

Here's a kicker for you guys, we put it on a Flash SAN at work and an Enterprise Internal Solid State Drive and still the same issue, now we are talking IOPS of unimaginable speeds for this game and problem still exists. My whole engineering team just kind of laughed when we saw it do this on that kind of hardware.

[Weissrolf]

Windows cache disabled (for said drive) maybe? Reading your background in between the lines and given how cache is enabled by default, not likely, but you never know.

I only play bought adventure modules with db.xml files just 1 mb large (yet). So I cannot test this for you. My main guess would be that the saving maxes out the main-thread for whatever inefficient algorithm was used and thus suffers from a CPU bottleneck (like most of the time with FGU), not a IOPS or bandwidth one. If it isn't the CPU then the write mechanism really would be messed up, which unfortunately can happen with various software.

[Jiminimonka]

Windows cache disabled (for said drive) maybe? Reading your background in between the lines and given how cache is enabled by default, not likely, but you never know.

I only play bought adventure modules with db.xml files just 1 mb large (yet). So I cannot test this for you. My main guess would be that the saving maxes out the main-thread for whatever inefficient algorithm was used and thus suffers from a CPU bottleneck (like most of the time with FGU), not a IOPS or bandwidth one. If it isn't the CPU then the write mechanism really would be messed up, which unfortunately can happen with various software.

Get your opinions on coding out of other people's threads Weissrolf.

[Zarestia]

Here's a kicker for you guys, we put it on a Flash SAN at work and an Enterprise Internal Solid State Drive and still the same issue, now we are talking IOPS of unimaginable speeds for this game and problem still exists. My whole engineering team just kind of laughed when we saw it do this on that kind of hardware.

If you put software with an "error/bug" on the fastest supercomputer in the world, you can normally still see the problem. Furthermore, enterprise hardware is not always best for consumer prodcuts, a game probably performs better on a high-end "gaming" computer than on a 64-core server with local NVME drives, 512 GB RAM and a big quadro card...

In your latest shown test video in mid february you moved a token on a map with LoS and enabled modules, after many modules were enabled there were some "freezes" as you tried to move the token. When LoS was disabled, the rest was fine. This seems to indicate some kind of garbage colletion and/or FoW history problems (first was already written by Moon Wizard).

Just some short ideas:
- Does the freeze happen when you enable the modules before you move the token?
- Does the freeze happen when you don't have LoS enabled?
- Does the map size affect the freezing?
- Does the freeze happen if you don't have any tokens on the map?
- A really clean campaign (with no other campaings, modules or extensions in all the folders) was tried, right?

I personally haven't seen this issue in my campaigns.

@Weissrolf: If there would be a problem with the saving mechanism, OP would be able to recreate when typing "/save", which was so far not tested as I read in the thread. Also please share your reverse-engineering findings of the "inefficient" algorithm so the devs can fix.
Maybe @Sterno can share one of his/her big modules to let others/the devs investigate a "saving issue" (should in reality be a new thread.). Would be really cool if this thread stays focused to OP's issue

[Weissrolf]

A suggest to look at memory changes if garbage collection is to be the culprit.

PS: If the campaign could be shared others may indeed take a look at it.

[Weissrolf]

I took the large "Keep on the Borderland" campaign uploaded by another forum user. It features a 32 mb db.xml file, lots of LoS walls and I populated the map with extra tokens. The many tokens with the many walls make map operations perform very badly with the main thread's CPU core being maxed out, the wall removal workaround works against that. But there is no 3 seconds lag every 15 seconds and no high load when no map operations are touched.

Saving the campaign via /save takes about 3 seconds (on my rig) with the main thread's CPU core being maxed out, so that would fit somewhat. But auto-saving only happens every 5 minutes, not every 15 seconds.

So no luck reproducing the exact same issue here.

[Moon Wizard]

@Psycholiquid71,

Are you still having the same performance hiccups using the latest build released on Tuesday?
Did we ever get a sample campaign exhibiting the issue from you?

Thanks,
JPG