Fake frametime spikes due to ETW events flushing in PresentMon 2.2.0?

[AlexUnwinder]

Good job on optimizing ETW backend and implementing flushing there, it really reduced reporting lag drastically and made PresentMon's data more realtime!

However, I noticed that ETW flushing seem to cause periodic fake spikes to be detected on frametime graph on my system. The screenshot displays PresentMon 2.2.0 native overlay with raw frametime and RTSS overlay.
Pink (top right) graph is RTSS frame-start-to-frame-start frametime measured inside 3D application's hooked Present() call. There are no real frametime spikes on 3D app side. Violet (bottom right) frametime graph is reported by PresentMon service's API. Unrealistic spikes are displayed there and on PresentMon's own raw frametime overlay. The frequency of spikes on that graph seem to be directly related to the service's ETW flushing period. If I increase ETW flushing period with pmSetEtwFlushPeriod() inside my PresentMon service's client - the spikes become less frequent too, and they completely disappear if I disable flushing via setting period to 0. Which makes me believe that ETW flushing is direct reason of spikes. 

[planetchili]

Thank you for the report and the results of your experiments. We will prioritize reproducing this on our end and see what can potentially be done to fix the issue.

[planetchili]

Hi Alex, we've been looking into this issue recently, and we're hoping you can provide us with some additional information.

Comparing the manual flush (new) and automatic flush (old) modes of operation, we have not been able to reproduce the frametime spikes you describe except on specific hardware / game titles (specifically Witcher 3).

We were wondering what you have noticed with regards to reproducibility on different hardware configurations and titles? What hardware and titles have you seen the issue on? I notice Forza Horizon 5 in your screenshot; are there any other titles you know of that can reproduce consistently (or is it all titles)?

[AlexUnwinder]

Hi!
Sorry for delayed response, I had different engineering sample GPU installed in that affected rig and had some urgent software development tasks associated with it, so sadly I couldn't double check it one more time on the same hardware configuration to reply to your question.
But I was finally able to install the same hardware I used when reporting the problem to peek into it now. And I was rather surprized to see that the problem no longer exists there. Initially I thought that some 24H2 platform updates could fix it, but then I realized that I had this problem on PresentMon v2.2.0 service and now my client is already updated to support newer v2.3.0 service API and I have new service version installed. So I tried to downgrade the service to v2.2.0 and recompiled my client to use v2.2.0 compatible PresentMonAPI2.dll.
Once I did it - the problem immediately returned. And I double checked to confirm that the issue indeed disappear after upgrading service to v2.3.0.

So, some internal changes in 2.3.0 seem to fix it, thanks!

[markgalvan-intel]

Hello @AlexUnwinder thank you very much for investigating the issue. It is very much appreciated! Just for a quick clarification, did you happen to build the latest source and use that for testing? Or did you use the service packaged in with the 2.3.0 msi?

[AlexUnwinder]

Hi @markgalvan-intel

I used original service packaged in with 2.3.0 msi.

[markgalvan-intel]

Thanks @AlexUnwinder for checking. Appreciate your time!