You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: