[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100827134154.50eef56c@lxorguk.ukuu.org.uk>
Date: Fri, 27 Aug 2010 13:41:54 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Richard Cochran <richardcochran@...il.com>
Cc: john stultz <johnstul@...ibm.com>,
Christian Riesch <christian.riesch@...cron.at>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, devicetree-discuss@...ts.ozlabs.org,
linux-arm-kernel@...ts.infradead.org,
Krzysztof Halasa <khc@...waw.pl>,
Rodolfo Giometti <giometti@...ux.it>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
> The master node in a PTP network probably takes its time from a
> precise external time source, like GPS. The GPS provides a 1 PPS
> directly to the PTP clock hardware, which latches the PTP hardware
> clock time on the PPS edge. This provides one sample as input to a
> clock servo (in the PTPd) that, in turn, regulates the PTP clock
> hardware.
A PTP clock is TAI, Unix time is UTC.
> This is the core issue and source of misunderstanding, in my view. The
> fact of the matter is, the current generation of computers has
> multiple clocks, and these are usually unsynchronized. I think we
> should not try too hard to cover up or work around this. It is a fact
> of life.
In this case I don't think you can. Their divergence is rather difficult
to handle unless you have a GPS to hand.
But all this talk of "PTP this" and "PTP that" is not helpful. Any
interface for additional time sources should be generic with PTP being
one use case.
Alan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists