lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 May 2010 17:37:41 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Jim Cromie <jim.cromie@...il.com>,
	Darryl Veitch <dveitch@...melb.edu.au>,
	Julien Ridoux <jridoux@...melb.edu.au>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 3/3] Try to convert non-trivial clocksources to
 clocksource_register_hz

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