I have a problem in an application I''m doing in Windows 98. The problem is that if the app run through the night, the clock will have lost about ½ an hour. I''m doing quite a lot of writing to the harddisk, but if I skip this part the clock is fine. Therefore I assume that something concerning the disk-writes are causing the loss of time. Could someone please hint as to what the problem might be, and what could be done to prevent it. Best regards, Martin

if you have made your own clock app , relying in the windows timer(s), this will fluctuate on the hardware recourses, and not very reliable for time taking, but i guess u read the system clock out directly ....

You can use GetSystemTime() or GetLocalTime() to get the time in days, hours, etc., or timeGetTime() to get the time in ms since the system started.

Dave

The clock I was referring to was Windows own clock. When I look at the time after running the app a couple of days, the Windows clock would have lost about ½ an hour or so. When I restart the computer the clock is fine again, so the BIOS clock seems to be fine, but somehow the Windows clock gets outs of sync.

I found out that the problem arises regardless of the disk writes, so I''m pretty confused as to what causes the problem. I use quite a few threads in the app. Could this be the problem, or is there another cause for the clock getting out of sync.

Any thoughts?

- mMartin

What is your app doing? Is it running highpriority all the time, what processor occupancy? Does it use the clock in the code? Does it have many threads?

The clock is used in the code, and it is very important that the clock is correct.

I use about 10-15 threads (all of which are ''below normal'' in priority - as defined in MFC anyway). Most of these threads reads data from a net-socket, and stores lots of data to the HD. The main app. is normal priority. The program is quite exhaustive on the CPU - it takes about 100% of the CPU time.

Once a while I also see the mouse cursor lagging a bit, but I have no idea if this is because of the same problem as the time or not.

Any ideas?

- Martin

I think windows uses the PIT 8253 timer chip to update the clock. It generates 1193181 ticks per second. When you turn on the computer it generates an interrupt every every 10000h tick, making 18.2 hz, and the period 55ms. This agrees with msdn, which says that GetSytemTicks is updated every 55ms.

Well, now to your problem. If your program generates many interrupts, say by harddisk activity or switching between threads, then the interrups will be disabled quit a lot. Now if the hardware generates a PIT interrupt when interruppts are disabled then it will be discarded. The Windows clock has lost 55ms. Do you see the problem?

This also explains you mouse problems, when interrupts are disabled the mouse can not generate an interrupt to the hardware and there will be lagging.

Now how would you solve this problem? I think that you could write some inline assembler that gets the bios clock, perhaps once every hour.

Hope this helps.

fredizzimo, thanks for the help. My guess was that it was something like this, but didn''t know exactly where it went wrong.

- Martin