Hi
Thanks for the response.
> Have you tried constants like -P 1e-4 -I 1e-8? If the system clock is
> accurate and stable to a millisecond, this should keep the PHC
> accurate to few milliseconds and stable to hundreds of nanoseconds,
> assuming the PHC is in a reasonably stable temperature.
You are right, such a slow servo already filters a lot, so my following PTP
setup was stable and accurate. My basic concern with such a servo was, that it
takes ages to compensate an initial frequency offset of the PHC. I've got
"older" hardware with PHC with +- 150ppm initial error. With Kp=1e-4 and
Ki=Kp^2=1e-8, I get an offset between SYS-PHC of 0.8s during the first 20000
seconds. See attached image1.png. This initial transient caused by the 150ppm
PHC offset is many hours long and creates that SYS-PHC offset of 0.8s. Although
relative PTP accuracy seems stable during this time, 0.8s SYS-PHC offset is a
bit big. A couple milliseconds would be better.
The current PI-Servo implementation includes a state machine where drift/offset
is first measured, and then the integral part is initialized accordingly. This
removes the long transient described above, and therefore my problem with the
0.8s offset are removed. But I was still concerned that we could get such a
transient for any reason. Perhaps NTP was not yet ready to tune the system
clock which invalidates that initial measurement. Perhaps I'm just too paranoid
about that initial transient and It would be better to wait for NTP to
stabilize first, then start phc2sys and trust the initial drift measurement.
With a low-pass/exponential smoothing filter (Kp=0.01, tau=10s), I tried to
create a servo with shorter transients but still removing enough
SW-timestamping jitter. With just faster PI-servos, like Kp=1e-3 and
Ki=Kp^2=1e-6 the transient gets into more acceptable range of 80ms PHC-SYS, but
the following PTP sync gets worse during the still long transient phase (see
image3.png). So the low-pass filter is a tradeoff. In case of a transient, it
still made the following PTP worse, but only for minutes instead of hours. The
drawback, without an integral part, a small SYS-PHC offset remains.
The longer I write about a new filter, the more get the impression that it is
only useful for my very specific case. Most people will most likely use a slow
PI as you suggested and make sure the initial drift measurement of the PI-Servo
succeeds, e.g. by starting NTP early.
BR Urs
> -----Original Message-----
> From: Miroslav Lichvar [mailto:[email protected]]
> Sent: Mittwoch, 15. Februar 2017 10:34
> To: Ritzmann Urs
> Cc: '[email protected]'
> Subject: Re: [Linuxptp-devel] phc2sys timestamp filtering
>
> On Tue, Feb 14, 2017 at 04:33:34PM +0000, Urs Ritzmann wrote:
> > I know, moving time from the less accurate, higher jitter NTP domain to the
> > PTP domain is a bad idea in general, but the use case is
> still valid. And it seems to be possible, given a filter with slow enough
> time constant to remove most of the NTP and Software
> timestamping jitter.
> >
> > Currently, I created an additional servo class, which is basically an
> > exponential smoothing / low-pass filter with a gain constant. If you
> think it could be useful for others, I would probably change the code a
> little before sending patches. Instead of the servo class, I think
> this matches the current implementation better:
> >
> > - Use the PI-Servo, but change it to accept zero integral constants,
> > optionally making it a P-Servo. Integral part reduces stability
> margin and is not required if some remaining static error is acceptable
> (which is in my case).
> > - Add an option to phc2sys to enable timestamp filtering (disabled by
> > default).
> > - Use the already existing moving average filter or alternatively add a
> > new exponential smoothing filter class to the filters.
>
> In general this looks interesting, but it's not very clear to me what
> would be the advantage over using the PI servo with smaller constants.
>
> Have you tried constants like -P 1e-4 -I 1e-8? If the system clock is
> accurate and stable to a millisecond, this should keep the PHC
> accurate to few milliseconds and stable to hundreds of nanoseconds,
> assuming the PHC is in a reasonably stable temperature.
>
> --
> Miroslav Lichvar
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
