AMD is smoother, and other debunkings of r/amd zingers

[Dan_D]

I'm using a 3900x on a X470 Gaming 7 WiFi. Anand review claimed DPC of 108 for that board, but that was a previous BIOS version. So I noticed you used LatencyMon and was going to test my own and came across this:


From https://resplendence.com/

About DPCs and ISRs

The Windows thread dispatcher (also known as scheduler) which is part of the kernel executes threads based on a priority scheme. Threads with higher priority will be given a longer execution time (also known as quantum or time slice) than threads with a lower priority. However the kernel also knows other types of units of execution known as interrupt service routines (ISRs). Devices connected to the system may interrupt on a connected CPU and cause their interrupt service routines to execute. An interrupt can occur on the same processor that an audio program is running on. Any thread that was running on the processor on which an interrupt occured will be temporarily halted regardless of its priority. The interrupt service routine (ISR) is executed and may schedule a DPC (Deferred Procedure Call) to offload an amount of work. The DPC will most likely run immediately on the same processor which means the audio application will halt until both the ISR and the DPC routines have finished execution. That is because ISRs and DPCs run at elevated IRQL which means they cannot become preempted by the thread dispatcher (scheduler). Therefore to guarantee responsiveness of the system, ISR and DPC routines should execute as fast as possible. Guidelines say that they should not spend more than 100 µs of execution time however this is often not reached due to hardware factors beyond the control of the driver developer. If execution time gets too high, the audio program may be unable to deliver audio buffers to the hardware in a timely manner.

This seems to suggest a target of 100 microseconds and a possible explanation for a perception of the smoothness claims. Unless I'm not reading this correctly, more cores means less chance of a interrupt halting your current task. Does that seem plausible?

