Kevin Oberman wrote:
>> Date: Fri, 02 Nov 2007 12:25:46 -0400
>> From: John Ioannidis <[EMAIL PROTECTED]>
>>
>> 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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
