Date: Tue, 05 Feb 2019 13:55:46 -0700 From: Ian Lepore <ian@freebsd.org> To: Eugene Grosbein <eugen@grosbein.net> Cc: FreeBSD <freebsd-stable@freebsd.org> Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:05.kqueue Message-ID: <3954a6fd232be453e8632159892250cb3ae47d08.camel@freebsd.org> In-Reply-To: <dd9b872b-8db5-0580-66ec-87bcf3ea75cd@grosbein.net> References: <20190109194030.DFE3A8CC7@freefall.freebsd.org> <20190205195416.5ddsmc4rf7og4ece@mutt-hbsd> <CAOtMX2gssNeEgvuY=8FDfGF%2B%2BaB2i50tRd=-LdfK0k7eD-_OFg@mail.gmail.com> <faaa6d3e1d48e2fa133be0c7158c78e625eae56a.camel@freebsd.org> <dd9b872b-8db5-0580-66ec-87bcf3ea75cd@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3954a6fd232be453e8632159892250cb3ae47d08.camel>