Re: [Linuxptp-users] Interesting (very wrong) PTP output

[Richard C. <ric...@gm...>]

On Thu, Jun 07, 2012 at 11:54:48AM +0200, Christian Riesch wrote:
> 
> Please find below a patch (it's only an quick hack and only compile-tested)
> that
> a) sets the clock to 0 ppb before doing anything else,
> b) clamps s->drift to the maximum adjustment value at the first calculation
>    (estimation),
> c) applies the estimate to the clock.

Coming back to this patch, I think I now have a better solution to the
issue of starting with a clock that has already been adjusted. I just
pushed out this commit

   8f00d29 Discover and utilize the initial clock frequency adjustment.

that makes use of the clock_adjtimex() to get the initial frequency
adjustment value (functionality to appear in kernel 3.7).

FWIW, I did try out this patch, but I found that, suprisingly, the
code seemed to work better without this patch.  I think the reason
was that the path delay measurements were spoiled by resetting the
frequency adjustment to zero, and the circa 100 ppm error introduced
at the jump was soon corrected.

In any case, using the latest kernel together with this patch works
perfectly, tested using the PHYTER.

Thanks,
Richard