Timer malfunctioning

[Juiced]

It seems something is failing on my motherboard. I've noticed that the Timer function jitters up and down. Here's a printout of several consecutive timer calls:
16090.8648817565
16090.8655844935
16090.8658789935
16090.8661592525
16090.8667812585
16090.8675800095
16090.8679783515
16090.868238152
16090.868663429
16090.864650254 <-----goes back down
16090.8652471265
16090.8701513455
16090.8661306515 <----goes back down
16090.866414312
16090.8712938285
16090.871486019
16090.871663644

Eventually it'll get to the point where it jumps down every 3-5 calls. Resetting my machine fixes it temporarily. Does anybody know what can cause this, how to fix it? I've searched google but with no luck since I don't know what I need to search for. Believe it or not, these small jumps really screws up my program. Thanks

[Gonzo]

if the timer jumps back more than 0.001 thats indeed an issue
remember that each cpu has its own HPET, which will invariably have its own time
its not an accurate measuring tool...
is this a single core cpu?

edit: i believe the times are synchronized between cpus now and then... which could explain your results
just dont use time measuring per thread and compare.. it will never work

[Juiced]

Here are my specs. I believe it's a dual core.

Mainboard : MSI K9VGM-V (MS-7253)
Chipset : K8M890CE Host Bridge
Processor : AMD Athlon 64 X2 3800+ @ 2000MHz
Physical Memory : 2048MB (1 x 2048 DDR2-SDRAM )
Operating System : Microsoft Windows XP Professional 5.01.2600 Service Pack 3 (32-bit)

The reason the timer is affecting my code is that I use a special timer function that gives the difference between 2 times:

Code: Select all

FUNCTION TimeDif (BYVAL ST AS DOUBLE, BYVAL FT AS DOUBLE) AS DOUBLE
    
    'This function returns the time length
    'between ST(start time) and FT(finish time)
    'while checking and adjusting if the clock
    'rollover occurs.
   
    IF ST < FT THEN
         TimeDif = FT - ST
    ELSE
         TimeDif = FT - ST + 86400
    END IF

END FUNCTION

So this basically adds 86400 to the time difference if the Start Time is larger, meaning the rollover occurred. I would use it like this:

Code: Select all

MyVarST = TIMER
do
     If TimeDif(MyVarST, TIMER) >= 1 Then
          print "1 second has elapsed"
          exit do
     end if
Loop

So in my case, with a bad timer acting up, a lot of times the start time will be larger than the end time since the timer function jitters back, which would add 86400 to the difference and cause the If statement to execute before the correct time difference occurred. It never happened before, but lately it's been acting up and gets worse the longer I wait between reboots.

[Gonzo]

well, your best bet is google here...
something is wonky with your cpu or drivers or kernel or anything in between

[Juiced]

well, your best bet is google here...
something is wonky with your cpu or drivers or kernel or anything in between

I tried searching for many variations of this subject, but no luck. Anybody have an alternative to Timer since it's unreliable?

[dodicat]

These boards are >= 5 years old?
I would suggest as a first investigation to check your computer battery, is your computer date and time correct immediately after booting?
Batteries last about 5 years.

[Juiced]

These boards are >= 5 years old?
I would suggest as a first investigation to check your computer battery, is your computer date and time correct immediately after booting?
Batteries last about 5 years.

My clock seems fine, but I didn't think the HPET ran off the cmos battery. Unless there's another battery I'm unaware of?

[Juiced]

I think I'll simply use a frame counter to time things. The smallest increment is 1/60 which is small enough.

[Gonzo]

HPETs have nothing to do with onboard clock.. after all, HPETs are stopped and reset in sleep mode and hibernation
your wonky timer is most likely because of some other issue... like dust or simply old age.. maybe thermal paste used up
who knows :/

[dodicat]

I have Win xp pro, (5.1, build 2600) service pack 3.
Two Intel Xeon processoes at 3.00 Ghz each, dual core, so 4 processors are counted in dxdiag.
32 bit system.
The significant jump in your timer, i.e, the 3rd and fourth decimal places seems large for 2.00 Ghz, then of course it jumps back down after several increases, which is your problem.

If I run this snippet here, I get a jump of either 2 or 3.
I get no beeps.

