lkml.org 
[lkml]   [2011]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 0/2] ABI for clock_gettime_ns
From
Date
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




\
 
 \ /
  Last update: 2011-12-14 17:51    [W:0.071 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site