Re: [Linuxptp-devel] Optimal P, I constants

[Miroslav L. <mli...@re...>]

On Tue, Apr 23, 2013 at 06:42:10PM +0000, Keller, Jacob E wrote:
> I think it might be better (at first) to create a new clock which is based on Allan intercept, since most people doing PTP are familiar enough with the P/I constants servo.

I think the options to set P, I directly could be still used, the new
option would be effective only if the configured P or I was zero, or
the new option was non-zero.

> I do think in the long term it definitely makes more sense to put the Allan intercept, as that appears to work better, and is easier to measure if I am not mistaken? (Jitter * wander in pbb, right?)

The Allan intercept is approximately
(jitter / wander_per_second)^(2/3) * 2

The deviation can be calculated from offsets reported by phc2sys (or
ptp4l) when free running and the intercept can be estimated from the
plot. A tool I use is at https://github.com/mlichvar/ppsallan.

With phc2sys it can be used like this:
phc2sys -P 1e-50 -I 1e-50 -m | tail -n +10 > log
awk '{ printf "%.9f\n", $4 * 1e-9 }' < log | ppsallan -B > adev
plotallan adev

The offsets should be collected at one second interval, or the result
needs to be scaled accordingly. To see the +1/2 slope well, it's
good to have at least 10 hours or more of data.

> Wouldn't this also have to set the update frequency as well? It appears that some update frequencies cause the result to be unstable or too slow..

Yes, the update interval would need to be included in the P, I
calculation. I think that's the main problem with the current code,
that the sync interval can change to a longer one in the runtime, but
P, I don't change and the servo may suddenly be unstable.

Ideally, the constants would be adjusted automatically according to
the current conditions. Or try a more sophisticated servo. I have some
ideas I want to explore, but it's not on my short-term todo list.

Thanks,

-- 
Miroslav Lichvar