Re: Slow convergence of NTP with GPS/PPS - NTP

This is a discussion on Re: Slow convergence of NTP with GPS/PPS - NTP ; > From: "David McConnell" > Date: Tue, 30 Sep 2008 14:04:18 +0100 > Sender: questions-bounces+oberman=es.net@lists.ntp.org > > > Hi > > We are using Linux ntpd with GPS/PPS reference clock to discipline the time > on our systems. > > ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Slow convergence of NTP with GPS/PPS

  1. Re: Slow convergence of NTP with GPS/PPS

    > From: "David McConnell"
    > Date: Tue, 30 Sep 2008 14:04:18 +0100
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > Hi
    >
    > We are using Linux ntpd with GPS/PPS reference clock to discipline the time
    > on our systems.
    >
    > Our application requires good time accuracy (better than 5ms) but it also
    > needs to get there quickly (as quickly as possible, but ideally taking no
    > more than about 15 minutes).
    > (The Linux/ntpd is running on a remote embedded device that is frequently
    > restarted - possibly once a day or so - so we cant wait hours for
    > convergence).
    >
    > Currently ntpd can take hours to achieve the desired acuracy.
    >
    > So, the question is simple - is there any way to significantly speedup the
    > convergence of ntpd (using GPS/PPS reference clock)?
    >
    > We would be prepared to compromise somewhat on accuracy and jitter.
    > (Currently accuracy and jitter values are excellent with jitter as low as 1
    > microsecond and accuracy better than 10 uS but it can take a day or two to
    > get there).
    >
    > It does not seem unreasonable to expect that the ntpd could achieve the
    > required accuracy within 15 minutes or so - but nothing we have tried seems
    > to work.
    > Have tried modifying some of the tinker values, but we dont really
    > understand what they all do - and have not really had any success.
    >
    > So to summarise:
    >
    > 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
    > clock)?
    > 2) If so, how - and what are the tradeoffs?


    Sorry for the dup for everyone on the mailing list, but I need to send
    it unsigned to make it to the news group.

    Most important is to start ntpd at boot time with the -g option so that
    it will immediately set the time. Then adjust your ntp.conf to set the
    maxpoll and minpoll to 4 for your reference clock.
    "minpoll 4 maxpoll 4"

    This will get the time synced to close to correct, hopefully a few
    microseconds, within a couple of minutes, depending on your hardware.
    --
    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

    --==_Exmh_1222806547_81119P
    Content-Type: application/pgp-signature
    iD8DBQFI4owTkn3rs5h7N1ERAmQBAJ4hJZT+g/g867Jcijg6bPrhrzT9AQCeN+5k
    Orv1xQK+MBGU7BWQ8YXnhio=
    =LqU7
    -----END PGP SIGNATURE-----

    --==_Exmh_1222806547_81119P--

  2. Re: Slow convergence of NTP with GPS/PPS

    Kevin Oberman wrote:

    >
    > Most important is to start ntpd at boot time with the -g option so that
    > it will immediately set the time. Then adjust your ntp.conf to set the
    > maxpoll and minpoll to 4 for your reference clock.
    > "minpoll 4 maxpoll 4"


    Most reference clocks ignore maxpoll, and I think quite a lot ignore
    minpoll.

    >
    > This will get the time synced to close to correct, hopefully a few
    > microseconds, within a couple of minutes, depending on your hardware.


    It will get you with a maximum error of about 128ms. You can do
    somewhat better if you ensure that you start off more than 128ms out, as
    that will force an initial step.

+ Reply to Thread