[time-nuts] PPS for NTP Server - How Close Is "Good Enough"?
m.matthew.george at gmail.com
Thu Jun 11 16:32:01 EDT 2015
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
LOCAL(0) .LOCL. 10 l 20h 64 0 0.000 0.000
oGPS_ONCORE(0) .GPS. 0 l 13 16 377 0.000 0.000
+time-c.timefreq .ACTS. 1 u 2 64 377 21.373 -0.344
+utcnist2.colora .ACTS. 1 u 3 64 377 22.262 0.144
+india.colorado. .NIST. 1 u 48 64 377 22.236 0.188
-time-a.timefreq .ACTS. 1 u 27 64 377 21.566 -0.595
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,
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
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.
On Thu, Jun 11, 2015 at 4:59 AM, Bob Camp <kb8tq at n1k.org> wrote:
> 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
> to discipline to and which to simply observe.
> > On Jun 11, 2015, at 12:05 AM, M. George <m.matthew.george at gmail.com>
> > 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
> > 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
> > 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
> > 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
> > controls the traffic to my Pi 2 running NTP. It's taking a lot of
> > 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
> > nice block in the low nano seconds, but it rarely shows an offset into
> > 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
> > and again, i'm not using hardpps kernel discipline.
> > Anyway, users on the other end are at the mercy of the network latency
> > 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
> > and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
More information about the time-nuts