linuxptp-users

Re: [Linuxptp-users] clockcheck - need to filter large spurious phase jumps?

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

On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote:
> We use 16s update interval on our NTP servers that are synced to PTP time
> code using a Spectracom PCIe PTP card, and our system clock jitter is
> around 700 nanoseconds! Frequency changes due to temperature effects are
> not rapid in our environment.  If you run adjtime too frequently you may
> end up chasing your tail.

That seems like a surprisingly good figure. Do you have a way of
verifying it, or is this simply what their software tells you?

Also, does their servo converge rather slowly, like ntp?

Thanks,
Richard

Re: [Linuxptp-users] clockcheck - need to filter large spurious phase jumps?

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

On Wed, Nov 13, 2013 at 09:07:39AM +0100, Richard Cochran wrote:
> On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote:
> > We use 16s update interval on our NTP servers that are synced to PTP time
> > code using a Spectracom PCIe PTP card, and our system clock jitter is
> > around 700 nanoseconds! Frequency changes due to temperature effects are
> > not rapid in our environment.  If you run adjtime too frequently you may
> > end up chasing your tail.
> 
> That seems like a surprisingly good figure. Do you have a way of
> verifying it, or is this simply what their software tells you?

Okay, I take it back. 700 nanoseconds is perfectly reasonable,
provided your kernel isn't using CONFIG_NO_HZ_IDLE.  Once I reboot
using nohz=off then I get very good results using phc2sys.

Thanks,
Richard

Re: [Linuxptp-users] clockcheck - need to filter large spurious phase jumps?

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

On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote:
> We use 16s update interval on our NTP servers that are synced to PTP time
> code using a Spectracom PCIe PTP card, and our system clock jitter is
> around 700 nanoseconds! Frequency changes due to temperature effects are
> not rapid in our environment.  If you run adjtime too frequently you may
> end up chasing your tail.

Regarding Spectracom, you are talking about their TimeKeeper software,
right?

>From the description on their web site it sounds like they are keeping
their own time in user space. They say their product does not require
user space or kernel modifications (but I suppose must require loading
a driver for their card). It is likely that they are intercepting
calls to the C library functions (like gettimeofday) via LD_PRELOAD.

In any case, in order to avoid comparing apples with oranges, I just
what to make it clear that phc2sys is adjusting the Linux system time
via the standard adjtimex system call.

Looking at your nov11-12.txt, it takes about 4.7 microseconds to read
the time from your PCIe card once. That is why the claim of 700 ns
jitter is surprising to me.

Thanks,
Richard

Re: [Linuxptp-users] clockcheck - need to filter large spurious phase jumps?

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

On Wed, Nov 13, 2013 at 09:07:39AM +0100, Richard Cochran wrote:
> On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote:
> > We use 16s update interval on our NTP servers that are synced to PTP time
> > code using a Spectracom PCIe PTP card, and our system clock jitter is
> > around 700 nanoseconds! Frequency changes due to temperature effects are
> > not rapid in our environment.  If you run adjtime too frequently you may
> > end up chasing your tail.
> 
> That seems like a surprisingly good figure. Do you have a way of
> verifying it, or is this simply what their software tells you?

It curious to what exactly "system clock jitter" means. I think
there is a problem with his system clock or reading of the PHC. With a
good system clock, keeping the reported offset below the PHC reading
jitter at 16s interval shouldn't be really a problem.

I tried to run the test with 32s interval on my test machine. When the
CPU is idle:

