Mobo Beeps w/HandBrake?

Discussion in 'Gigabyte' started by (PeteCresswell), May 1, 2013.

  1. 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.
    (PeteCresswell), May 1, 2013
    1. Advertisements

  2. (PeteCresswell)

    Paul Guest

    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.

    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".)

    "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...)

    If you use something like SpeedFan from , 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.

    "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).

    Paul, May 1, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.