I have the exact same problem and the same motherboard, iam realy unhappy i went AMD for my new machine.
I found at least on report of this in Asrock and MSI X370 motherboard threads, so even though it may be an Agesa thing, it does not seem to be limited to the specific Asus board.
1 of 1 people found this helpful
Well, I took a much closer look at those "freezes" again, which I called stalls, but they are the same thing for what we talk about. Both the GUI/graphic output and keyboard/mouse input are suspended anywhere between a short blip and several seconds (I measured up to around 4). Additionally some but not all processing seems to stop during that time, which I reported wrongly before when I claimed that the whole system stops.
First of all, both the suspension of graphic output and the partly ongoing of background processing can be measured! It's important to note that time-counters seem to roll on regardless of any stalls, which in turn allows software to keep measuring average CPU load, CPU cycles (+delta) and context switches (+delta) and frames per second. The CPU cycles Delta is especially interesting, because it tells us whether a program interrupts processing during a stall or not.
What Delta means is that when you measure over the span of a second then the Delta is the amount of cycles that happened during that second. If a program interrupted its processing during a stall then the CPU cycles Delta decreases on the very next tick right after a stall. If a program kept processing uninterrupted then the Delta increases on the very next tick right after the stall.
Programs that interrupt their processing include: WinRar, 7-Zip, Foobar2000, Firefox (Youtube HTML video output), Furmark
Programs that do [u]not[/u] interrupt their processing include: Ableton Live, MediaPlayerClassic, HWinfo
Both WinRar's and 7-Zip's benchmark throughput drop considerably during stalls. WinRar seems to especially dislike my Reaper based workload, or rather the other way around, as WinRar interrupts Reaper even more.
Audio and Video are two very special cases that justify some extra explanation.
Audio drivers do not stall, regardless of the audio buffer size being used. I ran a RME Babyface USB ASIO drivers (isochronous USB transfer) at less than 2 ms buffer size without interruption whatsoever while my mouse kept stalling over the very same USB port + hub. If the application keeps processing data (Ableton Live) you can run input audio from the USB audio interface to the application and then back to the audio interface completely uninterrupted while the rest of your system is nearly unusable.
If the application does interrupt its processing during a stall then the size of the application's own audio buffer decides over whether your audio stream gets interrupted or not. For example, if you set Foobar's own audio buffer to a size larger than the stalls (bigger than 4 seconds is good) then you get no audio interruptions. And if stalls are shorter than what Firefox buffers for Youtube playback then you get no interruption. This is because with larger buffers the audio data has already been processed before the stall happens and it seems that the program parts that just shovel the data to the audio driver do not get interrupted during a stall.
Video playback and graphic output always get interrupted, which in turn results in GPU load and Video Engine load dropping considerably, including the GPU frequency and temperature dropping. Since timers keep rolling the video/graphic output will jump forward to match the new time-frame (a 5 second stall means that the video jumps 5 seconds forward). For Youtube videos in Firefox this is a true jump, for videos in MediaPlayerClassic this is a fast forward that shortly increases the frame-rate (while maintaining the refresh-rate, because disabling VSync doesn't seem to work properly). Both Firefox Youtube and Furmark also see their average CPU load drop because of the stalls that interrupt their processing, even though they do maintain their time-lines in form of a straight jump.
Interestingly HWInfo's graph display works similarly to how Firefox Youtube playback and Furmark works. The graph will do a full jump to the new time-frame instantly after a stall instead of drawing the in-between measurements. If you mouse-over the graph you can see several seconds being absent corresponding to the stall time.
Its realy bad. Iam not able to even stress test my cpu at stock settings, It i try IBT i get up a a full minute 100% , RealBench isnt so bad with only 30 sec stalls and OCCT being the smaller stalls at about 20sec.
I can run P95 fine any setting no problems, ive preaty much gave up on it tbh. I feel like i bought a defective part or something :/