[LEAPSECS] Time math libraries, UTC to TAI

[Martin Burnicki]

Zefram wrote:
> Martin Burnicki wrote:
>> Of course it would be great if there was an API call which executes fast
>> to yield a high performance, and returns a timestamp plus an associated
>> status code consistently, in an atomic operation.
> 
> A read-only adjtimex() does return all of this information, at least on
> systems where struct timex includes the current time.  (Where it doesn't,
> there's no atomic way to get this information.)  Obviously it's more
> expensive than a mere clock_gettime(), but by how much?  One would think
> that just reading the state would be relatively cheap; nothing needs to
> be recomputed.

Agreed. However, I think the blocking mechanisms required to implement
this atomically may require lots of the execution time.

I have never tested how long the calls take to execute, and which
latencies can arise if you either of these functions in the middle of a
status update or so.

Also I'm not too familiar with the way clock_gettime() has been
implemented, but if I remember correctly it uses some tricks to make
access also from user space it really fast.

Today there are many users today which require a high number of request
per second to be serviced, with very high accuracy and resolution, so
that there are also hardware implementations of the NTP service.

Software implementations like ntpd also try to use SO_TIMESTAMP and
friends to eliminate the processing time in the network stack, etc. If
adjtimex() should be used by ntpd to get raw kernel time then either
SO_TIMESTAMP implementations also had to support this (eventually
alternatively, using a new SO_TIMESTAMP_XX code), or the SO_TIMESTAMP
feature could not be used to reduce latency, which resulted in increased
time error and jitter.

BTW, all of this not only applies to ntpd and friends, but also to PTP
daemon implementations.

> I think the "timestamp plus associated status code" call that should
> exist is actually clock_gettime(CLOCK_UTC).  Once that exists, I'm
> dubious about the utility of any proposed syscall that would just return
> a subset of struct timex.  The whole structure is quite useful for clock
> readers because it lets one construct an uncertainty bound, which is
> not available through any of the purpose-specific clock reading syscalls.

Agreed, by see my thoughts above regarding SO_TIMESTAMP.

Martin