If your clock is ok then at least battery trouble can be ruled out, the HPET is clock independent right enough, but a low battery can yeild strange results in XP.
Here's the snippet, sorry I can't be of more help.

Code: Select all

 

dim as double t,oldt

do
    t= timer
    print  mid(str(frac(t)),5,2);",";
    if t<=oldt then beep
    oldt=t
loop until inkey=chr(27)

sleep
  

[Juiced]

If I run this snippet here, I get a jump of either 2 or 3.
I get no beeps.

I'm getting: BEEP,BEEP,BEEP,BEEP,BEEP,BEEP,BEEP,BEEP...lol
Yup, there's something wrong alright. I'll try replacing the cmos battery.

[MichaelW]

Interesting problem.

I have doubts that Windows XP SP3 supports the 2005 version of the HPET.

AFAIK the HPET is part of the chipset, not the processor cores. But just in case the problem is with per-core timers (APIC for example) out of sync, and the system moving your process between cores, you can limit your process to a single core with code like this:

Code: Select all

''=============================================================================
#include "windows.bi"
''=============================================================================

dim as uinteger processAffinityMask, systemAffinityMask

''--------------------------------------------------------------------
'' For the following two functions a non-zero return value = success.
''--------------------------------------------------------------------

''---------------------------------------------------
'' Get the current process and system affinity mask.
''---------------------------------------------------

print GetProcessAffinityMask( GetCurrentProcess(), _
                              @processAffinityMask, _
                              @systemAffinityMask )
print bin(processAffinityMask,32)
print bin(systemAffinityMask,32)

''-----------------------------------------------------------
'' Restrict process to a single core. The specified affinity
'' mask must be a subset of the system affinity mask.
''-----------------------------------------------------------

print SetProcessAffinityMask(GetCurrentProcess(), 1)

print GetProcessAffinityMask( GetCurrentProcess(), _
                              @processAffinityMask, _
                              @systemAffinityMask )
print bin(processAffinityMask,32)
print bin(systemAffinityMask,32)

Result on a system with two virtual cores (a P4 with hyperthreading):

Code: Select all

 1
00000000000000000000000000000011
00000000000000000000000000000011
 1
 1
00000000000000000000000000000001
00000000000000000000000000000011

MSDN: Process and Thread Functions

The only part that I can see the CMOS RAM battery playing in this would be if the system is not retaining the BIOS setup.

[Juiced]

The only part that I can see the CMOS RAM battery playing in this would be if the system is not retaining the BIOS setup.

My Bios setup is kept so that eliminates that guess.

[Richard]

Now my guess.

The Timer counts cycles, if the chip is hot, aged or has the wrong supply voltage then the data may be corrupted while being read from the counter. This may be data dependent, for example when the number of adjacent zeros in the data transfer exceeds a threshold, the chip is unable to generate the binary number with sufficient signal voltage to be read correctly.

If you cool the chips and the problem disappears then it is a hardware fault, but you cannot tell if it is heat, voltage or age, only that the combination is unstable. To only effect the timer and not to crash the system requires that the hardware problem be specific to the counter. Maybe insufficient power distribution to the counter's buffer on the chip.

Replace the fan if it is faulty, or remove the obstruction to clear the air vents.

I might restart the computer and then look at the bit pattern of the timer register read, unfortunately timer returns a Double, not the original integer, so it is going to be a bit hard to see a rogue pattern.

[MichaelW]

If the system is otherwise not misbehaving, I think it is unlikely to be a hardware problem. Restarting the system should put the cores back in sync, but with the variable clock speed typical of recent processors (along with the ability to hibernate, etc) they will eventually get out of sync. If this is what is happening, and the FB Timer value is being derived from a per-core counter, and the system is not consistently running the process on the same core, limiting the process to a single core should eliminate the jitter.

I might restart the computer and then look at the bit pattern of the timer register read, unfortunately timer returns a Double, not the original integer, so it is going to be a bit hard to see a rogue pattern.

AFAIK under Windows the FB Timer value is derived from the high-resolution performance counter via the QueryPerformanceFrequency and QueryPerformanceCounter functions. You could call the QueryPerformanceCounter function to get the 64-bit integer count.