Re: NTP, UTC, and (negative) leap seconds

2020-11-19 Thread Ian Lepore
On Thu, 2020-11-19 at 19:50 -0500, David Magda wrote:
> Hello,
> 
> So there was a recent weblog post on a timekeeping observation:
> 
>   https://fanf.dreamwidth.org/133823.html
>   https://news.ycombinator.com/item?id=251458700  (via)
>   https://en.wikipedia.org/wiki/Leap_second
> 
> In all circumstances in the past, leap seconds were added:
> 
>   23:59:57Z
>   23:59:58
>   23:59:59
>   23:59:60
>   00:00:00
>   00:00:01
> 
> The post brings up the possibility of a “negative” leap second, i.e.,
> a skip:
> 
>   23:59:57Z
>   23:59:58
>   00:00:00
>   00:00:01
> 
> Has anyone tested this scenario on FreeBSD?
> 
> Thanks for any info.
> 
> 

I run the freebsd kernel and ntpd through "negative" leap second events
usually a couple times a year as part of testing our timekeeping
products at $work.  I'm skeptical that we'll ever see a negative leap,
but we have some customers who insist on having it demonstrated to them
as working correctly.

The kernel and ntpd handle it just fine.  No telling what any given
application might do in reaction to a skipped second.  

I just did it now on one of our products.  I scheduled a negative leap
(from offset 37 to 36) to happen at the end of the day 2020-12-31, then
I used a debugging command to manually force the date/time on the unit
to 2020-12-31-23:58:00 and let it run.  In a terminal window I had a
bourne shell on that unit running 

  while true; do sleep 1; ntptime; echo; done

The output (trimmed to the range 23:59:55 - 00:00:10) looks like:

ntp_gettime() returns code 2 (DEL)
  time e398e47b.82ebd4d0  Thu, Dec 31 2020 23:59:55.511, (.511411404),
  maximum error 4000 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.976 us, frequency 29.182 ppm, interval 128 s,
  maximum error 4000 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 0.937 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 2 (DEL)
  time e398e47c.8d714b9c  Thu, Dec 31 2020 23:59:56.552, (.552510729),
  maximum error 4500 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.957 us, frequency 29.182 ppm, interval 128 s,
  maximum error 4500 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 0.988 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 2 (DEL)
  time e398e47d.92dbb5a0  Thu, Dec 31 2020 23:59:57.573, (.573665426),
  maximum error 5000 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.937 us, frequency 29.182 ppm, interval 128 s,
  maximum error 5000 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 0.855 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 2 (DEL)
  time e398e47e.9878316c  Thu, Dec 31 2020 23:59:58.595, (.595584418),
  maximum error 5500 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.918 us, frequency 29.182 ppm, interval 128 s,
  maximum error 5500 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 1.006 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 4 (WAIT)
  time e398e480.9dd6cf84  Fri, Jan  1 2021  0:00:00.616, (.616559624),
  maximum error 6000 us, estimated error 5 us, TAI offset 36
ntp_adjtime() returns code 4 (WAIT)
  modes 0x0 (),
  offset 4.899 us, frequency 29.182 ppm, interval 128 s,
  maximum error 6000 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 1.010 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 4 (WAIT)
  time e398e481.a323571c  Fri, Jan  1 2021  0:00:01.637, (.637258156),
  maximum error 6500 us, estimated error 5 us, TAI offset 36
ntp_adjtime() returns code 4 (WAIT)
  modes 0x0 (),
  offset 4.880 us, frequency 29.182 ppm, interval 128 s,
  maximum error 6500 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 1.025 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 4 (WAIT)
  time e398e482.a8977424  Fri, Jan  1 2021  0:00:02.658, (

NTP, UTC, and (negative) leap seconds

2020-11-19 Thread David Magda
Hello,

So there was a recent weblog post on a timekeeping observation:

https://fanf.dreamwidth.org/133823.html
https://news.ycombinator.com/item?id=25145870  (via)
https://en.wikipedia.org/wiki/Leap_second

In all circumstances in the past, leap seconds were added:

23:59:57Z
23:59:58
23:59:59
23:59:60
00:00:00
00:00:01

The post brings up the possibility of a “negative” leap second, i.e., a skip:

23:59:57Z
23:59:58
00:00:00
00:00:01

Has anyone tested this scenario on FreeBSD?

Thanks for any info.

--
David Magda
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"