I have noted that, when measuring patches with Pgenerator, regardless I use a dedicated P2P Ethernet connection or a networked one, if I experience a PC load situation, there are some behaviours that I think need to be investigate. Load can be usually generated activating apps, or more simply, running, during a profile execution, a LUT tools. I have verified what looks to me the most network usage case, i,e, rectangular patches with FS stabilisation.
What happens with CS listening to OK Pgenerator messages, is, that, following that overload, CS starts measuring the stabilisation patches.

I have also verified that with a previous CS sw version, only the patch being run close overload, is affected.


Here what I have seen on the IP interface for the different cases:

First let me summarise the way CS works with FS stabilisation and window patches:



In case of OK listening, I see the following:

In the case CS does not listen to Pgenerator OK's (previous releases) I see the following:


I.E., A bunch of patches 3 patches are sent to the Pgenerator. It appears there is a possible bug in the Pgenerator as the first patch (stabilisation) has been displayed, but the sequence is respected, with a probe delay of 2.2 sec. It appears as an issue with Pgenerator, whose development group has been informed.

It is quite difficult for me to point out the root cause as I don't know enough details about CS implementation.
I am under the impression that during heavy load, CS cannot send patches. Looking at the previous release, it appears they have been buffered up to the patch one and later sent.
In the same condition, it looks that the listening mechanism has broken the above mechanism. Off course, I cannot know if a different mechanism has been implemented and has some bugs.

Note: interesting that I could not see any case in which Pgenerator patch response has been delayed. All the time I see an ok with a maximum delay of 3 msec

Attached file: Wireshark Tracing (displayed)

Please test WITHOUT PGen, and see if any such issues then exist.

Steve

Here what I get with HDMI interface. Off course I don't have FS stabilisation. To get it I have had to reduce max processor performance at 25% (I have edited the power plan).

Sounds like this is an issue with your PC, based on a direct HDMI connection having issues - hence the request to test without PGen.

Basically nothing we can do about this, other than suggest you get a better PC.
(Even my Surface GO tablet has no such issues.)

Steve

Here my PC:

I don't think it is so bad.
As said, to have the issue, I have had to reduce max PC performances to 25%.
The sequence that creates the issue is activating LUT tools, during a measurement. Have you tried that with reduced PC performances?

If you 'load' ColourSpace directly, such as doing LUT processing, the profiling may indeed freeze momentarily, but it will (should) maintain sync.
If the issues is outside ColourSpace , within the PC system itself, we have no control over that.
Basically, there is northing we can do if the PC is woefully underpowered, especially if you artificially reduce the PC's performance.
But as a Surface Go works perfectly, the requirements of ColourSpace are rather minimal.

Steve

I have done some more testing: even artificially reducing PC performances, with HDMI, I don't have any issue if stabilisation is not flagged. The PC freezes, but the synchronism is maintained.
It's all about stabilisation.
What I see on the panel, when stabilisation is activated (and FS is the most critical case), is, after the freezing, a sequence of fast patches, i.e. without the delays I set on probe reading and stabilisation duration. When instead stabilisation is not flagged, after the freezing, the next patch is read without any issue.

I've spoken to the Dev. team, and actually they say as ColourSpace is not fully muti-threading, if you make excessive demands on the ColourSpace PC during profiling, it is 'possible' the patch and probe reading may momentarily lose sync.
This is to be expected, and has nothing to do with stabilisation.

Basically, don't over tax the PC when profiling.

Steve

Steve, that's happened (limited out of sync) when Pgenerator OK listening was not active, and it looks related to a Pgenerator bug. But since listening has been introduced, after the freezing, stabilisation FS patches are read instead of the requested patch (i.e. even if you go in manual measure). The only way I have found to recover is disconnect and reconnect Pgenerator (and that's positive).
And using CS for generating loading is only a trick I use, as I have seen CS sensitive to load generated,

Anyhow many thanks for taking care. I hope I have done you a complete picture of what I have seen.

PS: Obvious that all I have done has nothing to do on what I usually do during a characterisation: P2P connection, PC as much as possible isolated. During manual calibration I am more transgressive, as, I can understand immediately if something goes wrong.