[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C9BC620.3@riesch.at>
Date: Thu, 23 Sep 2010 23:26:56 +0200
From: Christian Riesch <christian@...sch.at>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: Christoph Lameter <cl@...ux.com>,
Richard Cochran <richardcochran@...il.com>,
linux-kernel@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
linux-api@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, netdev@...r.kernel.org,
Arnd Bergmann <arnd@...db.de>,
David Miller <davem@...emloft.net>,
John Stultz <johnstul@...ibm.com>,
Krzysztof Halasa <khc@...waw.pl>,
Peter Zijlstra <peterz@...radead.org>,
Rodolfo Giometti <giometti@...ux.it>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the
MPC85xx.
Alan Cox wrote:
>> Please do not introduce useless additional layers for clock sync. Load
>> these ptp clocks like the other regular clock modules and make them sync
>> system time like any other clock.
>
> I don't think you understand PTP. PTP has masters, a system can need to
> be honouring multiple conflicting masters at once.
AFAIK the master's should not be conflicting. The Best Master Clock
algorithm (BMC) defined in IEEE1588 selects the best master clock. This
clock distributes its notion of time on the network while the other
masters, that is the other clocks/nodes that are configured to
potentially become a master, keep quiet. So usually we will only have
one source of time (the master clock selected by the BMC) and we will
steer our single PHC (PTP hardware clock) to follow this master (Of
course there may be use-cases that require more than one PTP clock,
e.g., for research purposes).
However, if the clock selected by the BMC is switched off, loses its
network connection..., the second best clock is selected by the BMC and
becomes master. This clock may be less accurate and thus our slave clock
has to switch from one notion of time to another. Is that the conflict
you mentioned?
Christian
--
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