Re: POE and the time

This discussion reminded me of:

http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

-- 
Jeremy Leader
[email protected]

On 12/14/2012 09:52 PM, Chris Fedde wrote:
> A few comments about the wiki notes.
>
> First ntpd is careful about ensuring that time always moves forward.  It
> does this by adjusting the clock slew rather than jumping time forwards or
> backwards.  When ntpd first starts up and the system clock is not set
> within 5 seconds relative to its ntp servers then ntpd will die with a log
> message rather than jump the time.  Within about an hour of starting ntpd
> can have the system synchronized within a few milliseconds of its best
> server.
>
> Some admins like to run ntpdate out of cron and force a time reset at
> regular intervals.  It's never a good idea to force time jumps. It can case
> all kinds of trouble for databases, NFS, cryptography, process scheduler
> and even event systems written in perl.
>
> Most systems have a separate hardware clocks that is pretty accurate.  OS
> time is typically synchronized with it at boot then runs independently of
> it.  Some admins like to synch with hwclock out of cron.  This is also a
> bad idea.  On "wintel" type systems the hardware clock typically reports
> only down to seconds.  This is much too rough for modern time keeping.,
>
> Virtual machines add another whole layer of complexity to the picture.  A
> vm will frequently have time jumps between time slices when it gets to run.
>   Things that require real time behaviors probably should not be run in a
> vm.  VM guests have to trust their host for an accurate representation of
> time.  And all the issues that crop up above add another layer of
> complexity to accurate time keeping here
>
> There are very few good reasons for administrative clock adjustments.
>   These days there are no good reasons based on simple calendrical causes.
>   Soon even the dreaded leap second will be dealt with through math  and
> lookup tables rather than clock adjustments.   Nearly all other reasons to
> adjust the clock are political and organizational rather than technical.
>
> If we still want to deal with time sifts we have to detect them. When time
> jumps occur it is hard for a program to detect them.  The only way that the
> program would know that time has changed is if it has two sources to
> compare.  If such an event has been detected then it has to decide if there
> was a good administrative reason for the change or not.
>
> If the program decides to take action because it has detected a time change
> then  it must have an array of logic to decide what special behaviors to
> apply for all of the various ways that the change could have occurred.
>   Should it fire missed events?  Should it recompute the offset for future
> events? what if the scale of the shift is large? What if the scale of the
> shift is tiny?  What if time shifts occur frequently? What if they are
> noisy, crossing and recrossing the same point in time?  We quickly get into
> pathological behaviors that either need to be accounted or ignored.
>
> Most developers who have cracked open this nut have eventually decided to
> leave well enough alone and have their system trust that the OS knows what
> time it is and that the admin had a "good reason" for mucking with the
> system time and leave it at that.   Trying to correct for bad admin
> behavior is better done at the social layer than at the technical one.
>
> Just my thoughts.
> chris