On 01/25/2015 10:15 AM, Valdis.Kletnieks@vt.edu wrote:
It shares another problem - that doing calculations across a boundary is difficult. If you have a recurring timer that pops at 23:58:30 on June 30, and you want another one in 2 minutes. do you want a timer that the next pop is at 00:00:30 - or 00:00:29? The operating system can't tell whether the desired semantic is "as close to every 120 elapsed seconds as possible" or "as close to the half-minute tick as possible".
I have automation code for a "classroom" full of Cisco routers, and the way I deal with that sort of issue is to say that anything that has to be synchronized to the wall clock uses cron(8), but for actions tied to a fixed interval I use sleep(3) and let the operating system sort out the issues, if any. I did this to sidestep the issues with Daylight Savings Time (DST) cusps; it also works for leapseconds, as the OS interval timing is not tied to the real-time clock. Funny you should mention ticks versus elapsed time. In every specification I've written since 1970, I've differentiated between the two. I got started doing that because in the computers of that era the real-time clock was tied to power-line frequency, while the interval timers were based on counts on a crystal oscillator. The crystal was using good for 1000 parts per million, good enough for short intervals. The power-line clock was pulled back and forth by the power company as said company would fine-tune the time so electric clocks would stay at the right time long-term as the expense of short-term jitter. Today's computers don't use clocks derived from 50- or 60-hertz power-line frequency. The last computer I remember seeing with such a clock was the IBM System/360. The System/370 used a motor-generator set for the power supply, so it had to get its real-time clock time source another way.