[time-nuts] help understanding drift in two ptpd-synchronized systems

[Magnus Danielson]

Hi Andrew,

On 2019-11-03 23:28, Andrew Kohlsmith (mailing lists account) wrote:
> Good afternoon, everyone,
>
> 000702615.150663173 (000342239): state=slave: offset=  -107ns drift=1073.417ppm HCLK=216.232MHz (4.325x)
> 000702616.150761324 (000343239): state=slave: offset=   -41ns drift=1073.414ppm HCLK=216.232MHz (4.325x)
> 000702617.150859615 (000344239): state=slave: offset=   -63ns drift=1073.414ppm HCLK=216.232MHz (4.325x)
> 000702618.150957847 (000345239): state=slave: offset=  -176ns drift=1073.408ppm HCLK=216.232MHz (4.325x)
> 000702619.151056198 (000346239): state=slave: offset=  -258ns drift=1073.393ppm HCLK=216.232MHz (4.325x)
>
> I tried playing around with zeroing the drift once I was synchronized, but that just creates a step response in ‘addend’ value the STM32 uses to finely adjust its time, which usually knocks it out of sync, performs a one-time step in the slave time and my drift is back in this 1000-1100ppm range. This tells me that the drift value is correct, but I can’t figure out why.
>
>
> My question is why would the long-term drift stay so high even though the systems *are* synchronized? I know I’m missing something, I just do not know what it is.

"Drift" is most probably phase-drift, i.e. frequency, so you do not
measure it in ns but in fractional form as done already. The
control-loop needs to build up that frequency control value to
compensate for the oscillator frequency offset in order to have it run
at the same rate as the master, and then it can phase-align it. All that
you described is consistent with that, its a concequence of your
oscillator, master reference and a working PLL loop.

Why you have a relative frequency error that large may have many reasons.

Cheers,
Magnus