Messages in this thread | | | Subject | Re: [RFC 0/2] ABI for clock_gettime_ns | From | john stultz <> | Date | Wed, 14 Dec 2011 08:48:30 -0800 |
| |
On Wed, 2011-12-14 at 08:46 +0100, Richard Cochran wrote: > On Mon, Dec 12, 2011 at 11:09:29PM -0800, Andy Lutomirski wrote: > > On Mon, Dec 12, 2011 at 7:43 PM, john stultz <johnstul@us.ibm.com> wrote: > > >> - New name, to distance ourselves from POSIX (clock_ns_get?) > > > > I will defer to the bikeshedding consensus :) > > > > >> - Family of calls, with set/get > > > > Setting the time is a big can of worms. adjtimex is rather > > incomprehensible (without reading lots of source and/or the rfc) and > > IMO puts a lot of NTP magic into the kernel, where it doesn't belong.
Honestly, I don't really see how we jumped to adjtimex from setting the time, nor the complexity hinted at. First, the rational for getting clock_gettime_ns is to avoid the overhead of userland translating from timespec to ns. I doubt there are similar performance needs for settimeofday(). Even if it was needed, it shouldn't be more complex then the unit conversion done in this abi patch. Am I missing something?
> > That being said, it might be nice to do something about leap seconds. > > I always thought that the nanosecond count should include every > > possible leap second so that every time that actually happens > > corresponds to a unique count, but maybe that's just me. > > The advantage of working with TAI is that you can use simple addition > and substraction (converting the result to UTC or whatever), and the > answer is always correct.
But again, the hard part with in-kernel TAI (possibly as the base of time)is that initialization of the TAI/UTC offset needs to be able to be phased in slowly, as we also have to preserve legacy interfaces and behavior.
> > >> - Sub nanosecond field > > > > Me. A nanosecond is approximately a light-second. Other than things > > local to a single computer, not much of interest happens on a > > sub-nanosecond time scale. Also, a single 64-bit count is nice, and > > 2^64 picoseconds isn't very long. > > Believe it or not, people (from the Test and Measurement field) have > already been asking me about having subnanosecond time values from the > kernel. > > What about this sort of time value? > > struct sys_timeval { > __s64 nanoseconds; > __u32 fractional_ns; > }; > > The second field can just be zero, for now.
I'm mixed on this.
We could do this, as the kernel keeps track of sub-ns granularity. However, its not stored in a decimal format. So I worry the extra math needed to convert it to something usable might add extra overhead, removing the gain of the proposed clock_gettime_ns() interface.
> > >> - TAI time base (or according to parameter?) > > > > > > Having a CLOCK_TAI would be interesting across the board. We already > > > keep a TAI offset in the ntp code. However, I'm not sure if ntp actually > > > sets it these days. > > > > A friend of mine would probably appreciate various barycentric time > > scales as well. This would also be a different (and unrelated) patch. > > What about this: a new, non-POSIX, rational time interface providing > TAI time values, and a user space library for time scale conversion?
Why do we need a new interface for TAI? clock_gettime(CLOCK_TAI,...) should be achievable. I do think it would be interesting, but I also think its separate from the goal of this proposal.
thanks -john
| |