Date: Thu, 03 Dec 2020 14:03:31 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Ian Lepore <ian@freebsd.org>, Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: <202012032203.0B3M3VJx004269@slippy.cwsent.com> 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
In message <25487.1607029223@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > -------- > 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. Yes. The initial proposal was for a uniquely new syscall that simply added and subtracted. But that quickly became a discussion about adjtimex(). Looking at the Linux code a few days ago it became apparent that adjtimex() was a hack. ADJ_TICK is another hack similar to MOD_FREQUENCY, which is called ADJ_FREQUENCY in adjtimex. ADJ_TICK is handled by ADJ_FREQUENCY (which is synonymous to MOD_FREQUENCY). ADJ_TICK looks broken. The Linux sys/timex.h equates the ADJ_* to MOD_* except for ADJ_SETOFFSET and ADJ_TICK, which aren't supported by ntp_adjtime(). > > That is why I'm not too entusiastic about adopting it. Neither am I, which is why I raised the issue here. They felt the need for it. Having discussion here gives me more gravitas to speak for the Project. Having said that, I'd roll up my sleeves to implement what we decided here. > > 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. > > > > I notice a struct timeval was mentioned, but hopefully that's in a > > context where MOD_NANO/STA_NANO apply and tv_usec will actually convey > > nanos? > > Yes, when the _NANO flag is set, the timeval is a timespec > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. The take away from this discussion is that we are not interested in implementing the Linux adjtimex() here. Which I agree with. I will go back with my initial proposal of a timespec add/subtract syscall takes a timespec as input increments or decrements the clock by the timespec and returns a timespec with the time. That enables the ntp developers to add or subtract time and compare it with what ntp thinks it should be. Their idea is to have a loop feeding deltas to the syscall and comparing the output with their expectation. This is certainly less disruptive and IMO more maintainable than their desired solution. I have had code for the other more simpler separate new syscall option in my git repo for about a week. This was rejected because the desire was for FreeBSD to implement adjtimex(). I could submit the simpler separate unrelated to ntp_adjtime() syscall as a phabricator review or post it here if people prefer that instead. The code hasn't been tested. IMO the important consideration isn't Linux compatibility but being atomic (reduction of syscalls from two to one). Once through the review process I can take it back to the nwtime folks. I'm sure they'd be happier with this over nothing. Thoughts? -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202012032203.0B3M3VJx004269>