On Wed, Feb 22, 2012 at 11:35:40PM +0000, Keller, Jacob E wrote:
> I recently had ptp4l running with a symmetricom grandmaster Xli box
> which I am using as an interop test for ptp4l. I noticed something
> odd, when configuring the setup. The grandmaster clock can be in a
> "master only, no slave" mode or a "slave only, no master" mode. When
> in slave only mode, it causes ptp4l to automatically fall back to
> master setup.
>
> The ptp4l state machine then never runs the best master clock
> routine, and so it never sets up the UtcOffset value in the announce
> field. This causes the grand master clock to use the previously
> known utc offset which in this case is 34 seconds. This causes a
> delay of 34 seconds in the clocks. I discovered that the clock
> property fields only get set when in the grand master state, which
> it will *never* enter because it doesn't properly run the best
> master clock algorithm. (Since in this case there is no other
> announcer).
>
> I am not sure what the correct answer to this question should
> be. Under normal circumstances with other ptp4ls, the utc offset is
> ignored. This particular clock, though, cannot have the utc offset
> changed to something outside the -19/-40 range, so I cannot manually
> reset the offset to 0.
>
> Is it correct to not properly configure the ptp4l clock when it is
> in fallback mode, or should it be changed to update the clock
> settings when it goes to master mode as a fallback? Normally the
> clock would go to grandmaster mode because there are no other clocks
> on the network with higher priority.. But it never does this in
> fallback mode, because it never receives an announce message at all.
I think the right thing would be to initialize the time properties in
clock.tds in clock_create(). In that way, if a port enters into master
state by default, the data set values will be correct.
I will add this soon (or please post a patch if you DIY).
Thanks,
Richard
|
