Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.os.windows-11 > #18480

Re: memory usage vs fan usage

Show all headers | View raw

On Thu, 4/17/2025 5:17 PM, Andy Burns wrote:
> Carlos E.R. wrote:
> 
>> Memory heat depends, AFAIK, solely on memory activity. Reading or writing cells.
> 
> yes that's what I thought, probably with writes being hungrier than reads,but what about refresh, isn't that a constant background read/write s it doesn't forget?
> 
>> Unless there is a feature that allows free memory to be powered down or not refreshed. I have not heard of it. 
> 
> No not heard of it, hypervisors do some clever tricks t spot multiple VMs with identical pages, anfd point them all to one copy, but thats to free up extra memory for those that need it, not to switch any off
> 
>> Considering that a laptop can sleep, while it keeps all ram holding its data on battery for some days, I don't think that unused ram uses any amount of significant power.
> 
> 

When you get a memory power spec, the "representative power" is via
the "Industry Standard Cycle Mix".

Each cycle type has a power consumption.

A "No Operation" on the command bus, still burns power, but that is
"toggle power". The clock signal has changed state twice, and internal
logic that changes state, dissipates a tiny amount of heat.

The next cycle type up from that, is "Refresh". Refresh uses a little
more power. AutoRefresh (computer sleeping), uses 1 watt over 16 chips.
the command bus during AutoRefresh is silent (the memory controller is
switched off during sleep). All of the power there, is counters inside
the module, incrementing Row and Column address, as memory locations
are visited every 64 milliseconds and recharged.

"Read" and "Write" cycle types, occur in bursts. The CPU likes to do
cache line sized accesses (64 bytes at a time). Two DIMMs in dual
channel are 16 bytes wide. A burst-of-4 is done in that case, to
complete a cache line fill or a cache line removal. If you run
a single DIMM, the memory controller uses a burst-of-8 for the cache
line activity. These cycles are very expensive, compared to the previous
cycles. But if you only do 4 of those, per 100 cycle interval,
or 8 of those per 100 cycle interval, the RAM only gets pleasantly warm.

The memory supports worse modes than that, but if you as an engineer
decide to use them, if you hammer the RAM, then be prepared to add
cooling as appropriate. I think you can do something like 256 cycles
back-to-back as a burst, which might be used for an expensive RAM drive
with a PCIe interface.

There are a couple transaction types. A page can be closed or a page
can be open. The cycle time for an open page, is fewer cycles than
if the page has to be opened. Maybe one is 60 cycles, the other 100 cycles.
In usage patterns like Memtest, you would expect a few of the tests
to be using a lot of open pages. The RAM runs a bit warmer, if you
check a Memtest run and use your finger to check temps.

In a desktop, if you use "fat" modules with heat spreaders, counter
intuitively, that's bad. There is no air channel between DIMMs when
you do that. The two modules in the middle of the four module cluster,
can be warmer than the outside ones.

But unlike GDDR7 on a video card, running at 95C or 100C, or L3 cache
in an AMD processor sandwiched underneath a CCX, the DRAM modules we
use for the most part, have a cool and uneventful life.

It is when you over-volt modules, they get hot. Some people might
be running Winbond modules, with a nominal 2.5V operating voltage,
ad 3.6V. Such kits came with blowers to fit over the RAM modules.
Part of that heat exists, because the DRAM chips have voltage
regulators inside (generating internal voltages for certain parts
of the design), and linear regulators are not efficient by any means,
and when really excessive amounts of voltage are used, those modules
are going to get *hot*. Burn yourself hot.

Ever since Intel started listing relative limited overvolt ranges,
the practice of incinerating RAM has kinda stopped. A 1.5V RAM
standard, had 1.65V as the "Absolute Max". After a few failures,
some of the users started recognizing those datasheet items as important.
And that amount of overvolt, is unlikely to even need those fancy
dragon-shaped metal covers with sharp points for your fingers.
Probably all the modules could be sold with just the memory chips
and their surface area for cooling. And the thinner modules would
have a tiny air channel between them.