Yes. That does seem plausible. These tasks execute incredibly quickly, so it might present as a slight lack of responsiveness. The fewer cores you have, the more likely this could happen where you would be able to see or feel it. As I said, DPC latency can vary quite a lot on systems even with the same motherboard. Installing the manufacturers Windows based utilities can sometimes drive up DPC latency as an example. One of the manufacturers, (I can't recall which), actually included a DPC tuning utility to try and reduce this. Or at least, one of them used to. It wasn't ASUS, that's all I can recall on that.

Here is a minute and 30 second test on the test system with the GIGABYTE Z490 Aorus Master running on it.

As you can see, the highest measured interrupt to process latency was 179.60. However, it usually hovers around 4-8.8 or so with occasional spikes just over 100. ISR was 2.38.35. Now, when I test this normally for reviews I let it run for about ten minutes.

 

[Deleted member 134608]

Yes. That does seem plausible. These tasks execute incredibly quickly, so it might present as a slight lack of responsiveness. The fewer cores you have, the more likely this could happen where you would be able to see or feel it. As I said, DPC latency can vary quite a lot on systems even with the same motherboard. Installing the manufacturers Windows based utilities can sometimes drive up DPC latency as an example. One of the manufacturers, (I can't recall which), actually included a DPC tuning utility to try and reduce this. Or at least, one of them used to. It wasn't ASUS, that's all I can recall on that.

Here is a minute and 30 second test on the test system with the GIGABYTE Z490 Aorus Master running on it.

View attachment 269872

As you can see, the highest measured interrupt to process latency was 179.60. However, it usually hovers around 4-8.8 or so with occasional spikes just over 100. ISR was 2.38.35. Now, when I test this normally for reviews I let it run for about ten minutes.

Here is my X470 Gaming 7 3900x

Wish our systems were side by side at the moment to see if we could perceive a difference. Mines idles much higher, usually in the 70 range. That 20.30 was an outlier. If the theory holds, yours should feel quicker. Be nice to have an average though.

Before someone mentions it: I realize this isn't scientific and placebo is a thing. But something must explain people's perception of responsiveness between systems.

 

[TheSlySyl]

I honestly have no idea what that utility is, but because I like giving more points of view. This is my 3900X on my X370, i ran the utility while browsing the internet (20+ tabs open) and all of my normal background tasks (Plex, minecraft server, discord, etc. Though both servers are currently idle).

The interrupt to process bounced between 6 and 20ish.

That highest reported DPC happened when I went and opened a new tab on my browser.

....that pagefault count seems weirdly high. I have 24GB of free ram at the moment. I feel like that's somehow related to Primocache.

 

[1_rick]

Mate, I don't have 7 eyes and 3 brains to process all that glorious multitasking. Can't even sip a soda pop while Microsoft edge is loading.

Multitasking is for AI.

Can you walk and chew gum at the same time?

 

[OutOfPhase]

Mate, I don't have 7 eyes and 3 brains to process all that glorious multitasking. Can't even sip a soda pop while Microsoft edge is loading.

Multitasking is for AI.

I know you're kidding (have some salsa, TacoMan) - but for others - look at your running process list sometime, then enjoy TacoFun.
(Spoiler: Multitasking isn't just for user code)

As for DPC timing -
In my experience moderate differences matter far less than many think, although it is super cool to spot real differences between systems which honestly should not exist to statistically evident levels (but do, as Dan_D has reported many times).

I personally haven't noticed any real issue until you get to "broken" numbers. Until then, the numbers are waaay smaller than all the other required latencies which you will notice (orders of multiple ms). We design hardware to be pretty good about knowing the current layout these days. We don't design stuff expecting the OS to do hard realtime for example - most hardware can do quick-turnaround stuff directly with no sw involvement, or at least very quickly in the ISR.
(Aside - hard realtime coding is super fun, if rare these days. If you're a sw person and haven't - do so someday in your career. It's like the 8-bit days all over in terms of fun thinking of how quick or predictable you can make code.)

If you see those lovely green bars start to zoom across the midpoint of screen, that's cause for alarm. There have absolutely been times when some vendors shipped REALLY BAD device drivers which purposefully dwelled in their ISR for significant amounts of time for their own throughput - and hosed everything else.

I haven't seen that in a while, but anyone who runs this the latency tool - run it for a while and keep an eye on that third bar. Just napkin-math - I'd suggest anything over 200uS on a modern system is probably not a great stat, and may indicate drivers with quality issues. That's code running at an incredibly high priv level which should be aggressively minimized. It's a sign the vendor maybe didn't design the stack well.

 

[travm]

Part of the problem is that benchmarking sites (every last one of them, including this one when it did reviews) do not measure spool-up delay or single-task transactional latency. Responsiveness often is perceived as "smoothness" but virtually all benchmarks focus on assessing sustained throughput of one thing or another. Furthermore, and not to trivialize it too much, but sustained throughput benchmarks are incredibly simple to run - a child could do it. Task and transaction timing analysis requires much more sophisticated tools and expertise, particularly on modern systems, that I believe is well outside the expertise of most tech site reviewers and youtubers who would not know what to do with an on-chip debugger or HW/SW profiling toolchain if it landed on their lap.

So, they tend not to capture or measure how quickly a processor spools up from an energy saving state, nor how quickly a chipset begins to service a NVMe I/O call, nor how efficiently an OS executes process instantiation on one hardware architecture versus another. And they certainly won't describe how efficiently an interrupt-based architecture is actually working on the Intel box vs. the AMD box. They don't need to because the true definition of "smoothness" - guaranteed timing - is actually not a requirement of PC, IT/server or gaming hardware at all. Be it Windows, Linux or BSD, none provide that utterly predictable timing stability that a RTOS does. Naturally, none of the applications running atop are measured on the basis of this predictability, and the benchmarking and measurement tools for the most part lack the necessary robustness as well.

I'd love to see a site tackle this topic more thoroughly if it's even possible with x86 hardware and operating systems. Until then I suppose we'll just have to live with people arguing about whose "experience" is bigger and more awesome.

This!
I have an AMD FX system still in use simply because it's snappy AF and all components are still just running at peak. I even built a ryzen system and don't use it because it doesn't feel faster. I can run benchmarks and it's slower by a significant margin, but turn the fps counter off and it feels just as fast.
It would be interesting if someone investigated why this happens.

 

[SmokeRngs]

One thing you have to consider is that monitor input lag and many other factors can contribute to one system feeling smoother than another.

Just like the rest of the components the monitor hooked up to the AMD system was also older and cheaper and all of them were CRTs hooked up via D-sub. I'm telling you that the AMD system had everything working against it and yet it still felt smoother and snappier than the better and faster Intel system. I tried to do side by side simultaneous tests and could never pinpoint anything different between them.

I never expected to see any difference and wasn't looking for any differences. It wasn't something I immediately noticed either but there was a feeling of difference when I swapped between the two systems. It wasn't on just one OS. I tried it with the same version of Windows with the same settings as well a couple of different Linux distros common between the two systems.

 

[Dan_D]

As for DPC timing -
In my experience moderate differences matter far less than many think, although it is super cool to spot real differences between systems which honestly should not exist to statistically evident levels (but do, as Dan_D has reported many times).

Agreed. I've seen systems score horribly regarding DPC latency and I never perceived any issues with them, nor did I run into issues with audio playback. I've watched Youtube on the test bench systems plenty of times or used them for various random tasks. I don't typically talk about that because its mixed usage with nothing scheduled or done consistently. It's a general user experience and for the most part, DPC has never impacted these systems negatively, even when they score bad.

Also, if I update drivers or Windows, the DPC numbers can shift dramatically. Often, retesting motherboards months later, I usually see a reduction in DPC latency over time. As a result, I don't put much stock in it. Though, I understand how it can present a problem if egregiously bad, or consistently bad. The tool reporting a super high spike is by itself alarming on the surface, but I think the average idle numbers are probably more useful. I can actually cause any of these things to spike if I want to. Open certain applications or let the system go into sleep mode and the number skyrockets.

 

[Deleted member 134608]

Agreed. I've seen systems score horribly regarding DPC latency and I never perceived any issues with them, nor did I run into issues with audio playback. I've watched Youtube on the test bench systems plenty of times or used them for various random tasks. I don't typically talk about that because its mixed usage with nothing scheduled or done consistently. It's a general user experience and for the most part, DPC has never impacted these systems negatively, even when they score bad.

Also, if I update drivers or Windows, the DPC numbers can shift dramatically. Often, retesting motherboards months later, I usually see a reduction in DPC latency over time. As a result, I don't put much stock in it. Though, I understand how it can present a problem if egregiously bad, or consistently bad. The tool reporting a super high spike is by itself alarming on the surface, but I think the average idle numbers are probably more useful. I can actually cause any of these things to spike if I want to. Open certain applications or let the system go into sleep mode and the number skyrockets.

Perhaps it isn't DPC and I was barking up the wrong tree. Interupts? I would like to know what stutters/hangs USB mice and keyboards specifically, (I miss honestly miss PS/2. That crap didn't happen on PS/2) but mainly to try to identify objectively where the perceieved differences of "smoothness" come from between different CPU/mobo/RAM combinations. Assuming there's a difference and I'm not crazy anyway lol

 

[sphinx99]

Perhaps it isn't DPC and I was barking up the wrong tree. Interupts? I would like to know what stutters/hangs USB mice and keyboards specifically, (I miss honestly miss PS/2. That crap didn't happen on PS/2) but mainly to try to identify objectively where the perceieved differences of "smoothness" come from between different CPU/mobo/RAM combinations. Assuming there's a difference and I'm not crazy anyway lol

I think there may be a blocking or latching mechanism that causes problems. A month ago, a wireless mouse I use began having issues. I would see stuttering and hanging that would begin perhaps 10s after starting to transfer data off a USB-C key connected to a port near the USB-A port the wireless transceiver was connected to. At first I thought this might be an interference effect, or maybe bus saturation for some odd reason. I switched to a wireless mouse and saw a similar issue, so I figured it’s not RF interference. But what concerned me was that I noticed some frame drops in windowed GPU games and explorer copy dialog pauses at the same time. All this on a 3960X on an Asus TRX40 platform that has no business suffering from I/O saturation effects. I personally believe there is something wonky about Windows 10 and USB HIDs but I can’t prove it or place my thumb on exactly what it is. Windows has always suffered from this, at least going back to Windows 98. (Prior to that all my experience is Ps/2 and I agree with you, no wonkiness there.)