The clock Lagged when MediaPlayer play mp3?

[mttc]

Gigabyte EX58-UD4 Board, Clean XP SP3, disconnect from network.

When I play mp3 with Microsoft MediaPlayer, the XP clock start lagged
about 3 sec per Minute! This happen only if EasyTune tools is also
running (Gigabyte board tune tool).
I try to play with VLC, and I not see any lagged.

I try it again on win7 clean install and I got the same. I try also to
replace the Power Supply or use with one Stick of memory. but all the
same.

Any Idea please?

 

[Paul]

Gigabyte EX58-UD4 Board, Clean XP SP3, disconnect from network.

When I play mp3 with Microsoft MediaPlayer, the XP clock start lagged
about 3 sec per Minute! This happen only if EasyTune tools is also
running (Gigabyte board tune tool).
I try to play with VLC, and I not see any lagged.

I try it again on win7 clean install and I got the same. I try also to
replace the Power Supply or use with one Stick of memory. but all the
same.

Any Idea please?

Pretty simple. Stop using EasyTune.

A potential mechanism to screw up a system clock,
is described here.

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

"and cause clock ticks to get lost"

Just a guess,
Paul

 

[mttc]

Pretty simple. Stop using EasyTune.

A potential mechanism to screw up a systemclock,
is described here.

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

    "and causeclockticks to get lost"

Just a guess,
    Paul

Did you mean that ET6 run on System Management Mode?
Did this Explain why I got Clock slow also after Sis Sandra BanchMark?
why Sandra not cause me Lag on other boards systems?

Thenks

 

[Paul]

Did you mean that ET6 run on System Management Mode?
Did this Explain why I got Clock slow also after Sis Sandra BanchMark?
why Sandra not cause me Lag on other boards systems?

Thenks

To make the WinXP system time clock run slow, you need a mechanism which
causes clock tick interrupts to get lost. If the interrupt service
routine doesn't get to run in time, that is a mechanism.

Clock tick interrupts come from hardware, many times a second.
That particular interrupt has a high priority, and in a normal
system, no other activity would prevent the interrupt from being
serviced. To explain a slow running clock (where the time loss is
larger than can be explained by the accuracy of the quartz oscillator),
you need a mechanism which causes the loss of clock tick interrupts.

Software activity at the kernel level, works with sets of rules.
Such as not running at interrupt level for long period of time
and the like. (The hardware drivers added to the system, also have
to follow the rules.) If there was a problem with the design of the
OS itself, then time loss would be seen by many users.

There have been cases, where the problem is caused by a hardware
bug. For example, some motherboards with Nforce2 chipset, have
trouble with time keeping. The problem was only evident, when
some of the boards were overclocked (non-canonical operating
frequency for the chipset). The bug may have been in the
interrupt logic.

If you see the problem, with both WinXP and with Win7, that
tends to suggest there must be a hardware or driver component
to this problem.

You have a function in the BIOS called HPET, and you could
try disabling that for a test. I don't know why that would be
a problem, but it is all I can see that might be related,
in the BIOS.

http://web.archive.org/web/20040729073446/http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx

Paul

 

[mttc]

To make the WinXP system timeclockrun slow, you need a mechanism which
causesclocktick interrupts to get lost. If the interrupt service
routine doesn't get to run in time, that is a mechanism.

Clocktick interrupts come from hardware, many times a second.
That particular interrupt has a high priority, and in a normal
system, no other activity would prevent the interrupt from being
serviced. To explain a slow runningclock(where the time loss is
larger than can be explained by the accuracy of the quartz oscillator),
you need a mechanism which causes the loss ofclocktick interrupts.

Software activity at the kernel level, works with sets of rules.
Such as not running at interrupt level for long period of time
and the like. (The hardware drivers added to the system, also have
to follow the rules.) If there was a problem with the design of the
OS itself, then time loss would be seen by many users.

There have been cases, where the problem is caused by a hardware
bug. For example, some motherboards with Nforce2 chipset, have
trouble with time keeping. The problem was only evident, when
some of the boards were overclocked (non-canonical operating
frequency for the chipset). The bug may have been in the
interrupt logic.

If you see the problem, with both WinXP and with Win7, that
tends to suggest there must be a hardware or driver component
to this problem.

You have a function in the BIOS called HPET, and you could
try disabling that for a test. I don't know why that would be
a problem, but it is all I can see that might be related,
in the BIOS.

http://web.archive.org/web/20040729073446/http://www.microsoft.com/wh...

    Paul

I disable HPET Support on BOIS. the I boot XP again and I run EsyTune
(Gigabyte board tune tool). I not open any other App (no need to rum
also the MediaPlayer). the Clock Start Lagged. I not underspend what
cause that difference.

I not get any clue from Gigabyte that have known issues about EasyTune
with this board. Also I ask Sis Sandra, they answer me:

 

[Paul]

