Re: [RFC][PATCH 3/3] Try to convert non-trivial clocksources to clocksource_register_hz

[john stultz <johnstul@us.ibm.com>]

On Mon, 2010-05-10 at 17:33 -0400, Jim Cromie wrote:
> <OT - out of scope in this thread>
> 
> on 5/3, slashdot had a synopsis of this item:
> http://queue.acm.org/detail.cfm?id=1773943
> It proposes a different split of duty between kernel and NTP daemon,
> but oddly doesnt mention PTP.

Yea, I emailed with some the RADclocks folks last year. They have done
quite a bit of very interesting work, but to my knowledge, they haven't
been working with upstream very much to push the patches.

Julien/Darryl: Sorry for dragging you out here, but I was curious if you
had any plans to push your patches to lkml in the near term? From the
patches in the tarball, it looks like you're structurally fairly clean
(and you're using git, so that's good!) so they're probably a good
starting point.

However, I do still have some concerns about the new interfaces that
expose the raw counter values. From your paper (its very nice btw,
congrats!) you mentioned CLOCK_MONOTONIC_RAW as a possible C_c(t) clock,
but from the patches it seems that you found it insufficient? It would
be really interesting to hear more about that, as well as your thoughts
about the dual-system in-kernel and out of kernel NTP adjustment loops. 

I'm curious if the RADclocks calculation of C_a(t) = Cd(t) - E(t) can
actually be done in the kernel, assuming E(t) is provided by userland.
Or is that missing something core to RADclocks design?

> Does this or PTP make any sense in Linux ?

Folks are working on using PTP with Linux. My understanding is that the
interfaces don't really change except for the packet timestamping.
Google up Patrick Ohly's work for some details (although I've not heard
too much on this recently, so I'm not sure how active it is).

thanks
-john