Date: Thu, 03 Dec 2020 09:31:10 -0700 From: Ian Lepore <ian@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Cy Schubert <Cy.Schubert@cschubert.com> Cc: freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> In-Reply-To: <4086.1606982335@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2020-12-03 at 07:58 +0000, Poul-Henning Kamp wrote: > -------- > Cy Schubert writes: > > > 1. A new syscall, similar to clock_settime() and clock_gettime() > > that > > adds/subtracts the delta, in a struct timespec, via a call to > > kern_clock_settime(). Then atomically returns the current time as > > if > > clock_gettime() was immediately called. > > Did they say why they need this and why simply setting the clock is > not > good enough ? > > What program uses this ? > I have been very much wanting this feature for years, so much so that I've come close to hacking it in myself and just carrying it as local patches to the kernel at $work. 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. After a clock_settime() call I'm still off by anything from hundreds of microseconds to milliseconds and have to wait for that error to be tediously steered out over the course of many minutes. Once kernel time is phase-aligned, it never needs to be steered again. It has always bugged me that any steering is needed at all, it should be possible to set the phase once and be perfectly on-time from that point forward. (Perfect meaning within the measurement capabilities of the hardware, typically within about 150ns, which is certainly good enough for ntp and most PTP applications.) I'm relatively agnostic about how the ability to offset the clock is implemented, a new syscall works fine for me. 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? -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5e0db735b29f1ece02521871b2cd392c3467101d.camel>