News and Reviews > Official Announcements

November Discounts and Giveaway

<< < (3/5) > >>

Grorgy:
Darwin, there is an option just to do the indexing anyway, or at set times of the day but it is a fairly disk intensive process as you would know and given my usage, set times are next to useless.  letting it do it when idle is by far the best option for me.  I dont actually have a need for cpuidle, my computers are both running well, no apparent over heating or other such nasties.  I'd rather have a search function, and i gotta say I'm pretty happy with copernic, less resource intensive than the others Ive tried, and with archivarius and locate for the more specialised searches it fits in well.

Darwin:
Heh, heh - great minds think alike! I dropped in here to say that I'd uninstalled CPUIdle for the same reasons (well, barring the indexing thing - Archivarius didn't have a problem with it)...

Ralf Maximus:
I got curious about CPUIdle and some of the other software CPU coolers, and this is what I learned about how they work.

Essentially they issue a processor HLT command, which halts the CPU until a non-maskable interrupt occurs or it is manually un-halted.  Basically, HLT stops the CPU clock; kind of a pause button.  Obviously each package has its own "is the CPU idle?" threshold measurement mechanism.  This (and the UI) is what sets them apart.

Why is pausing the CPU good?  When the CPU is halted, it consumes virtually no power and thus, generates no heat. In some modern workstations, this can be the difference between a 40-watt bulb and a 300-watt halogen.

Why is this bad?  To restart the CPU requires a bit of overhead and (probably) a bunch of Windows context switches.  The delay comes not necessarily from the un-halting, rather it's a byproduct of CPUIdle watching the system and initiating the restart.  My guess is CPUIdle installs its own NMI (or hijacks an existing one) and redirects to its own code.   Halting/unhalting once every few seconds it's probably not a big deal.  Done multiple times per second, it could be a hit on performance.  Oh, and depending on how good the "CPU idle?" mechanism works, some important background activities could be missed or delayed.

Note that "a hit on performance" while describing something meant to run when things are idle may seem silly, but it's that second bit -- the waking up -- I wonder about.  Move the mouse and that generates an NMI and wakey-wakey... does it result in a micro-delay?  Probably.  Does it matter?  Probably not for a mouse.  But for a hard-drive?  A network card?

As Grorgy notes, some software doesn't generate the proper stimulus to awaken the CPU, so that raises questions about what else isn't getting acknowledged in a timely fashion.  Could Darwin's instability be a result of some interrupts not being serviced quickly enough?  It's one thing if your background MP3 downloads stall; quite another if your backup software isn't backing up, or various Windows services miss a beat here and there.  Remember, only NMIs natively reverse a HLT, and those are usually hardware generated.  Everything else has to be faked by CPUIdle.

It's probably a great tool for the uber-tweakers, and may even extend the life for a normal machine on the edge of failing.  It's certainly gotten glowing reviews from folks who watch their CPU core temp for a hobby.

There is also some irony in somebody tweaking a box to within microseconds of failure -- overclocking, water-cooling, Satanic rites -- and then installing a tool which, essentially, stops their CPU entirely.  And then exacts a small performance fee to restart it every few thousand microseconds.

f0dder:
Ralf Maximus: the NT idle thread already does HLT, so CPUIdle doesn't have an advantage there.

The CPU will always be woken N times per second because of the clock tick. Recent linux kernels have the option of running "tickless", which means a timer tick is only generated when necessary, not N times per second - but that didn't seem to have any advantages on x86 systems.

An external interrupt will always bring the CPU out of the HLT state (unless NMIs are masked, of course), and because of the timer tick, your system won't sleep indefinitely even if there's no other external interrupt signalled.

Btw I'm pretty sure more recent processors (intel speedstep, amd cool&quiet) have more to it than just HLT, at least you have to choose the correct "power mode" in windows for it to be effective... I'd rather use that than installing third-party software.

Again: cpuidle was fine for 9x, but why use it on NT?

Ralf Maximus:
The CPU will always be woken N times per second because of the clock tick.

--- End quote ---

If you're speaking of THE CLOCK, the crystal-driven heartbeat of the CPU, then that's what the HLT command supposedly stops.  The CPUIdle website itself explicitly says it issues a HLT statement to work its voodoo.

According to this MSKB article, NT's Idle thread is a real process that simply does nothing (if I understand it correctly).  Where does HLT fit into this?

I'm not discounting what you say; I'm not qualified.  I gave up assembly language years ago and only know what I read from the Intel & MS docs.  But CPUIdle is doing *something* and according to them it's driven by the HLT command.

Is it possible we are saying the same thing in different ways?

Navigation

[0] Message Index

[#] Next page

[*] Previous page