From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757086Ab0EKAhy (ORCPT ); Mon, 10 May 2010 20:37:54 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:60069 "EHLO e39.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754496Ab0EKAhw (ORCPT ); Mon, 10 May 2010 20:37:52 -0400 Subject: Re: [RFC][PATCH 3/3] Try to convert non-trivial clocksources to clocksource_register_hz From: john stultz To: Jim Cromie , Darryl Veitch , Julien Ridoux Cc: lkml , Ralf Baechle , Martin Schwidefsky , Benjamin Herrenschmidt , Paul Mundt , Thomas Gleixner In-Reply-To: References: <1272677785-23881-1-git-send-email-johnstul@us.ibm.com> <1272677785-23881-2-git-send-email-johnstul@us.ibm.com> <1272677785-23881-3-git-send-email-johnstul@us.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 10 May 2010 17:37:41 -0700 Message-ID: <1273538261.3843.99.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2010-05-10 at 17:33 -0400, Jim Cromie wrote: > > > 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