On Thu, May 28, 2015 at 08:24:59AM +0200, Miroslav Lichvar wrote: > On Wed, May 27, 2015 at 07:37:39PM +0200, Richard Cochran wrote: > > On Wed, May 27, 2015 at 03:05:14PM +0200, Miroslav Lichvar wrote: > > > Is it not possible that the offset will change when there is some > > > restart or reconfiguration in the PTP network? > > > > Yes, but any phase offset that suddenly appears is fixed by a jump. > > Is that always preferred over slew?
I wouldn't say "always", because you never know what people want. Maybe it wouldn't hurt to allow the frequency adjustment in some cases. But then, the user can just not set this option. > Ok, but adjusting frequency to correct a phase offset is still > fine, right? To be honest, I didn't even try that with my hardware setup. I went on the assumption that the frequency is already locked, and any adjustment can only be a mistake. > Hm, so the offset normally stays at zero or is it stepping on each > update? It always stays zero. Non-zero offsets only appear in error conditions, like resetting the GM's time or breaking the SyncE chain. > If there is no noise in the measurements, then one step on start and no > more clock updates would make sense. That is basically what I really want to do, but without rewriting ptp4l. > If there is some noise I think it would > be still useful to let the servos adjust the frequency similarly to a > case with a stabilized clock (e.g. OCXO), which has a fixed but > non-zero frequency offset. > > In seems odd to me to call the servo function and then ignore its > result. In general this breaks the internal state of the servo since > the assumption is that it is always controlling the clock. But a new servo type would make sense to you? Thanks, Richard ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
