Re: How do I know my GPS-based NTP server isactually working properly? - NTP

This is a discussion on Re: How do I know my GPS-based NTP server isactually working properly? - NTP ; > 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), ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: How do I know my GPS-based NTP server isactually working properly?

  1. Re: How do I know my GPS-based NTP server isactually working properly?

    > 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.)
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

  2. Re: How do I know my GPS-based NTP server isactually working properly?

    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

  3. Re: How do I know my GPS-based NTP server isactually working properly?

    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

+ Reply to Thread