[Linuxptp-devel] An update to or a new PI(D) servo?

[Nico Augustijn]

Hello people,

We've been using ptp4l (1.6) here to synchronize a Xilinx MicroBlaze (soft core) processor to a PTP master and have had some excellent results; once we have a stable lock on the master, the maximum time jitter is only about 20 nanoseconds. And that was with only a simple and cheap 1 Gb switch.
Last week, we've upgraded the RTL of the board to use a 10 Gb MAC and found that it introduced a fair amount of jitter on the PPS of the system compared with 1Gb.
We believe this could be mitigated by introducing a second, "slower", set of PI parameters that would kick in when your locking distance becomes within a certain amount of ns (say about 70 ns, but should be configurable).

This would require either an update to the current PI servo or the introduction of a new, adaptive PI(D) servo.

I'm capable enough to write the code myself (whether my manager allows me to spend the time for it is another matter) but Richard suggested I post this to the list first to get some additional input.

Regards,

Nico.

[Miroslav Lichvar]

Post by Nico Augustijn
Last week, we've upgraded the RTL of the board to use a 10 Gb MAC and found that it introduced a fair amount of jitter on the PPS of the system compared with 1Gb.
We believe this could be mitigated by introducing a second, "slower", set of PI parameters that would kick in when your locking distance becomes within a certain amount of ns (say about 70 ns, but should be configurable).

Automatic switching between different sets of PI parameters could be
useful and there have been some proposals to do that, but it's not
clear to me how exactly you want to select the best set of parameters.

If you know the second set of PI parameters performs better, why not
use them right from the start? If this is about faster convergence,
maybe it would be better to add the derivative term to the current
servo?

Also, linuxptp already has an adaptive servo, linreg. Have you tried
it?

[Nico Augustijn]

Hi people, I've been out for a while due to a bad flue and now I'm picking where I left off so...

The selection of the parameters would be based on the "perceived locking distance". This could be a user-settable threshold. For instance, in our particular situation we'd want to switch to much "slower" parameters when we're within about 100 - 200 ns of lock to reduce jitter. The reason we use more aggressive PI values at first is that we need to be within 1 microsecond of lock distance within 5 seconds of starting the BMCA. This is a requirement of the SMPTE205g spec that we cannot change.

The colleague who selected the PI servo and determined optimum parameters tells me the linreg servo performance was not as good as the tuned PI servo.

I am not sure what you mean with "maybe it would be better to add the derivative term to the current servo". Could you expand a bit on that?

Regards,

Nico.

-----Original Message-----
From: Miroslav Lichvar [mailto:***@redhat.com]
Sent: dinsdag 29 maart 2016 15:54
To: Nico Augustijn <***@Adeas.nl>
Cc: linuxptp-***@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] An update to or a new PI(D) servo?

Post by Nico Augustijn
Last week, we've upgraded the RTL of the board to use a 10 Gb MAC and found that it introduced a fair amount of jitter on the PPS of the system compared with 1Gb.
We believe this could be mitigated by introducing a second, "slower", set of PI parameters that would kick in when your locking distance becomes within a certain amount of ns (say about 70 ns, but should be configurable).

Automatic switching between different sets of PI parameters could be useful and there have been some proposals to do that, but it's not clear to me how exactly you want to select the best set of parameters.

If you know the second set of PI parameters performs better, why not use them right from the start? If this is about faster convergence, maybe it would be better to add the derivative term to the current servo?

Also, linuxptp already has an adaptive servo, linreg. Have you tried it?

--
Miroslav Lichvar

------------------------------------------------------------------------------

[Miroslav Lichvar]

Post by Nico Augustijn
The selection of the parameters would be based on the "perceived locking distance". This could be a user-settable threshold. For instance, in our particular situation we'd want to switch to much "slower" parameters when we're within about 100 - 200 ns of lock to reduce jitter. The reason we use more aggressive PI values at first is that we need to be within 1 microsecond of lock distance within 5 seconds of starting the BMCA. This is a requirement of the SMPTE205g spec that we cannot change.

Ok, that makes sense. I'd suggest to implement this as a new
"multi-stage" PI servo, independently from the PI servo that linuxptp
currently has as it will probably require a carefully configuration to
get good results and prevent thrashing between the two sets of
constants, etc. An extra set of PI constants and a threshold wouldn't
fit the configuration of the current PI servo very well.

Post by Nico Augustijn
The colleague who selected the PI servo and determined optimum parameters tells me the linreg servo performance was not as good as the tuned PI servo.

What constants the tuned PI servo used and what difference in the
performance did you see?

Post by Nico Augustijn
I am not sure what you mean with "maybe it would be better to add the derivative term to the current servo". Could you expand a bit on that?

If the servo had a derivative term, I think it could converge faster
as it would predict the future offset. I'm not sure if it would be as
fast as the multi-stage servo you propose. In any case, extending the
configuration of the current PI servo with a D term would be
difficult.