Kevin Oberman wrote:
>> Date: Fri, 02 Nov 2007 12:25:46 -0400
>> From: John Ioannidis
>>
>> Thanks for the reply, but this is not answering my question. I
wasn't asking how to *configure* the beast (I've already done this
successfully), I was asking how to verify that it actually works as
documented!
>>
>> What measurements do I have to take that will show the difference
between a setup that's actually using the PPS signal from the GPS
receiver and one that's not (because, for example, the DCD line on the
motherboard is cracked, to give a stupid example).
>
> I guess I was not clear. 'ntpq -p' will provide the output I showed and
> this will tell you whether the PPS is working. (Note: I don't see that
> it will as your configuration is not correct.)

By "working" I mean "actually having an effect". Not simply that the
kernel takes notice, but that I'm actually getting better results. Hence
my insistence on statistical measurements. I'm also curious as to how
much better my accuracy is when I use the PPS (and hence whether it's
worth the extra trouble for my particular application).

AFAICT, my configuration is correct (modulo the polling intervals). The
"flag3 1" in the fudge line tells the NMEA driver (notice the .20. in
the third octet of the fake IP address) to actually use the PPS signal.

For the record, here is the output of ntpq -p

# ntpq -p
remote refid st t when poll reach delay offset
jitter
================================================== ============================
*GPS_NMEA(1) .PPS. 0 l 53 64 377 0.000 0.019
0.014

Am I missing something?

Thanks,

/ji

John Ioannidis said the following on 11/02/2007 01:16 PM:
> Kevin Oberman wrote:
> >> Date: Fri, 02 Nov 2007 12:25:46 -0400
> >> From: John Ioannidis
> >>
> >> Thanks for the reply, but this is not answering my question. I
> wasn't asking how to *configure* the beast (I've already done this
> successfully), I was asking how to verify that it actually works as
> documented!
> >>
> >> What measurements do I have to take that will show the difference
> between a setup that's actually using the PPS signal from the GPS
> receiver and one that's not (because, for example, the DCD line on the
> motherboard is cracked, to give a stupid example).

I believe the only way you can really *know* how an NTP instance is
performing is to compare it to an external reference of known quality.
Internal NTP statistics can give you an inference (I'm not certain
that's the right word here) that the system is operating correctly, but
no more than that.

If, as your "ntpq -p" shows, you're only syncing to the PPS source and
no other servers, there is absolutely no way to know that you are
keeping the correct time. Apart from the <500 PPM offset sanity check,
your PPS signal could be running at any rate and you wouldn't know it.

So if you truly want to "know", my recommendation is to monitor your
system against another server or three, or have an another server
monitor you. Those servers, of course, should be of known good quality.

You can use the "noselect" option if you'd like to ensure that you only
monitor, but don't sync to, the external server.

By comparing the performance of your system versus the others (along
with using NTP internal stats), you can determine how close you are to
their view of the correct time. You're still trusting that the other
server is keeping good time, but if you use (with permission!) one of
the NIST or USNO servers, or a similar source in other countries, you
can be pretty sure that they are accurate.

Now's not the best time to look at is because a power outage recently
caused a big glitch, but I monitor a herd of my internal stratum 1
servers as well as some external servers on a separate NTP box, with
stats derived from the monitoring system's peerstats logs visible at
http://www.febo.com/time-freq/ntp/stats/index.html.

John