Mobo Beeps w/HandBrake?

EP45-UD3L.

When I run the video transcoding app "HandBrake" with "Normal" CPU
priority, I get intermittent beeps from the mobo.

Setting it down to "Below Normal" (in Process Lasso's scheme of
things...) the beeps go away almost completely.

Kicking it up to "High", makes Windows XP appear to freeze and the mobo
emit a continuous beep. But XP isn't really frozen, just really,
really, really unresponsive. Click on Process Lasso's UI to reduce CPU
priority, wait a few minutes, and the menu pops.

Looking at the mobo's temps via "SpeedFan", I'm seeing cores 1-4 in the
low sixties C and core 0 up around 67 degrees C. But when I kicked the
priority up to "High" Core 0's temp spiked up to 69-70 degrees and the
other two showed a similar increase.

Based on SpeedFan's temperature graph, I'm guessing it's the mobo and
not the graphics card, but I really have no clue.

Can anybody shed some light?

Mainly I'm wondering if the CPU and/or mobo is getting physically
abused/damaged/worn or the mobo is just telling me that it's not working
as well as it should be.

 

There's a report here, for another Gigabyte motherboard, mixed with
transcoding video. The person reporting, says they have a temperature
alarm program, and it isn't going off, and yet the motherboard beeps.

http://www.idlethumbs.net/forums/topic/5842-buying-or-building-a-pc/page-2

Beeps from the BIOS level, can exist for a number of reasons. CPU overheat
is one. VCore output voltage out of spec is another. Fan failure is a
third reason. The BIOS gets to run via SMM, and we know Gigabyte does
stuff like that, because of when they've issued boards with DPC latency
problems. (DPC latency is an indirect means, of detecting the motherboard
taking "tea breaks" to run BIOS code. If Gigabyte re-releases the BIOS,
sometimes this is fixed, and the latency improves, meaning less time
spent at BIOS level. People who build audio workstations, tend to
bitch to Gigabyte about "DPC Latency too high".)

http://en.wikipedia.org/wiki/System_Management_Mode

"The SMM may disrupt the behavior of real-time applications with
constrained timing requirements."

There is not supposed to be any way of detecting an SMM from Windows.
Indirect observation, with DPCLat, is one way, but it's not checking
a status bit or anything. DPCLat merely notes that "some time went missing"
in a sense. The OS can't tell when it's taken an SMM, and clock ticks
can be missed that way. I presume some fine-grained timer, is still
working, as without it, DPCLat program couldn't observe what is
going on. (Use this, if doing real time work, and needing to
look for latency spiking...)

http://www.thesycon.de/deu/latency_check.shtml

If you use something like SpeedFan from almico.com , or use whatever
Gigabyte provides for hardware monitor output, you might be able to
check what is happening with respect to the potential functions being
monitored. You've already done that for temperature. Leaving VCore
or fan speed as variables (and it probably isn't fan speed).

The only other thing you're missing, is visibility into "Throttling".
I don't believe the BIOS SMM would monitor that. But this is a means
of measuring whether you don't have sufficient cooling for the CPU.
When doing a video render, the system should not Throttle. You can use
RMClock to display the Throttle bit. Throttling there (performance loss)
exists, as a thermal control mechanism. If the CPU throttles, you
need a better cooler.

http://ixbtlabs.com/articles2/cpu/intel-thermal-features-core2.html

http://www.ixbt.com/cpu/intel-thermal-features/c2xeq_5.png

http://cpu.rightmark.org/download.shtml

"RMClock Utility 2.35"

*******

On other brands of motherboards, a BIOS beep during runtime would
sound like a European police car siren. That sound would be coming
from the case speaker. That's a warning of a temperature or
VCore voltage problem.

It's normal for VCore to dip a bit. That's called the load line,
and the VCore can be off by 0.15V at high load. The BIOS should
not be beeping, if the processor is withing the high or low load
lines. Intel provides a graph in their CPU spec, showing acceptable
limits for the load line. So if there is an alarm function for that,
it should only trigger at more than 0.15V on the low side.

The processor itself, has VID pins on the socket. The VID pins
put out a five or six bit code. That feeds the regulator. Intel
fixes the range of values the register driving VID can put out.
To do "boosted" VID values, that's usually done by adding a boost
through an offset in the regulator. So when you're analysing
VCore yourself, be aware that the target is variable to begin
with. Perhaps it's 1.0V when Idle, and 1.3V under 100% load. Then,
the load line would be on top of that. 1.3V - 0.15 = 1.15V. Those
are some considerations. Now, I don't remember exactly how I did
it (maybe RMClock???), but I got values for my particular processor
for the allowed range of VID register.

The datasheet for the processor, won't have the information, but
the info is "baked" into the processor somehow, and it's to prevent
easy overvolting. The reason VID is variable in the first place,
is for SpeedStep (EIST) functions. My divider spans 6X to 9X, and the
VID voltage code is adjusted for each multiplier value. If you
turn off EIST, then the multiplier and VID values should stay at
their peak (9X, 1.3V etc). On my Asus motherboard, not only did
I have to disable EIST, I also had to disable some C-state settings,
to jam the motherboard at the nominal 3GHz CPU clock. (On the older
Asus boards, just disabling EIST was enough. Modern boards have C-state
meddling as well.) So if I wanted to do some VID
monitoring, perhaps my first step would be jamming the thing
at top multiplier (9X), then see whether VID stays put.

On an Asus motherboard, at idle, the VCore will be 0.060V above
nominal. So if the VID code said "make 1.0V", an Asus would
actually put out 1.06V, and that would be considered normal for
an Asus. And then, with full load, and say 1.3V max VID setting,
I might see 1.3-0.15=1.15V for VCore. The processor draws so much
current, that's why the VCore value drops.

*******

For now, it might suffice to see if Throttle correlates with
"The Beep", and see if that is the trigger condition. You can do
the other stuff, if you want a finer grained estimate of the
situation (VCore too low). Due to the dynamic nature of VCore,
the first step is to disable the dynamic, as that makes static
readings easier to interpret (say 1.3V + 0.060V at idle, and
1.3V - 0.150V at load).

HTH,
Paul