REMINDER: Leap Second
list at satchell.net
Sun Jan 25 22:24:52 UTC 2015
On 01/25/2015 10:15 AM, Valdis.Kletnieks at 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
More information about the NANOG