[time-nuts] PPS for NTP Server - How Close Is "Good Enough"?

Bob Camp kb8tq at n1k.org
Thu Jun 11 20:16:00 EDT 2015


Hi

Comparing a GPS to a series of “over the net” sources will always make the GPS look 
good. NTP is usually smart enough to figure out that the GPS is the one it wants and lock
in on it. 

The ppm’s at the bottom are talking about the software PLL and how it’s offset from your
computer’s local clock. It’s telling you what it’s best guess is at the frequency of the oscillator
on your Pi. It’s a guess until you can do enough work to be sure that NTP isn’t being messed
up by something else going on in the system.

Bob

> On Jun 11, 2015, at 4:32 PM, M. George <m.matthew.george at gmail.com> wrote:
> 
> Hi Bob, yes I'm including several other sources and usually about 3 are
> getting included in the discipline of the local clock.  Here is my ntpq
> -pcrl output at the time I wrote this message.
> 
> pi at raspi2 ~ $ ntpq -pcrl
>     remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> LOCAL(0)        .LOCL.          10 l  20h   64    0    0.000    0.000
> 0.000
> oGPS_ONCORE(0)   .GPS.            0 l   13   16  377    0.000    0.000
> 0.002
> +time-c.timefreq .ACTS.           1 u    2   64  377   21.373   -0.344
> 0.504
> +utcnist2.colora .ACTS.           1 u    3   64  377   22.262    0.144
> 1.720
> +india.colorado. .NIST.           1 u   48   64  377   22.236    0.188
> 0.122
> -time-a.timefreq .ACTS.           1 u   27   64  377   21.566   -0.595
> 0.405
> associd=0 status=0419 leap_none, sync_uhf_radio, 1 event, leap_armed,
> version="ntpd 4.3.37 at 1.2483-o Thu Jun 11 00:12:07 UTC 2015 (1)",
> processor="armv7l", system="Linux/3.18.14-v7+", leap=00, stratum=1,
> precision=-19, rootdelay=0.000, rootdisp=1.195, refid=GPS,
> reftime=d9246d02.38389bc3  Thu, Jun 11 2015 14:24:34.219,
> clock=d9246d0f.92141a9c  Thu, Jun 11 2015 14:24:47.570, peer=6887, tc=4,
> mintc=3, offset=0.000163, frequency=-7.742, sys_jitter=0.001907,
> clk_jitter=0.002, clk_wander=0.000, tai=35, leapsec=201507010000,
> expire=201512280000
> 
> I have been careful to try and tweak the time1 offset to get a reasonable
> offset against the reference servers that show something less than 1ms over
> time.
> 
> Shortly I'll have another GPS / M12+ up and running on another PI that I
> can use as a local reference along with other NTP servers over the internet.
> 
> As you can see, the PPM frequency on this Pi is still showing -7.742.  I
> assume that is if it was undisciplined?  I have wondered about that.
> 
> Matt
> 
> On Thu, Jun 11, 2015 at 4:59 AM, Bob Camp <kb8tq at n1k.org> wrote:
> 
>> Hi
>> 
>> Be careful of “single source” comparisons. When running with one reference,
>> NTP is really measuring the reference against it’s self. It’s analogous to
>> using a
>> frequency counter to check it’s own reference. It *does* indeed check a
>> number of things.
>> It’s not really checking everything.
>> 
>> An overly simple way to look at it:
>> 
>> NTP is running a PLL, it “locks” a (software based) oscillator to the
>> reference. With
>> a single reference, it’s comparing the output of that PLL to the input to
>> the PLL.
>> 
>> The obvious way to get around this is to have multiple references coming
>> into NTP.
>> That’s easy if you want “less stable” references. It’s more money if you
>> want to
>> duplicate the GPS you have. After that it’s a matter of telling NTP which
>> sources
>> to discipline to and which to simply observe.
>> 
>> Bob
>> 
>>> On Jun 11, 2015, at 12:05 AM, M. George <m.matthew.george at gmail.com>
>> wrote:
>>> 
>>> Here is what I have been able to do with a Motorola Oncore UT+ that I got
>>> from Bob Stewart awhile back.  This is with a Raspberry PI 2 with a
>> number
>>> of tweaks and a custom compiled kernel.  Nothing too drastic... plus the
>>> current Dev version of NTP compile on the Raspberry PI.  I'm getting
>> better
>>> results letting ntpd discipline the clock over doing kernel discipline...
>>> not surprising because the algorithms in the ntpd code are much more
>>> sophisticated than the Linux kernel pps code... ntpd discipline provides
>>> much lower jitter in my experience.
>>> 
>>> I'm rambling at this point, but the following samples are with a $30
>>> antenna on the peak of my roof with LMR-400 solid conductor coax at a
>>> length of 70 ft.  ~1.2 ns per foot delay based on the LMR-400 specs and
>>> nice low loss.  I'm running the coax into an 8 way antenna splitter
>> etc...
>>> nothing that anyone else hasn't done before here.
>>> 
>>> The Raspberry PI 2 in this case is under load too as part of the
>>> www.pool.ntp.org pool: time.nc7j.com if you want to sync against it.
>>> 
>>> As everyone else has mentioned, it's total overkill for NTP, but I'm just
>>> interested in tweaking and seeing how good I can get for fun more than
>>> anything else... i.e. time-nut obsession.  I'm pretty happy with the
>>> following under load with www.pool.ntp.org set at 25MB of bandwidth
>> which
>>> controls the traffic to my Pi 2 running NTP.  It's taking a lot of
>> traffic
>>> per second... the CPU for ntpd on the Pi is still low at around .5% to 1%
>>> of one core on the Pi 2.
>>> 
>>> Here is a block of offsets from a loopstat file, and yes I cherry picked
>> a
>>> nice block in the low nano seconds, but it rarely shows an offset into
>> the
>>> micro seconds over time.. these are 16 second samples of the offsets...
>>> 
>>> -0.000000225
>>> -0.000000273
>>> 0.000000094
>>> 0.000000328
>>> -0.000000155
>>> -0.000000042
>>> -0.000000169
>>> 0.000000323
>>> 0.000000038
>>> -0.000000312
>>> -0.000000675
>>> -0.000000036
>>> 0.000000213
>>> -0.000000193
>>> 0.000000005
>>> -0.000000503
>>> -0.000000154
>>> -0.000000179
>>> -0.000000321
>>> 0.000000096
>>> -0.000000119
>>> -0.000000173
>>> 
>>> Not too shabby for a killer deal on an Oncore UT+ for $5 from Bob!  I'm
>>> running the PPS out of the UT+ through a level converter to get the ~3.3v
>>> PPS output... the serial output on the UT+ is also going through a level
>>> converter direct into the Pi 2.  Using the oncore 127.127.30.0 ntpd
>> driver
>>> and again, i'm not using hardpps kernel discipline.
>>> 
>>> Anyway, users on the other end are at the mercy of the network latency
>> and
>>> noise etc... but I'm serving up some pretty consistent time references,
>>> considering the Pi 2 was $35... and the only one that really cares is
>>> me...  I'm trying to masquerade as a nerdy wana-b time-nut.
>>> 
>>> I think NTP is a great place to start... if you want to toy around and
>>> tinker, plus provide a service to the rest of the Internet by joining
>>> www.pool.ntp.org and sharing your obsession with time.
>>> 
>>> Max NG7M
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> 
> 
> 
> -- 
> M. George
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the time-nuts mailing list