"StandBy" and Reported Latency Settings

[BonzaiDuck]

In the last couple months, I've discovered the following phenomenon.

Here are the background facts: I run the system with SpeedStep disabled. Whether I over-clock or not, I choose the memory latencies manually, even if they are the SPD/EPP spec. The motherboard is an ASUS Striker Extreme (nVidia 680i chipset). The memory is Crucial Tracer DDR2-800, but that shouldn't matter.

When I put the system on "Standby" and then wake it up, Everest Ultimate and CPU-Z both report a tCL CAS latency that is less by that set in BIOS by either 1 or 2.

Yet, there is no system instability whatsoever, nor any data corruption, nor any failures under PRIME95.

I sent a tech-support query to Lavalys (Everest Ultimate), and they believe it's a bug in the BIOS.

I sent a tech-support request to ASUS, and they sent back this gibberish in which every paragraph addressed a possible cause for "instability."

Like I said, there is no "instability," but the utilities all report this tCL inconsistency when waking up from Standby.

Comments? Observations? Insights? Has anyone seen or noticed this? Does anyone know why it happens? Could it be a flaw in the operating system (Win XP MCE 2005 SP2 -- same as Win XP Pro SP 2)?

 

[Mondoman]

"Standby" mode has always had various problems -- I wouldn't worry about an issue that doesn't seem to cause any instability. I'd be more worried about potential unseen instabilities caused by standby mode.

 

[BonzaiDuck]

Such as . . . .?

See, I've gotten really itchy about power-bills lately. We trimmed down the number of computers in the house running simultaneously from 5 to 3. But a machine I built in 2003 uses 150W, while this quad-core monster uses 320W at idle and close to 418W at load.

So Standby mode is important to us. So far, I haven't had much of a problem with Standby mode -- although there were a couple times when it wouldn't wake up. I'm only tentatively chalking this up as possibly linked to marginally stable settings, or some problem with SpeedStep, or even OS settings in "power options." I was able to eliminate those troubles by disabling speedstep and setting Power Options to "Always On." And I retested my system to choose voltages that were minimal, and then kicked them all up one notch for "extra insurance."

So now when I set the system to "Standby," and I return to the machine a few hours later and wake it up, it's still functioning the way it had been before Standby.

But the utilities report tCL that is either lower than the BIOS setting by 1 or 2.

 

[Mondoman]

The problem is that standby mode has always been somewhat of an afterthought, especially to the OS and driver writers. Many people never use it, and it certainly doesn't get as much attention and testing by developers. In general, the BIOS and low-priced peripheral drivers get the least attention and resources, so that's where I'd most expect a problem. It's tricky to shut down and later turn back on all sorts of low-level hardware and software systems without any unintended consequences (such as those caused by hidden dependencies).

If it works for you, then keep using it. Personally, I just shut my systems off at night.

 

[BonzaiDuck]

Then that explains it, Mondoman.

Originally posted by: Mondoman
The problem is that standby mode has always been somewhat of an afterthought, especially to the OS and driver writers. Many people never use it, and it certainly doesn't get as much attention and testing by developers. In general, the BIOS and low-priced peripheral drivers get the least attention and resources, so that's where I'd most expect a problem. It's tricky to shut down and later turn back on all sorts of low-level hardware and software systems without any unintended consequences (such as those caused by hidden dependencies).

If it works for you, then keep using it. Personally, I just shut my systems off at night.

That explains why I haven't seen anyone address it enough so that I probably wouldn't have been obliged to post these observations . . . and . . . . concerns.

BUT

I've discovered something else, late as it is, just past the mid-point in this motherboard's industry/market life-cycle.

Scenario 1 -- Sequence of events, commonly experienced:

a) [Status: PSU toggle, ON; rear Striker-Extreme board-active toggle ON; [blue utility lights OFF]and "motherboard-active." Clean electrical power at 40% CPU capacity.]

front-panel momentary power-on toggle ON.

[boot,OS-loads, usage]

b) "Start->Shutdown->Turn_off_computer->Turn off"
[powers down normally]
c) if iterations = 0 then goto a)
d) [CDROM, hard-disk array initialize; keyboard, monitor initialize; System Post . . . OS loads.]
e) stop

Scenario 2 -- introduces "Standby"

a) front-panel momentary power-on toggle ON.
[boot,OS-loads, usage]
b) If iterations = 0, then "Start->Shutdown->Turn_off_computer->Standby" else (d)
c) Wake with mouse and keyboard
[machine responds normally]
d) "Start->Shutdown->Turn_off_computer->Turn off"
[normal system power-down]
e) do a)
[CDROM, HD array intialize; keyboard fails initialization -- no KYBD LED, monitor fails initialization -- remains in amber/sleep-state.]
[remedy: RESET]