freebsd stable - Feb 2019 - [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:05.kqueue

06.02.2019 3:18, Ian Lepore wrote:
>> 2019, of course.  re@ does NOT make mistakes.  What you fail to
>> realize is that NIST was using kqueue to check their atomic clock, and
>> they lost the race.  Enjoy the rest of 2020.
>> -Alan
>>
> 
> I think you meant that as a joke, but the reality is that NIST measures
> their atomic clocks using gear that runs FreeBSD (made by the company I
> work for). :)
I do not know if it is related or not: some months ago my FreeBSD 11.2-STABLE
box
having GPS received attached at /dev/cuau0 for my local ntpd stratum 1 server
went to late of 2020 insanely. I was forced to comment GPS out of ntpd config to
revive it
but I lost all data in hundreds of local RRD databases and
I found a race in libarchive being a reason why my backups had not most part of
databases.

I still do not know exact reason and use Internet time source instead of local
GPS.

On Wed, 2019-02-06 at 03:46 +0700, Eugene Grosbein
wrote:
> 06.02.2019 3:18, Ian Lepore wrote:
> 
> > > 2019, of course.  re@ does NOT make mistakes.  What you fail to
> > > realize is that NIST was using kqueue to check their atomic
> > > clock, and
> > > they lost the race.  Enjoy the rest of 2020.
> > > -Alan
> > > 
> > 
> > I think you meant that as a joke, but the reality is that NIST
> > measures
> > their atomic clocks using gear that runs FreeBSD (made by the
> > company I
> > work for). :)
> 
> I do not know if it is related or not: some months ago my FreeBSD
> 11.2-STABLE box
> having GPS received attached at /dev/cuau0 for my local ntpd stratum
> 1 server
> went to late of 2020 insanely. I was forced to comment GPS out of
> ntpd config to revive it
> but I lost all data in hundreds of local RRD databases and
> I found a race in libarchive being a reason why my backups had not
> most part of databases.
> 
> I still do not know exact reason and use Internet time source instead
> of local GPS.
The GPS week number rolls over in April 2019. At $work we have already
been seeing glitches in gps receivers as early as last June that were
caused by errors in the receivers' firmware that didn't handle the
upcoming rollover properly.

When a receiver first powers on, it has no real idea what gps era it's
in (right now we're in the 2nd, about to roll over to the 3rd). It has
to guess, which it mostly does the same way as software does that has
to deal with 2-digit years: make a decision based on the current date
being before/after some cutoff (like > 70 means 2070), and assume
everyone will be running newer firmware before that date arrives.

So your problem was most likely the gps receiver making a bad choice
before it had enough info to make a good choice. It's one of many
reasons why an ntp server should have at least 3 (really, at least 5)
peers, so it can reject obviously-insane data from a single source.
Even when you use a gps to get really accurate local time, you should
have a handful of network peers that can serve as sanity-checkers.

-- Ian