Replies: 1 comment
|
I have now diagnosed the root cause of the intermittent 13ms CPU stalls: it's a problem with the fTPM on certain older AMD processors: https://www.amd.com/en/resources/support-articles/faqs/PA-410.html |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'm getting ~13ms CPU stalls (on all or most cores), mainly when launching applications. I assume that the findings here are related? (THANKYOU for the excellent work, btw!) If I do NOT launch apps, and simply do my normal real time audio work in a DAW, the problem happens very infrequently. If launching apps was the ONLY way to cause the glitch, I wouldn't have worried about it.
The best way to monitor the stalls is with the "In Depth" mode of LatencyMon, which appears to be only available in the paid version. I'm using the "Tight Loop High IRQ Level" mode. This spins in a tight loop, and nothing except System Management Interrupts (SMIs) can interrupt it. It reveals the problem readily. The standard mode of LatencyMon takes significantly longer before it will catch the problem.
I am actually monitoring the SMI count - sure enough, the count increases when the stall occurs, typically by either 5 or 10. Note that the SMI count increases for all cores, which I understand means it's a global/broadcast type of SMI. The way I'm monitoring the SMI count is using a hacked version of the Chipsec security suite. (I got A.I to do the hacking - it was very brute force, and pretty awful, but it finally got me something that works). The reason I had to hack it was because it currently doesn't support this platform.
I'm already running the latest version of the BIOS (317) which hasn't been updated for a long time.
I've been discussing this in a few places - the most in-depth discussion has occurred here:
https://learn.microsoft.com/en-au/answers/questions/5491950/asio-audio-glitches-on-asus-rog-flow-x16-need-help
Just a bit of general advice that might help others get to a good "baseline" with their DPC latency:
This is my first AMD machine, and I spent a VERY long time trying all the settings I was used to changing on my Intel based machines, to no avail. I finally stumbled on these two VERY IMPORTANT settings:
In "Processor Power Management", change these two settings to 100%:
Processor Idle Demote Threshold
Processor Idle Promote Threshold
These settings are important to prevent throttling. I have suggested to ASUS that the high performance profiles in Armoury Crate should automatically apply these settings - I haven't heard back.
Note that by default these settings won't be visible - an easy way to unhide them is to use this utility: https://forums.guru3d.com/threads/windows-power-plan-settings-explorer-utility.416058/
Besides these, follow all the usual advice regarding other settings to try. I notice for example that on my Dell XPS 17 9720 (Intel based), it was critical to disable "Allow this device to be turned off to save power" for the USB Root Hub controller, in Device Manager. I've done the same on this ASUS ROG as well, but I haven't gone back and turned the setting off to see how much difference it makes.
It's important to understand how Armoury Crate interacts with the Windows power management settings too. This is my understanding, but don't take it as gospel:
When the "Windows" power profile is selected in A.C, it allows the normal Windows power management settings to take control.
On the other hand, if any of the other profiles are selected (e.g Turbo) it will CREATE a NEW power profile, from scratch, using it's OWN settings. So, if you edit this profile in the Windows "Edit Power Plan" settings, your changes will be erased as soon as you use A.C to select a different profile. Even if you switch back to the original profile, it will re-initialise all the settings.
Fortunately, there is a way to have your edits persist, so that each time you select a profile using A.C, it will LOAD the profile that was last active, including your edits, rather than re-initializing from it's internal defaults:
powercfg /listand note the active profile, which will be the one that A.C just createdpowercfg /changename <GUID> "<new name>"where<GUID>is the long identification string for the active profile. E.gpowercfg /changename 6fecc5ae-f350-48a5-b669-b472cb895ccf "My Turbo"There's ANOTHER complexity, which I don't fully understand yet. Aside from A.C, in Windows 11 there are TWO places where the power settings can be controlled: the old place via the Control Panel (the only place in Windows 10), and now in Windows 11, also via Settings | System | Power and Battery | Power Mode. Pete Brown @microsoft says that the new Settings area takes precedence, but I haven't verified yet. Unfortunately that new Settings area doesn't expose all the nitty gritty stuff that's available via the Control Panel.
Anyway, aside from this strange 13ms stall, which is very infrequent when I use the system normally (but very FREQUENT if I launch apps), my DPC latency is actually superb!:

All reactions