I disable HPET Support on BOIS. the I boot XP again and I run EsyTune
(Gigabyte board tune tool). I not open any other App (no need to rum
also the MediaPlayer). the Clock Start Lagged. I not underspend what
cause that difference.

I not get any clue from Gigabyte that have known issues about EasyTune
with this board. Also I ask Sis Sandra, they answer me:

Well, the basic mechanism for the system time to run slow, is known.
It has to do with interference with the clock tick interrupt and
its servicing. So you'd be looking for a mechanism that could do that.
It isn't exactly going to be easy to figure out, unless you happen
on the solution by accident. (I don't know enough of the details
of the various mechanisms, to help further.)

The existence of SMI and SMM, was enough for these users to attempt
to change the settings. The software they want to run, is real-time,
and interference is unacceptable. So they attempted to disable SMI,
as a means to prevent any interruptions of real-time operation.
The BIOS can lock the controls on SMI (SMI_Lock bit), to prevent
a potential security issue. And that might mean, that any defined
mechanism, cannot be changed while the OS is running.

http://www.mathworks.com/matlabcentral/fileexchange/18832

*******

Just out of curiosity, there is another parameter you may wish to
evaluate on your Gigabyte motherboard. That is DPC latency.

http://forums.anandtech.com/messageview.aspx?catid=29&threadid=2182171

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

There is nothing wrong with DPCs. A DPC is a deferred procedure call,
a way of scheduling interrupt handler work, to run at user level. That
shortens the time spend at interrupt level. The DPC Latency Checker
tool, measures the response time for the DPCs to get services. (So
a DPC is added to the queue, and the latency checker records how
long it took before it was serviced. Too long a latency, affect
sound playback for example.)

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

On my cheap motherboard with Core2 Duo processor, I can run the DPC Latency
Checker. Currently, I have a 3D game, running in the background as a load.
The DPC Latency Checker, shows green bars, having a height of no greater than
about 250 microseconds. If I actually enter the game (with alt-tab), the
latency goes up to about 800 microseconds. But the bars are still green,
implying the responsiveness of the computer is not affected significantly.

You might try running the DPC Latency Checker, and see if you also have
a problem with that. If you have an interrupt problem, it may also reflect
itself in excessive DPC latency.

Paul

 

[mttc]

Well, the basic mechanism for the system time to run slow, is known.
It has to do with interference with theclocktick interrupt and
its servicing. So you'd be looking for a mechanism that could do that.
It isn't exactly going to be easy to figure out, unless you happen
on the solution by accident. (I don't know enough of the details
of the various mechanisms, to help further.)

The existence of SMI and SMM, was enough for these users to attempt
to change the settings. The software they want to run, is real-time,
and interference is unacceptable. So they attempted to disable SMI,
as a means to prevent any interruptions of real-time operation.
The BIOS can lock the controls on SMI (SMI_Lock bit), to prevent
a potential security issue. And that might mean, that any defined
mechanism, cannot be changed while the OS is running.

http://www.mathworks.com/matlabcentral/fileexchange/18832

*******

Just out of curiosity, there is another parameter you may wish to
evaluate on your Gigabyte motherboard. That is DPC latency.

http://forums.anandtech.com/messageview.aspx?catid=29&threadid=2182171

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

There is nothing wrong with DPCs. A DPC is a deferred procedure call,
a way of scheduling interrupt handler work, to run at user level. That
shortens the time spend at interrupt level. The DPC Latency Checker
tool, measures the response time for the DPCs to get services. (So
a DPC is added to the queue, and the latency checker records how
long it took before it was serviced. Too long a latency, affect
sound playback for example.)

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

On my cheap motherboard with Core2 Duo processor, I can run the DPC Latency
Checker. Currently, I have a 3D game, running in the background as a load..
The DPC Latency Checker, shows green bars, having a height of no greater than
about 250 microseconds. If I actually enter the game (with alt-tab), the
latency goes up to about 800 microseconds. But the bars are still green,
implying the responsiveness of the computer is not affected significantly..

You might try running the DPC Latency Checker, and see if you also have
a problem with that. If you have an interrupt problem, it may also reflect
itself in excessive DPC latency.

    Paul

I not sure that this effect on clock. the OS determine the Time by
counting the tick interrupt, even it come late.

 

[Paul]

I not sure that this effect on clock. the OS determine the Time by
counting the tick interrupt, even it come late.

I agree that the mechanism seems improbable to you, but
what other mechanisms are there ? The beauty of SMI,
is the computer is defenseless against it. If the SMI
runs longer than a clock tick, the clock tick is lost
and not counted. To lose time consistently, and with
more error than can be accounted for by the quartz
timing elements, requires a violation of the expectations
of the OS designer. The clock tick interrupt is assigned
a high priority, to help prevent this sort of thing.

Run the DPC check. While DPC has nothing to do with the
clock tick interrupt, a high DPC latency is also an
indication that something is preventing the system from
being responsive. In some cases, a BIOS update has fixed
a DPC issue.

Paul