How to give the pc clock the highest priority

D

DarkCyber

[H]ard|Gawd
Joined
May 14, 2003
Messages
1,273
This is the closest place I could find to post this.

I have computer that needs the pc clock to trigger some events at exact times during the day on some software. This works perfect, most of the time. About once or twice every few weeks now the program is missing some of these triggers. The writers of the software says it has to do with the OS hiccuping or being busy at that exact moment and makes the program miss that exact time trigger...e.g.

6:00:00 AM

They are saying that Windows XP Pro instead of rolling from 5:59:59 to 6:00:00 AM that it is skipping 6:00:00 AM and maybe going from 5:59:59 to 6:00:01, thus the trigger set at 6:00:00 AM never gets triggered, because the pc never actually saw that exact time. One more note, the time is synced with internet time servers, but no where near the time that these triggers are set for. So, they are not missing due to the fact that the pc clock is being updated and maybe skipping it that way.

So, now to my question. Is there a way to give the computer clock the absolute highest priority of all other operations?

This pc has very little installed on it and is using very very little system or cpu resources, so I am at a loss here. What they are saying sounds plausible.
 
Interesting, never heard of that before but it does sound like it could be a possible reason.

Odd though as I have never had an issue with tasks being carried out at set times (like backups, av scans, etc.).


Is what you could look for is what process is the windows clock. Then you could go into task manager --> processes --> right click on the process --> Set Priority --> High
 
I would assume that the clock doesn't run under any seperate process or thread, it's a piece of hardware. The kernel is responsible for communicating with it, but it's not a seperate program. You cant just lower the priority and the computer skips out of the space-time continuum ;).

Seriously, the clock is a chip on the motherboard, it requires no resources. What does however is communicating with it. The kernel is the end all be all for doing so if you are looking for a 'process', that is what is doing the work. For instance, your clock in the task tray is mearly a program that when it's process started it asked the kernel, through an API (application programming interface), what time/date it is. The kernel gave it that time and the process went on about it's merry way. Now, I don't know for certain, but I would guess there are only 3 ways the taskbar clock process can continue. It could either a) constantly poll the kernel, spawning a costly thread each time, asking what time it is or b) create an autonomous timer of it's own that only periodically recalibrates itself to the system clock or c) subscribe to an event that the parent API fires to it (think firing an event every second for the SECOND_EVENT or every minute for the MINUTE_EVENT) so it in effect relies on the API to publish time to it. B and C are actually related, as in order to do B effectively you would have to implement C. So in all likely hood, C is how it's done, and C is how they are doing it.

So now that your brain is scrambled, what can you do? Well the hardware clock is out of your control, as are the kernel (unless you're a general [oh man, couldn't stop myself]) and the API being used. In short, you can't fix their problem, they will have to. If the machine truly isn't overutilized at the time in question, then they are going to have to implement a better way of checking the time - likely through a lower level API that is more reliable.
 
My first thought was that perhaps the atomic clock sync built into windows was occasionally firing up and adjusting your clock, thus "skipping" certain seconds.
 
I tend to agree with SpaceHonkey, find a better way. Instead of "is current time == trigger" then do something like "is current time >= trigger. That way you won't miss it because it skips a few ms
 
You could just disable the synchronization to a server and then manually update it as often (or not often) as you like.
 
Yep if the trigger relies on 1 microsecond to launch it's bad programming not a hardware issue.
 
Thanks for the suggestions. I feel that it is something in their software as well.
 
Can you modify the sig. digits in any way? so that 6:00:00 to 6:00:29 are rounded to 6:00:00? That may be something they have to do within their program though...
 
pallesen said:
I tend to agree with SpaceHonkey, find a better way. Instead of "is current time == trigger" then do something like "is current time >= trigger. That way you won't miss it because it skips a few ms
Click to expand...

I think that this is easiest solution:)
 
Most PC operating systems record the passage of time by counting interrupts on a real time clock or an ACPI timer. Since windows is not a real time operating system, a clock tick interrupt does not guarantee a context switch to the interrupt handler, and thus time can be lost. The logic in their software is flawed since there is no assurance in the operating system of getting CPU time scheduled at the exact time. If this where a RTOS it might be different.
 
Christopher said:
Most PC operating systems record the passage of time by counting interrupts on a real time clock or an ACPI timer. Since windows is not a real time operating system, a clock tick interrupt does not guarantee a context switch to the interrupt handler, and thus time can be lost. The logic in their software is flawed since there is no assurance in the operating system of getting CPU time scheduled at the exact time. If this where a RTOS it might be different.
Click to expand...

And THAT's the winner!


Any software that relies on timing precision that finite needs to have better handling for cases where it can be +/- that precision.
 
I agree. The program I am using is called Wavestation, which is made by www.bsiusa.com. That program is the older version of their software as they have replaced it with a newer version called Simian. But Simian still has the exact same problem, based on posts in their help forum. So, whatever they did in Wavestation, they must still be doing the same thing in Simian.

Thanks everyone, but looks like I am just stuck with this being an occasional problem :mad:
 
not really, for interups and multi-task schedualing the ACPI is/was used but that was innacurate as CPU-speed increased. That is what the HPET is for, a high precision event timer, ie you are running lots of processes and the kernel need to allocate x amount of CPU-time to each the ACPI/RTC-interup/HPET is used

It aint used for date-time info or for scheduling something to happen every day at 6pm (although if you coded a program yrself to use the HPET you could)

Scheduling and CRON come of the main system time and are also low-priority processes and as such IF there are other apps/services that are running with a higher priority there is the possibility it misses the time

I have a cron-job that updates every 6h and the last update actually occured at 12:59:06 54sec within the every 6h BUT it did it

the problem here it seems (and has been pointed out) was the use-of == and not >= for the time
 
You must log in or register to reply here.
Back
Top