KDE System Monitor and the like have easy ways of monitoring how many bits per second are going in and out of your storage at a given time, is there anything similar for memory?
KDE System Monitor and the like have easy ways of monitoring how many bits per second are going in and out of your storage at a given time, is there anything similar for memory?
Non-ECC memory controllers don’t really track the flow of information in and out, the same way your CPU can’t track that as well until it hits a register. CPU and Memory use clock speed regulated by voltage to pass data back and forth with no gates between, so there isn’t a way to directly monitor and get feedback about the flow of information until it hits a destination that does report back or gatekeep for whatever it is (performance registers for example).
You can view the frequency of your running memory, which should give you an idea of the speed at which things will pass in/out, but that’s about all you’re going to get unless you find a utility that pulls a bunch of information from /proc and consolidates it all, but even then I believe you’d only be seeing an approximation and not live feedback about what’s passing through memory.
CPUs count cache data movements. Each L3 cache miss is a memory load.
could you please explain what you mean by no gates?
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?