On multiple occasions, Intel advertised the possibility of RAM overheat
and talked of "cycle rate limiters", as a means to avoid sticky situations.
The industry response, was you could hear crickets. Absolutely nobody
panicked. Today, you might find that memory modules do have
temperature sensors (DDR5 maybe), but there might not be any consumer
software to read that out.

The CPU power, there is a TDP figure. You can use half the TDP,
by running one core railed. The reason for that, is the racetrack
ring with the core voltage on it, is raised for all cores, and the
idle cores still leak a bit of power. When additional cores engage,
the incremental power penalty isn't all that great.

But you can see from that observation, that the memory compressor
running on one core, that's not going to be good for battery life.
Good battery life, comes from bursty CPU activity, where the CPU
voltage drops in microseconds, back to the power saving voltage,
and your battery lasts for hours and hours.

And now I have to go over to the machine on the bench, and figure
out what the hell it is doing in the background :-/ I have the USB
stick with the tools on it, to load up the machine and start looking.
This is a Windows 10, with barely any software installed on it. There is
no WSL2 on it, and I don't think there is a VBox or a VMWare on it.

   Paul

Back to alt.comp.os.windows-11 | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-17 15:16 +0100
  Re: memory usage vs fan usage Paul <nospam@needed.invalid> - 2025-04-17 12:09 -0400
    Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-17 19:57 +0100
      Re: memory usage vs fan usage Paul <nospam@needed.invalid> - 2025-04-18 03:15 -0400
  Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-17 11:59 -0500
    Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-17 19:40 +0100
      Re: memory usage vs fan usage Frank Slootweg <this@ddress.is.invalid> - 2025-04-19 12:04 +0000
        Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-19 13:36 +0100
          Re: memory usage vs fan usage Paul <nospam@needed.invalid> - 2025-04-19 09:25 -0400
          Re: memory usage vs fan usage Frank Slootweg <this@ddress.is.invalid> - 2025-04-19 14:54 +0000
            Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-19 16:16 +0100
            Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-24 08:17 +0100
              Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-24 05:14 -0500
                Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-24 11:30 +0100
                Re: memory usage vs fan usage Paul <nospam@needed.invalid> - 2025-04-24 09:08 -0400
                Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-24 20:59 -0500
                Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-25 07:40 +0100
                Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-25 19:13 +0100
                Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-25 22:29 -0500
                Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-26 10:31 +0100
                Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-26 15:05 -0500
        Re: memory usage vs fan usage "Carlos E.R." <robin_listas@es.invalid> - 2025-04-19 14:36 +0200
          Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-19 13:56 +0100
          Re: memory usage vs fan usage Paul <nospam@needed.invalid> - 2025-04-19 09:28 -0400
  Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-17 15:07 -0500
    Re: memory usage vs fan usage "Carlos E.R." <robin_listas@es.invalid> - 2025-04-17 22:25 +0200
      Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-17 19:30 -0500
        Re: memory usage vs fan usage "Carlos E.R." <robin_listas@es.invalid> - 2025-04-18 14:09 +0200
          Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-18 11:13 -0500
            Re: memory usage vs fan usage "Carlos E.R." <robin_listas@es.invalid> - 2025-04-18 21:33 +0200
    Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-17 22:12 +0100
      Re: memory usage vs fan usage VanguardLH <V@nguard.LH> - 2025-04-17 20:07 -0500
      Re: memory usage vs fan usage Paul <nospam@needed.invalid> - 2025-04-18 05:24 -0400
        Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-18 12:08 +0100
          Re: memory usage vs fan usage Frank Slootweg <this@ddress.is.invalid> - 2025-04-18 18:09 +0000
            Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-18 19:36 +0100
  Re: memory usage vs fan usage "Carlos E.R." <robin_listas@es.invalid> - 2025-04-17 22:29 +0200
    Re: memory usage vs fan usage Andy Burns <usenet@andyburns.uk> - 2025-04-17 22:17 +0100
      Re: memory usage vs fan usage "Carlos E.R." <robin_listas@es.invalid> - 2025-04-18 02:19 +0200
      Re: memory usage vs fan usage Paul <nospam@needed.invalid> - 2025-04-18 05:52 -0400

csiph-web