✘minpoll=maxpoll=2

[Gary E. Miller]

Yo Achim!

On Mon, 19 Sep 2016 20:09:04 +0200
Achim Gratz <Stromeko at nexgo.de> wrote:

> Gary E. Miller writes:
> >> You 've made this argument before, but I think it's circular
> >> reasoning.  
> >
> > Really?  I think the data is very clear, you can optimize for time
> > or for frequency.  
> 
> No, I still think you're misinterpreting it.  The only reason you see
> that apparent tradeoff is that once you steer the PLL fast enough
> (higher loop bandwidth) all the measurement noise ends up in the
> frequency variable, while if you steer it more slowly (lower loop
> bandwidth), it will be seen predominantly in the offset variable.
> These two variables are not independent and are not themselves an
> actual measurement of what their names suggest.

I'm not sure why you think we disagree.  I fully agree with your
interpretation.  Basically you push here, the error mosve over there,
and vice versa.


> >> You make the local clock follow external jitter faster.  
> >
> > What external jiitter?  Assumption #1 is that the PPS is way
> > better than the internal XTAL.  An assumption supported by the GPS
> > data sheets.  
> 
> The PPS may be (at time scales beyond 1s), but not the measurement
> that NTP does and uses to steer the PLL.

Actually, even at time scales of nanosec, the PPS is very good.

But I agree that all we can see is the result of less than perfact
time stamping in the kernel, mashed with less than perfect NTP
algorithsm.  Until we get something better it is what we got.

>  Looking at the PPS arrival
> times on my rasPi (with ppswatch), there is around 10µs jitter when
> there is no load and going up to 30µs with light activity.

You are being generous.  I see much worse sometimes.  And you have to
specify Pi 1, Pi 2, or Pi 3.  I have them all, and they are all 
different.

>  I'm
> running at poll=4, so ntpd completely eliminates the 10µs jitter in
> the loopstats, as it should.  This jitter must be assumed to come
> from the measurement itself since there's no way the GPS module
> produces that much and the local clock doesn't have that large jitter
> at the 1s timescale either.

I'm running a poll=4 test right now.  I'll comment when I have real data.

On my Pi 3, the poll=3 is worse then poll=1 and poll=2, so I have my
dounts that it gets better at poll=4.  But you may have a Pi 2, or a
different kernel.  If you got data, pleasse send it in.

> > And please notice I am optimizing for self-referencetial stable
> > time, not some 'true' time.  Until it is stable, no point playing
> > with static offsets to make it 'true'.  
> 
> You are in fact destabilizing it by making it follow spurious
> deviations in the measurement.  When disciplining an oscillator, you
> must not do that for timescales lower than the Allan intercept with
> the discipline clock, or you're actually making it worse than it
> already is.

My data is my data.  I look forward to you coming up with better data.

If ntpd is calculating 'goodness' wrong then ntpd needs to be fixed.

If we can come up with a better metric, even if just for testing and 
requires hardware, I'd love to hear it.

> >> BTW, both your plots showed relatively large swings in frequency
> >> offset in a short period of time.  
> >
> > Both plots?  I'm up to dozens now  Gotta be a bit more specific.  
> 
> You've only posted two plots in the post previous to the one I
> responded to.

The plots are too easy to mis-interpret.  The human eye is not good at
reading crazy graphs for the 90% point.  I dont care so much how the
noise looks as long as I have a good 90% band, averaged over 24 hours.

I have now posted 5 data measurements for each of 2 very different hosts
at 4 different poll values.  All 24 hour averages.  More to come.

I'll report that data after my sig.

> > Nope.  My house has no A/C.  It would likely be better if I did have
> > A/C.  If you look at the complete graphs (with CPU, Room, HR, etc.
> > temps) you will see a temperature correlation.  
> 
> Oh, I see it now.  You're plotting days-hh:mm, not hh-mm:ss as I
> assumed initially.

I'm always open to reducing ambiguity, any way the chart could be more
obvvious?

Also, be sure to look at the Xeon plots.  The temps stays within 1°C, but
the frequency still swings a lot over the day.  I suspect it in more
corelated to atmosphere temp then room temp.  At 500ppb the small
things matter, just not sure which small things.

    https://rellim.com/ntpstats/day/

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588


Xeon:

      Local Clock      Local Clock  Local Clock    PPS         PPS      
Poll  Freq Offset 90%  Jitter 90%   Stability 90%  Offset 90%  Jitter 90%       
1           495ppb         16.9us      27.7ppt       39.0us      26.7us
2           332ppb         20.9us      15.6ppt       40.6us      29.7us
3           165ppb         20.5us       7.5ppt       34.6us      27.9us
6           570ppb         10.2us       1.2ppt       34.2us      16.3us


Pi 3:

      Local Clock      Local Clock  Local Clock    PPS         PPS
Poll  Freq Offset 90%  Jitter 90%   Stability 90%  Offset 90%  Jitter 90%
1          1.1ppm         0.43us       2.3ppt         1.6us     0.34us
2          1.1ppm         0.08us       2.9ppt         2.2us     0.20us
3          0.5ppm         0.18us       1.9ppt         3.0us     0.56us
6          1.4ppm         3.3us        2.2ppt        68us       9.7us
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160919/0eb56654/attachment.bin>