Date: Thu, 03 Dec 2020 15:00:58 -0700 From: Ian Lepore <ian@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: <c57736b17fee6885913f40fc0c3e00d358341363.camel@freebsd.org> In-Reply-To: <25487.1607029223@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2020-12-03 at 21:00 +0000, Poul-Henning Kamp wrote: > -------- > Ian Lepore writes: > > On Thu, 2020-12-03 at 07:58 +0000, Poul-Henning Kamp wrote: > > We run freebsd on hardware whose timecounter clock is fed from a > > gps- > > disciplined oscillator and the hardware in the SOC implementing > > that > > clock can capture the counter on an edge of an incoming PPS (which > > is > > generated from the same disciplined oscillator), so we can get > > fairly > > accurate phase measurements. > > > > But I can't set the time with anything like the same accuracy. > > Wrong. > > You can set time with nanosecond precision, even pretty quickly, > but you cannot *step* it with nano-second precision. > > (This last is an universal truth: The code to do the load+add+store > takes instructions on the order of several nanoseconds, and try as > you might, you cannot calibrate that offset to sub-nanosecond > uncertainty on contemporary hardware. This is why there is no > escaping fiddling with minute frequency adjustments and measurements > over a period of time, if you want your clock to be precise at the > ~sub-20 nanosecond level.) > > MOD_OFFSET will precisly slew the clock a given offset over a period > of time, in an exponential-decay manner, taking pains to ensure > time never stops og goes backwards. > > The "no-step-no-stop" policy was a very deliberate design decision > by Dave Mills, and not one he was ever willing to compromise on. > > His argument was that while forward steps are generally not too > troublesome, time should never *ever* go backwards, *and* that > postive and negative offsets should be handled identically. > > On a purely philosophical basis, that argument is unassailable, > but we have all tried CMOS RTC's giving us bogus time. > > Both the "initial step" code in ntpd(8) and the ntpdate(8) program > exists as workarounds around Daves veto, to cope with bad CMOS > time. > > Fortunately time-steps are a lot less poisonous these days, because > people have discovered CLOCK_MONOTONIC, but "no-step-no-stop" is > fundamentally still the right way to go. > > Anyway, the "ADJ_SETOFFSET" is a hackish bolt-on, starting with the > fact that the "ADJ_" prefix is totally out of family for > <sys/timex.h>, > and any interaction with the rest of the PLL is unspecified. > > That is why I'm not too entusiastic about adopting it. > > A more correct integration in the kernel-pll would be to have a > modifier flag for MOD_OFFSET which indicates that a step is desired, > and document that it zeros the PLL as part of the operation. > > But as mentioned above, no matter what, the precision is probably > limited to around 25 nanoseconds, possibly more depending on locking, > and while that may be good enough for your specific case, it is > a blemish on the otherwise very stringent about precision PLL code. > > As usual, all those arguments make good sense in a pristine academic world, and no sense at all in a venue such as an embedded-system timekeeping product that doesn't even run ntpd and doesn't care in the slightest about stepping the time at startup (indeed, has no option but to step the time since there is no cmos or other clock to keep time during power-off, and even you have to admit that carefully slewing the time forward from 1/1/70 to the present in tiny increments is a bit impractical). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c57736b17fee6885913f40fc0c3e00d358341363.camel>