4 Replies Latest reply on Aug 24, 2017 2:38 AM by timurborn

    Complete Windows stalls when using even a single core of Reaper (DAW software).


      The CPU stress stalls that some people (including me) experience with stress tests like ITB AVX are even worse than I thought. Up to now I mostly only put time into learning about Ryzen's general operation, compatibility and overclocking, but now I checked DAWBench in Reaper running on a 1800X (Asus Crosshair 6 Hero).


      Turns out that even a single logical core being fully (over)utilized by Reaper leads to extreme system stalls close to making the PC unusable. That's 15 logical cores being unused and you still can watch graphic elements being built up from top to bottom and input (keyboard/mouse) being heavily broken. Even processes set to run at Realtime (31) priority get interrupted, all the while neither DPC or interrupt latencies can be measured to increase.


      I uninstalled HWinfo and did not run any other software that reads out temps and such. On top of that I did a Clear CMOS and replaced the NVidia GPU driver with the Microsoft standard one. I tried various CPU core affinities and power schemes, different memory frequency and timing settings, all to no avail. My 16 thread CPU is literally turned into a 1 thread CPU for this kind of workload.


      This also happens in Safe Mode and without using an actual audio driver (null device). It's worse than what I have seen from running ITB and ITB can even run smoothly without stalls under the same circumstances. To make sure that this is not an issue of Reaper (DAW software) I ran my test on an 8 year old 4-threads laptop and there it worked as expected, aka the software stalled when the core was overloaded while the rest of Windows remained usable.

        • Re: Complete Windows stalls when using even a single core of Reaper (DAW software).

          I have the exact same problem and the same motherboard, iam realy unhappy i went AMD for my new machine.

          • Re: Complete Windows stalls when using even a single core of Reaper (DAW software).

            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.

            1 of 1 people found this helpful