[ntp:questions] LOCL clock reachability not 377?

Miroslav Lichvar mlichvar at redhat.com
Fri Aug 1 10:22:58 UTC 2014


On Thu, Jul 31, 2014 at 10:43:12PM +0000, Rob wrote:
> William Unruh <unruh at invalid.ca> wrote:
> > I think you need to read up on the cmos clock. As I said, it reports
> > only the seconds, but is settable and "readable" to microseconds. 
> 
> The CMOS clock is running off a 32768Hz crystal, so no way it can be
> more accurately set than 30us.
> 
> Even it could be possible in theory to set and read it accurately to
> that value, apparently Linux does not do that.  That makes it questionable
> to me if it can be done.  I could understand when Windows would not
> exploit such a capability, when there is no monetary gain to be made.
> But the Linux developers are too proud and too nerdy to skip such an
> opportunity.

Well, the problem with reading or setting the RTC accurately is that
it takes up to 1 second, for a system call that's unacceptable. It
can't be really compared to the system clock, which can be read in few
tens of nanoseconds, on Linux it usually doesn't even involve a real
system call.

> The fact that there is a microsecond-accurate API to set and read the
> clock does not indicate anything.  Remember Linux can run on any platform,
> and there may be other platforms, now or in the future, that can use
> this accuracy.

The RTC ioctls use only second resolution, AFAIK there is no API that
would allow reading or setting the RTC with better resolution, you
need to do it yourself by timing the ioctl call when setting the clock
and enabling the interrupt when reading the clock. When ntpd is
running, the kernel 11-minute update mode will time the RTC update to
few ticks, that's few milliseconds with a 1000Hz kernel.

-- 
Miroslav Lichvar


More information about the questions mailing list