phc2sys[773832.254]: PI servo: sync interval 32.000 kp 0.022 ki 0.009375
phc2sys[773864.254]: sys offset       -58 s0 freq      +0 delay   4929
phc2sys[773896.254]: sys offset        58 s2 freq  +24472 delay   4921
phc2sys[773928.254]: sys offset       135 s2 freq  +24476 delay   4929
phc2sys[773960.255]: sys offset       170 s2 freq  +24478 delay   4936
phc2sys[773992.255]: sys offset       277 s2 freq  +24483 delay   4951
phc2sys[774024.255]: sys offset       232 s2 freq  +24484 delay   4921
phc2sys[774056.255]: sys offset        19 s2 freq  +24480 delay   4921
phc2sys[774088.255]: sys offset      -244 s2 freq  +24472 delay   4906
phc2sys[774120.255]: sys offset      -298 s2 freq  +24468 delay   4936
phc2sys[774152.255]: sys offset      -115 s2 freq  +24471 delay   4913
phc2sys[774184.256]: sys offset        99 s2 freq  +24476 delay   4928
phc2sys[774216.256]: sys offset       390 s2 freq  +24486 delay   4928
phc2sys[774248.256]: sys offset       399 s2 freq  +24490 delay   4936
phc2sys[774280.256]: sys offset       239 s2 freq  +24489 delay   4943
phc2sys[774312.256]: sys offset      -107 s2 freq  +24480 delay   4921
phc2sys[774344.256]: sys offset      -262 s2 freq  +24475 delay   4943
phc2sys[774376.257]: sys offset      -404 s2 freq  +24468 delay   4951

However, loading the CPU causes a rapid change in the frequency of the
clock and it takes a while to settle down again:

phc2sys[777864.273]: sys offset       229 s2 freq  +24519 delay   4951
phc2sys[777896.273]: sys offset       158 s2 freq  +24519 delay   4913
phc2sys[777928.273]: sys offset       183 s2 freq  +24522 delay   4925
phc2sys[777960.273]: sys offset       255 s2 freq  +24526 delay   4954
phc2sys[777992.273]: sys offset       371 s2 freq  +24532 delay   4929
phc2sys[778024.273]: sys offset       546 s2 freq  +24541 delay   4928
phc2sys[778056.274]: sys offset       814 s2 freq  +24554 delay   4928
phc2sys[778088.274]: sys offset      1362 s2 freq  +24579 delay   4936
phc2sys[778120.274]: sys offset      1743 s2 freq  +24604 delay   4921
phc2sys[778152.274]: sys offset      1708 s2 freq  +24619 delay   4929
phc2sys[778184.274]: sys offset      1789 s2 freq  +24637 delay   4936
phc2sys[778216.274]: sys offset      1822 s2 freq  +24655 delay   4921
phc2sys[778248.274]: sys offset      1840 s2 freq  +24673 delay   4914
phc2sys[778280.275]: sys offset      1931 s2 freq  +24693 delay   4928
phc2sys[778312.275]: sys offset      1832 s2 freq  +24708 delay   4921
phc2sys[778344.275]: sys offset      1224 s2 freq  +24706 delay   4936

The response would be better with more aggresive PI constants.

> Also, does their servo converge rather slowly, like ntp?

The PI servo should be able to give similar results to other servos if
the constants are set well and there are no problems with unexpected
changes in the frequency due to temperature, etc. See this graph from
the simulator of time error vs reference clock jitter with differently
scaled PI constants. Each set of the constants has a jitter/wander
ratio where it performs best. chrony is included as an example of well
performing adaptive loop. For any jitter/wander there are PI constants
that will perform better than chrony adjusting its own loop
automatically.

http://mlichvar.fedorapeople.org/tmp/pi_poll5.png

-- 
Miroslav Lichvar

Re: [Linuxptp-users] clockcheck - need to filter large spurious phase jumps?

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

On Wed, Nov 13, 2013 at 01:41:37PM +0100, Miroslav Lichvar wrote:
> 
> I tried to run the test with 32s interval on my test machine. When the
> CPU is idle:
> 
> phc2sys[773832.254]: PI servo: sync interval 32.000 kp 0.022 ki 0.009375
> phc2sys[773864.254]: sys offset       -58 s0 freq      +0 delay   4929

Your results look way better than mine. I guess that your machine is a
64 bit OS with VDSO, right?

Mine is a 32 bit Pentium D, and Rick's is an atom, IIRC.

It looks to me like the VDSO is giving much different results. But we
want to have phc2sys working well in both cases.

Thanks,
Richard