I guess, but not simply. Probably easier to look it up, but I'll take a stab at it:

The CPU is informed how much memory is available to use, and the address spaces across the memory provisioned when it is assigned work, so it "decides" what it's supposed to work with by using its own logic gates.

The memory controller has a logic system of its own that decides how read/write work happens when it's assigned work.

Between the two there are no gates that measure how much traffic is flowing between them. This is just a bus that passes signals back and forth (caching gets more complex so I'll skip that).

So the signals passed back and forth between these two pieces of hardware doesn't have a place where it can measure exactly what is passed back and forth, it just exists to provide a pathway to allow the signals.

ECC memory passes parity bits with its payload, sort of like a TCP conversation, so it's controller knows what is passed to it and if the expected payload is intact. Because this exists on the memory controller, you can read those values and find out what is passing through it to measure what OP is sort of asking about (though it's so fast it wouldn't make sense without sanitizing the data into a normalized measure somehow).

(ok i see, you're using the term CPU colloquially to refer to the processor. i know you obviously know the difference & that's what you meant - i just mention the distinction for others who may not be aware.)

ultimately op may not require exact monitoring, since they compared it to standard system monitors etc, which are ofc approximate as well. so the tools as listed by Eager Eagle in this comment may be sufficient for the general use described by op?

eg. these, screenshots looks pretty close to what i imagined op meant

now onto your very cool idea of substantially improving the temporal resolution of measuring memory bandwidth...you've got me very interested with your idea 😀

my inital sense is counting completed L3/4 cache misses sourced from DRAM and similar events might be alot easier - though as you point out that will inevitably accumulate event counts within a given time interval rather than an individual event.

i understand the role of parity bits in ECC memory, but i didn't quite understand how & which ECC fields you would access, and how/where you would store those results with improved temporal resolution compared to event counts?

would love to hear what your setup would look like? 😀 which ECC-specific masks would you monitor? where/how would you store/process such high resolution results without impacting the measurement itself? details pls 😁

Eager Eagle

2025-05-23 22:50:34

It seems pcm-memory can do it on Intel CPUs and uProf for AMD.

Other than these I've mostly seen benchmarking and profiling tools (like perf) but I guess these are not what you're looking for.

GitHub - intel/pcm: Intel® Performance Counter Monitor (Intel® PCM)

Intel® Performance Counter Monitor (Intel® PCM). Contribute to intel/pcm development by creating an account on GitHub.

^GitHub