Yo Achim! On Mon, 19 Sep 2016 20:09:04 +0200 Achim Gratz <strom...@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
g...@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
pgpfyoqLSiPLC.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
