[Linuxptp-devel] phc2sys timestamp filtering

[Urs Ritzmann]

Hi

I had to add an extension to the phc2sys tool and would like to ask about your opinion about chances to get it upstream.

It's about running the phc2sys tool in the opposite direction, sys2phc, but with a more smooth servo.

This is my Use Case: Relative (device to device) time accuracy is important but absolute world-time only needs to match roughly (couple of milliseconds). Therefore, people always wanted to run NTP on the PTP Grandmaster and use NTP as a reference for world-time. This way, they can safe an expensive time server or GPS reference.

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.

What's your opinion. Is it worth sending patches?

BR
Urs

[Richard Cochran]

Post by Urs Ritzmann
What's your opinion. Is it worth sending patches?

Yes, this is a use case that would interest many people, I should
think.

Thanks,
Richard

[Keller, Jacob E]

-----Original Message-----
Sent: Tuesday, February 14, 2017 10:05 AM
Subject: Re: [Linuxptp-devel] phc2sys timestamp filtering

Post by Urs Ritzmann
What's your opinion. Is it worth sending patches?

Yes, this is a use case that would interest many people, I should
think.
Thanks,
Richard

I agree, the use case seems interesting. The best way to discuss implementation is over actual code.

Thanks,
Jake

[Miroslav Lichvar]

Post by Urs Ritzmann
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.
- 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.

[Richard Cochran]

Post by Miroslav Lichvar
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.

Yes, I was wondering this as well. If you have some test results that
show the advantage of your new approach, then it would be interesting
for us if you would share your data.

Post by Miroslav Lichvar
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.

Thanks,
Richard

[Urs Ritzmann]

Hi

Thanks for the response.

Post by Miroslav Lichvar
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

Post by Miroslav Lichvar
-----Original Message-----
Sent: Mittwoch, 15. Februar 2017 10:34
To: Ritzmann Urs
Subject: Re: [Linuxptp-devel] phc2sys timestamp filtering

Post by Urs Ritzmann
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.

Post by Urs Ritzmann
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

Post by Urs Ritzmann
- 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).

Post by Urs Ritzmann
- 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

[Richard Cochran]

Post by Urs Ritzmann
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.

But ntpd avoids sudden system clock adjustments, doesn't it?

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Urs Ritzmann
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.

But ntpd avoids sudden system clock adjustments, doesn't it?

Normally it does, but on start, if the offset is smaller than 128ms, it
doesn't step the clock and depending on the time constant it may
take hours to correct and stabilize. With the lastest ntpd version
(4.2.8), it's faster. Running ntpdate before ntpd may help.

[Emilio Marín López]

Hello Miroslav and Richard,

Thank you very much for your discussion and clarifications.

We are trying to make one of our devices PTP compatible so we are
thinking in using your linuxptp. The problem is that we need the telecom
profile (ITU G.8265.1) and that specific profile uses unicast traffic.
That was the reason why I asked about the unicast traffic.

Regards,

Emilio.

Post by Miroslav Lichvar

Post by Richard Cochran

Post by Urs Ritzmann
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.

But ntpd avoids sudden system clock adjustments, doesn't it?

Normally it does, but on start, if the offset is smaller than 128ms, it
doesn't step the clock and depending on the time constant it may
take hours to correct and stabilize. With the lastest ntpd version
(4.2.8), it's faster. Running ntpdate before ntpd may help.

[Richard Cochran]

We are trying to make one of our devices PTP compatible so we are thinking
in using your linuxptp. The problem is that we need the telecom profile (ITU
G.8265.1) and that specific profile uses unicast traffic. That was the
reason why I asked about the unicast traffic.

Take a look at ptpd. IIRC, they added unicast telecom profile support
recently.

Cheers,
Richard