Citect 2018 R2 multi page graphics limit

G'day,

I think we've found a limit with the Citect client process.  We have a number of clients, 2 of which exhibit issues displaying faceplates and other slow response problems.  These issues only surfaced when we updated from 2018 update 13 to 2018 R2 update 10.  The two clients that are exhibiting this issue both have 4xHD monitors plus 2x4K monitors, running the SA environment and runtime only client processes.

We traced the issue back to the CPU core that runs the Citect32 process reaching 100% utilisation.  The processors are quad core (non hyperthreading) Xeon 2.9GHz units.  We are going to look at replacing them with Xeon quad core hyperthreading 4.5GHz equivalents.  We haven't observed any other hardware limitations

Some of the symptoms we seem to be experiencing are:

  • Faceplates slow to load
  • Faceplates don't load
  • Alarms stop displaying (though this may be a different issue as it appears to occur on lightly loaded clients)
  • Alarm filtering resets to unfiltered periodically

For the end users - has anyone else come across these issues?  Has upgrading processor to one with a higher clock speed helped?

For the developers - is there anything in the works to split the Citect client process into a single process per monitor such that we can utilise the additional cores that modern PCs come with?  Is there a supported method to enable Windows to split the Client process across multiple cores?

Cheers, Owen

Parents
  • Hi, We had similar problems on a recent project though we implemented 4x4k SA workspace in V2016 because of release and risk constraints. In the end we performed several rounds of cicode profiling ("Profile 1" then "Page table profile" in the kernel) and optimising on the client and also set the [page]scantime, [page]anmdelay and [animator]flashtime all to 1000. Word from the Devs was that these params all need to be set together in order to impact the animation CPU usage (the lowest essentially wins). We were able to function like this YMMV. Good luck!
Reply
  • Hi, We had similar problems on a recent project though we implemented 4x4k SA workspace in V2016 because of release and risk constraints. In the end we performed several rounds of cicode profiling ("Profile 1" then "Page table profile" in the kernel) and optimising on the client and also set the [page]scantime, [page]anmdelay and [animator]flashtime all to 1000. Word from the Devs was that these params all need to be set together in order to impact the animation CPU usage (the lowest essentially wins). We were able to function like this YMMV. Good luck!
Children
No Data