prefer in ntp.conf - NTP

This is a discussion on prefer in ntp.conf - NTP ; I am using a GPS nmea/pps source (lets not go into the heart-ache involved in getting that working), and a very recent download of ntp source, with the nmea patch. Obviously I have a few internet sources as well, but ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: prefer in ntp.conf

  1. prefer in ntp.conf

    I am using a GPS nmea/pps source (lets not go into the heart-ache
    involved in getting that working), and a very recent download of ntp
    source, with the nmea patch. Obviously I have a few internet sources as
    well, but use the prefer keyword for the pps source. Obviously when it
    is working the pps is about as accurate as I can get. However when I run
    ntpq -p it isn't quite doing as I want.
    I want to lock exactly to that pps source WHILE IT IS SENSIBLE, and to
    drop back to the internet when it has lost satellites. However ntp
    appears to be taking an average, loaded towards the GPS source. When the
    GPS looses satellites and goes beserk ntp sensibly drops it as a source.
    Your suggestions would be welcomed.

    Paul
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: prefer in ntp.conf


    paul@lavender-fam.net (Paul) writes:
    > I want to lock exactly to that pps source WHILE IT IS SENSIBLE, and to
    > drop back to the internet when it has lost satellites. However ntp
    > appears to be taking an average, loaded towards the GPS source. When the
    > GPS looses satellites and goes beserk ntp sensibly drops it as a source.
    > Your suggestions would be welcomed.


    Stepping outside the box a bit, the real problem here is your GPS
    reception is very marginal. Even if ntp did what you want, you'd
    still get crappy GPS data since the GPS is "satellite hopping" and
    getting a noisy low-quality lock on the satellites. Why not fix that
    first and then start hacking ntp to do what you want with the "prefer"
    keyword. (Such as having it ignore the prefer if the clocksource is
    at stratum 16).

    -wolfgang
    --
    Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
    IPv6 on Fedora 7 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

  3. Re: prefer in ntp.conf

    Paul,

    What GPS are you using? What OS? What does your ntpq -p data look like?

    If you get a receiver with TRAIM, then you can have it disable the PPS
    output when it detects itself getting out of sync, either by bad data or no
    lock. Otherwise most GPSes will just keep pulsing away none-the-wiser
    (except for their NMEA data which NTP doesn't check against).

    You *could* write extra code in the driver to check various NMEA sentences
    (which why it hasn't been done I'm not sure) to make sure it has a proper
    lock.

    Or as someone else mentioned, ensure that your antenna has a proper view of
    the sky so you do not loose lock.

    I wrote a post just a day or two ago about the PREFER source and how if you
    have several internet sources they can out weigh your local (more accurate)
    source and thus discard it if you do not have the PREFER flag set. So it can
    be a potential issue.

    Jason

    >I am using a GPS nmea/pps source (lets not go into the heart-ache
    >involved in getting that working), and a very recent download of ntp
    >source, with the nmea patch. Obviously I have a few internet sources as
    >well, but use the prefer keyword for the pps source. Obviously when it
    >is working the pps is about as accurate as I can get. However when I run
    >ntpq -p it isn't quite doing as I want.
    >I want to lock exactly to that pps source WHILE IT IS SENSIBLE, and to
    >drop back to the internet when it has lost satellites. However ntp
    >appears to be taking an average, loaded towards the GPS source. When the
    >GPS looses satellites and goes beserk ntp sensibly drops it as a source.
    >Your suggestions would be welcomed.
    >
    >Paul


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  4. Re: prefer in ntp.conf

    Jason
    I couldn't find your post on the prefer - it sounds exactly what I am
    finding. Incidently the mnea patch does listen to the nmea data (so you
    could have a totally free standing ntp system. Unfortunately simple GPS
    receivers don't have the capability you mention, hence the need for
    sanity checks.

    Paul

    On Wed, 2007-06-13 at 14:25 -0500, Jason Rabel wrote:
    > Paul,
    >
    > What GPS are you using? What OS? What does your ntpq -p data look like?
    >
    > If you get a receiver with TRAIM, then you can have it disable the PPS
    > output when it detects itself getting out of sync, either by bad data or no
    > lock. Otherwise most GPSes will just keep pulsing away none-the-wiser
    > (except for their NMEA data which NTP doesn't check against).
    >
    > You *could* write extra code in the driver to check various NMEA sentences
    > (which why it hasn't been done I'm not sure) to make sure it has a proper
    > lock.
    >
    > Or as someone else mentioned, ensure that your antenna has a proper view of
    > the sky so you do not loose lock.
    >
    > I wrote a post just a day or two ago about the PREFER source and how if you
    > have several internet sources they can out weigh your local (more accurate)
    > source and thus discard it if you do not have the PREFER flag set. So it can
    > be a potential issue.
    >
    > Jason
    >
    > >I am using a GPS nmea/pps source (lets not go into the heart-ache
    > >involved in getting that working), and a very recent download of ntp
    > >source, with the nmea patch. Obviously I have a few internet sources as
    > >well, but use the prefer keyword for the pps source. Obviously when it
    > >is working the pps is about as accurate as I can get. However when I run
    > >ntpq -p it isn't quite doing as I want.
    > >I want to lock exactly to that pps source WHILE IT IS SENSIBLE, and to
    > >drop back to the internet when it has lost satellites. However ntp
    > >appears to be taking an average, loaded towards the GPS source. When the
    > >GPS looses satellites and goes beserk ntp sensibly drops it as a source.
    > >Your suggestions would be welcomed.
    > >
    > >Paul

    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  5. Re: prefer in ntp.conf

    Paul,

    The post can be found at:

    https://lists.ntp.isc.org/pipermail/...ne/014586.html

    I'm not sure what you mean by the "nmea patch"? My guess is you are trying
    to do it all on linux and had to jump through hoops to get it all working.

    It's been a while since I looked at the NMEA refclock, but I'm pretty sure
    all it looks for is to parse the date/time.

    A modified nmea reflock driver could be written so that it also checks
    certain sentences to see if the receiver has a 2D/3D fix, or even is just
    tracking any satellites. I guess it's not currently in there because not all
    receivers output the same sentences by default. Also again a 'better'
    receiver will have TRAIM and/or capable of an overdetermistic
    single-satellite solution.

    Again, what GPS receiver are you using? If you are serious it might be worth
    spending a little cash to mount an antenna with a clear view of the sky and
    use a receiver that has better features geared toward timing solutions.

    Jason


    >Jason
    >I couldn't find your post on the prefer - it sounds exactly what I am
    >finding. Incidently the mnea patch does listen to the nmea data (so you
    >could have a totally free standing ntp system. Unfortunately simple GPS
    >receivers don't have the capability you mention, hence the need for
    >sanity checks.
    >
    >Paul


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: prefer in ntp.conf


    >It's been a while since I looked at the NMEA refclock, but I'm pretty sure
    >all it looks for is to parse the date/time.


    The NMEA driver has a feature/hack/bug where it automagically uses
    the PPS info if the text message makes sense.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


+ Reply to Thread