Re: [chrony-dev] Leap second handling

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

 Actually, and developed by Mills, the behaviour of the system clock is
supposed to be that during the forward leap second (insertion of a second)
what is supposed to happen is that teh system clock stops for a second, (It
does not gobackward) but every time the sysem clock is queried, it is supposed
to give a time slightly later than the previous reading. Thus lets say you
query the clock 3 times a second. You would get
23:59.59.0
23:59:59.333333
23:59.59.666666
0:0:0.000000
0:0:0.000001
0:0:0.000002
0:0:0:000003
0:0:0:333333
0:0:0:666666
0:0:1:000000
so the clock never goes backwards. For a lost second, the reading ofthe clock
during th 58th second and the 0 sec goes twice as fast
57:666666
58.000000
58.666666
59.333333
0.000000
0.333333

The clock in all cases is read exactly 1/3 of a second as determined by TAI
time.

That is what is supposed to happen. clearly on some systems there were
problems. I saw none. But then I was not looking closely.


On Wed, 11 Jul 2012, Frank Muzzulini wrote:

> On 07/10/12 23:49, Bill Unruh wrote:
> >  On Tue, 10 Jul 2012, Frank Muzzulini wrote:
> >
> > >  Hello,
> > > 
> > >  sadly I was not able to observe the leap second in June and I also
> > >  found that the online documentation gives little information about how
> > >  chrony handles a leap second. I guess it forwards the information to
> > >  the kernel, doesn't it?
> > > 
> > >  You may have heard about the the problems some linux systems had and
> > >  the solution implemented by Google. (If you haven't, look at
> > >  http://www.h-online.com/open/news/item/Leap-second-Linux-can-freeze-1629805.html).
> > >  I wonder if chrony could add something like that as an option, too.
> > > 
> > >  Alternatively I can also imagine a simpler way: Pass the leap second
> > >  announcement to clients as usual and locally adapt the time as if it
> > >  were an error of one second, encountered at 0:00 UTC. If clients use
> > >  the same setting, it will work neatly for all anyway.
> >
> >  Well, my version of chrony seems to have handled it without any problem.
> >  If
> >  you look at www.theory.physics.ubc.ca/chrony youwill see no evidence of
> >  any
> >  problem .
>
> I am not speaking about a problem of chrony, I want chrony to be a solution 
> to other problems. Let me express this more clearly.
>
> There are actually two problems:
>
> 1. The general one: The posix interface to get the system time (gettimeofday 
> or clock_gettime(CLOCK_REALTIME) does not forsee any representation of leap 
> seconds. In practice, at least in Linux, from the application point of view a 
> leap second looks like a back step of one second.
>
> 2. The specific one: Some linux kernels have chance to consume endless CPU 
> after passing a leap second.
>
> I am sure the linux bug will be fixed by the time of the next leap second, 
> although some old kernels might still be around and new bugs might come up. 
> The general problem will remain.
>
> Btw: I have no permission to look at your server, but I found that one of our 
> test machines was running chrony during the leap second and so I could see 
> that it passes the information to the kernel as expected.

--
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.