Intermittent Halting / Freezing / "Not Responding" Messages

[LordEntrails]

I will also add that for the future, it's better to develop your campaign material in a dedicated development campaign. And use several of them. One for each chapter/regional/plot line so that you can load and unload the module as needed. See link in my sig for some suggestions.

[AndyGJFantasyG]

I will have a look through he db.xml. See if there are any over the top large NPC entries. Issue is that our campaign is running @16+ and PCs/NPCs are chunky in the details...Not uncommon for there to be 20-30 effects on each character in play.

[JohnQPublic]

We were having similar issues, but they went away when the DM locked the map.

[Thunderhead]

Late to the party (as usual)... we're having some intermittent lag issues as well so I figured I'd add my $0.02. Hard to pinpoint what it is but it seems to be getting worse, which led me to look through the forums.

I'm the DM, running 5e. We're running DotMM with a ton of add-ons but I've got a beast of a machine and a 1Gb connection to the 'net so I reckon my end is equipped to handle a pretty severe load. It's been good but I'm noticing that the players are complaining that their end is locking up when I'm moving NPCs. Everything else seems to flow very smoothly and it's just the NPC movements that are causing grief.

My question for the group is, is FGU single-threaded or multi-threaded? More cores won't do me much good if it's just using a single core...

Machine specs for what it's worth:
AMD Ryzen Threadripper 2970X 32-Core
128GB RAM
2TB Samsung EVO Plus
Nvidia GeForce GTS 1080 Ti
Nvidia Quadro P4000 x2
Windows Pro x64

My apologies for hijacking.

[Weissrolf]

Except for the networking part mostly single-threaded. Especially the main Lua interpreter thread runs only on a single core handling everything from modules, rulesets and extensions to GUI interaction. Even worse, said Lua 5.1 interpreter does not even scale with higher IPC and cache sizes on new CPU (Ryzen 5900X here), only clock-rates matter.

Still hoping anyone at SW takes a serious look into LuaJIT (just in time compiler) as possible alternative to speed things up.

Everytime you see a "process not responding" it means that FGU's main thread is overloaded.

[Ecks]

I'm noticing that the players are complaining that their end is locking up when I'm moving NPCs. Everything else seems to flow very smoothly and it's just the NPC movements that are causing grief

I ran into something similar where the GM moving player tokens lagged for the players (https://www.fantasygrounds.com/forum...update-v4-1-4)). I believe there is a ticket logged to investigate it.

[Moon Wizard]

@Thunderhead,
The UI/scripting/data is single-threaded; because it has to be in order to preserve instruction order. Graphics rendering and networking is multi-threaded. As @Ecks mentioned, there was an issue reported recently that we are still investigating. Unfortunately, it came in the middle of a big refactor we are working on to rebuild the undo system for image/map editing, which has the system in pieces at the moment. I've boosted the priority, so that issue is the first to look at after undo work. If the players have generally slower/older machines, they can also try using /vsync 2 (or 3/4) to reduce the update frequency of the application in the mean time.

@Weissrolf,
I did look at LuaJIT as a drop-in replacement; and it was not faster in my basic timing tests (loading and main window opening), and actually threw errors because the Lua code in the rulesets/extensions was too "complex" for it according to the errors it threw. So, LuaJIT is not an option, because it is not faster in this scenario and apparently doesn't support the full Lua language. I would recommend again not continuing to try to pin everything on any sort of threading model or on the Lua engine; as the issues that you keep attributing them too have always been related to something else (LoS, token vision, etc.)

Regards,
JPG

[Weissrolf]

There are lots of slowdowns (unresponsiveness) not related to token/LoS/lighting, mostly loading and processing/displaying of data. Too bad that LuaJIT is not an option, because that was my last hope of ever getting better performance short of clocking the CPU over 6 GHz on liquid nitrogen. WoW suffers from the same issues when many Lua addons are loaded, so Lua hit a wall and that seems to be the end of it. But thanks for taking a look and now letting us know about it.

One field where FGU definitively can improve is load/process times of clients. Some months ago I posted numbers (load times in seconds) for both GM and clients and the client loading the same modules on the same computer took way longer and loaded modules in a later phase compared to the GM server.

Currently my FGU data files are on a NAS drive and either the file-access or the memory allocation is what currently slows down my campaign load times, even while FGU's CPU load is hardly ever maxed out (see image of single CPU core that FGU is allocated to). I will load data from a local drive again to get a better comparison of what might be happening and then report back.

[Weissrolf]

So I disabled the NAS share and thus had FGU load the local offline files. Furthermore I loaded the campaign twice to have all files reside in Windows file cache (aka RAM). Load time for the campaign files (ruleset, modules and extensions) was over 40 seconds.



As can be seen in the screenshot the CPU still is hardly maxed out at all, albeit being improved. So either FGU's memory allocation or file read algorithms seem to slow down its Lua processing (CPU). Since loading the same files via NAS share takes longer I suspect that file read access algorithms do at least play partly into this. This may be something to improve upon.

There are times where the loading dice stops moving and the UI becomes unresponsive, so it's all a mixed situation.

[Moon Wizard]

In terms of priority, loading performance is a lower priority than in-game performance and new features; as loading only needs to occur when the session is loading.

Also, you can improve your load times by reducing the number of assets in your images/tokens folder as well.

Regards,
JPG