Driver Help? - NTP

This is a discussion on Driver Help? - NTP ; I'm hacking a copy of the NMEA driver to work with the CDMA modems (which provide a clock signal even if not subscribed - kinda interesting) and have it talking to the device. But - even though the dispersion looks ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Driver Help?

  1. Driver Help?

    I'm hacking a copy of the NMEA driver to work with the CDMA modems
    (which provide a clock signal even if not subscribed - kinda
    interesting) and have it talking to the device.

    But - even though the dispersion looks reasonable and so does jitter,
    the application refuses to consider it "synced".

    I have the following.....

    ntpdc> sysi
    system peer: CDMA(0)
    system peer mode: client
    leap indicator: 11
    stratum: 16
    precision: -19
    root distance: 0.00000 s
    root dispersion: 0.00165 s
    reference ID: [67.68.77.0]
    reference time: 00000000.00000000 Thu, Feb 7 2036 0:28:16.000
    system flags: auth monitor ntp kernel stats
    jitter: 0.001129 s
    stability: 0.000 ppm
    broadcastdelay: 0.003998 s
    authdelay: 0.000000 s
    ntpdc> peer
    remote local st poll reach delay offset disp
    ================================================== =====================
    *CDMA(0) 127.0.0.1 0 16 377 0.00000 0.241065 0.00697
    ntpdc>

    Obviously, I'm missing SOMETHING....... the dispersion looks reasonable,
    but it will not lock up on the clock. Any idea where I start?

    Oh, the other thing I've run into is that the START routine is never
    called if I don't run the application with debugging turned on (!); no
    errors logged, just no startup. I stuck a syslog in the "start" routine
    right at the front - it never gets executed if the ntpd app is in the
    background!

    This might be a nice driver to contribute.... if I can get the dang
    thing working! :-)

    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  2. Re: Driver Help?

    Karl Denninger wrote:
    > I'm hacking a copy of the NMEA driver to work with the CDMA modems
    > (which provide a clock signal even if not subscribed - kinda
    > interesting) and have it talking to the device.
    >
    > But - even though the dispersion looks reasonable and so does jitter,
    > the application refuses to consider it "synced".
    >
    > I have the following.....
    >
    > ntpdc> sysi
    > system peer: CDMA(0)
    > system peer mode: client
    > leap indicator: 11
    > stratum: 16
    > precision: -19
    > root distance: 0.00000 s
    > root dispersion: 0.00165 s
    > reference ID: [67.68.77.0]
    > reference time: 00000000.00000000 Thu, Feb 7 2036 0:28:16.000
    > system flags: auth monitor ntp kernel stats
    > jitter: 0.001129 s
    > stability: 0.000 ppm
    > broadcastdelay: 0.003998 s
    > authdelay: 0.000000 s
    > ntpdc> peer
    > remote local st poll reach delay offset disp
    > ================================================== =====================
    > *CDMA(0) 127.0.0.1 0 16 377 0.00000 0.241065 0.00697
    > ntpdc>
    >
    > Obviously, I'm missing SOMETHING....... the dispersion looks reasonable,
    > but it will not lock up on the clock. Any idea where I start?


    I think you may be missing the "*" in column one above. That indicates
    that ntpd has your CDMA(0) clock as the synchronization source.

    The offset looks a little high unless ntdp was started quite recently.
    Bear in mind that ntpd needs time to beat your clock into submission.
    Thirty minutes is a good length of time to wait before taking offset and
    dispersion figures seriously.


  3. Re: Driver Help?

    Richard B. Gilbert wrote:
    > Karl Denninger wrote:
    >> I'm hacking a copy of the NMEA driver to work with the CDMA modems
    >> (which provide a clock signal even if not subscribed - kinda
    >> interesting) and have it talking to the device.
    >>
    >> But - even though the dispersion looks reasonable and so does jitter,
    >> the application refuses to consider it "synced".
    >>
    >> I have the following.....
    >>
    >> ntpdc> sysi
    >> system peer: CDMA(0)
    >> system peer mode: client
    >> leap indicator: 11
    >> stratum: 16
    >> precision: -19
    >> root distance: 0.00000 s
    >> root dispersion: 0.00165 s
    >> reference ID: [67.68.77.0]
    >> reference time: 00000000.00000000 Thu, Feb 7 2036 0:28:16.000
    >> system flags: auth monitor ntp kernel stats
    >> jitter: 0.001129 s
    >> stability: 0.000 ppm
    >> broadcastdelay: 0.003998 s
    >> authdelay: 0.000000 s
    >> ntpdc> peer
    >> remote local st poll reach delay offset disp
    >> ================================================== =====================
    >> *CDMA(0) 127.0.0.1 0 16 377 0.00000 0.241065 0.00697
    >> ntpdc>
    >>
    >> Obviously, I'm missing SOMETHING....... the dispersion looks
    >> reasonable, but it will not lock up on the clock. Any idea where I
    >> start?

    >
    > I think you may be missing the "*" in column one above. That indicates
    > that ntpd has your CDMA(0) clock as the synchronization source.
    >
    > The offset looks a little high unless ntdp was started quite recently.
    > Bear in mind that ntpd needs time to beat your clock into submission.
    > Thirty minutes is a good length of time to wait before taking offset and
    > dispersion figures seriously.
    >


    Ok... I'll wait a good long while (several hours)

    This thing isn't the BEST time source ever invented, but I've got a few
    folks who would like it as a solution, and of course I'll contribute the
    driver back to the codebase - if I can get it to work!

    The other problem - that the driver's "start" routine is never called
    unless ntpd is not running as a daemon - is puzzling. Not quite sure
    why that would happen.... but the routine is definitely not being
    entered, although the base code IS running (the startup message gets
    logged to the syslog and there are no errors.)

    Its almost like the config file switch is ignored if its not in debug
    mode and thus didn't attempt to start the clock. I can get a sysi but a
    peer shows no data (as expected with no clocks or peers attached)

    I built this from source of the current RC2 source - I'm a long-time
    NTPD user (and have a Stratum 1 server running here with a GPS+PPS
    source), but haven't (yet) attempted to integrate a "new" clock into the
    codebase.

    --
    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  4. Re: Driver Help?

    What OS are you running, and what CDMA modem are you using? (Just curious)

    Also from the info you gave it looks like it is using your CDMA source, but
    seeing the stratum at 16 I don't think you have had NTP run long enough to
    adjust the clock into sync.

    Jason

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


  5. Re: Driver Help?

    Jason Rabel wrote:
    > What OS are you running, and what CDMA modem are you using? (Just curious)
    >
    > Also from the info you gave it looks like it is using your CDMA source, but
    > seeing the stratum at 16 I don't think you have had NTP run long enough to
    > adjust the clock into sync.
    >
    > Jason



    FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.

    --
    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  6. Re: Driver Help?

    Karl Denninger wrote:
    > Jason Rabel wrote:
    >> What OS are you running, and what CDMA modem are you using? (Just
    >> curious)
    >>
    >> Also from the info you gave it looks like it is using your CDMA
    >> source, but
    >> seeing the stratum at 16 I don't think you have had NTP run long
    >> enough to
    >> adjust the clock into sync.
    >>
    >> Jason

    >
    >
    > FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.
    >


    Quick update on this.... it appears that while the timecode is being
    stuffed appropriately, the underlying NTPD daemon doesn't like it -
    after a half-hour or so (running with debug turned up) and watching it
    log things, it fails to lock on and resets the time source, dropping and
    restarting the clock.

    I assume this means it is unable to get "happy enough" with the
    stability of the timestamps to formulate a "solution", declares the
    clock "broken", and then restarts....... yes?

    The obvious question is "can a time source that outputs only with 1
    second resolution and only when polled generate
    sufficiently-high-quality reference time for the system to use it?"

    If the answer is "no", then the curtain needs to be drawn on this
    attempt. If the answer is "yes", then I need to figure out how to
    accomplish getting better input resolution I suspect - perhaps with a
    helper application that polls at a higher rate of speed (e.g. several
    times per second) and "stuffs" timecode events into the receive buffer
    (e.g. via a named pipe or similar)

    --
    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  7. Re: Driver Help?

    >>> In article , Karl Denninger writes:

    ntpdc> peer
    >>> remote local st poll reach delay offset disp
    >>> ================================================== =====================
    >>> *CDMA(0) 127.0.0.1 0 16 377 0.00000 0.241065 0.00697


    I would not expect to see 127.0.0.1 in that field, but it may be because you
    are using ntpdc and not ntpq. What does the output of 'ntpq -p' look like?

    Karl> I built this from source of the current RC2 source

    I'd recommend using ntp-dev instead. We're effectively at a feature freeze
    for ntp-4.2.6 now, as I'm expecting to release 4.2.6 as soon as the current
    set of blocking bugs are fixed. I expect this will take another couple of
    months' time.

    H

  8. Re: Driver Help?

    Karl Denninger wrote:
    > Karl Denninger wrote:
    >
    >> Jason Rabel wrote:
    >>
    >>> What OS are you running, and what CDMA modem are you using? (Just
    >>> curious)
    >>>
    >>> Also from the info you gave it looks like it is using your CDMA
    >>> source, but
    >>> seeing the stratum at 16 I don't think you have had NTP run long
    >>> enough to
    >>> adjust the clock into sync.
    >>>
    >>> Jason

    >>
    >>
    >>
    >> FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.
    >>

    >
    > Quick update on this.... it appears that while the timecode is being
    > stuffed appropriately, the underlying NTPD daemon doesn't like it -
    > after a half-hour or so (running with debug turned up) and watching it
    > log things, it fails to lock on and resets the time source, dropping and
    > restarting the clock.
    >
    > I assume this means it is unable to get "happy enough" with the
    > stability of the timestamps to formulate a "solution", declares the
    > clock "broken", and then restarts....... yes?
    >
    > The obvious question is "can a time source that outputs only with 1
    > second resolution and only when polled generate
    > sufficiently-high-quality reference time for the system to use it?"
    >
    > If the answer is "no", then the curtain needs to be drawn on this
    > attempt. If the answer is "yes", then I need to figure out how to
    > accomplish getting better input resolution I suspect - perhaps with a
    > helper application that polls at a higher rate of speed (e.g. several
    > times per second) and "stuffs" timecode events into the receive buffer
    > (e.g. via a named pipe or similar)
    >


    Subject to correction by someone who knows what he's talking about the
    answer is not just "no" but "HELL NO"!

    The resolution of 1 second is a killer. This is going to make the
    jitter a function of exactly when each poll is received. I doubt that
    ntpd cares very much exactly when a poll is sent. If this device has a
    PPS output, it might be useable. . . .


  9. Re: Driver Help?

    Richard B. Gilbert wrote:
    > Karl Denninger wrote:
    >> Karl Denninger wrote:
    >>
    >>> Jason Rabel wrote:
    >>>
    >>>> What OS are you running, and what CDMA modem are you using? (Just
    >>>> curious)
    >>>>
    >>>> Also from the info you gave it looks like it is using your CDMA
    >>>> source, but
    >>>> seeing the stratum at 16 I don't think you have had NTP run long
    >>>> enough to
    >>>> adjust the clock into sync.
    >>>>
    >>>> Jason
    >>>
    >>>
    >>>
    >>> FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA.
    >>>

    >>
    >> Quick update on this.... it appears that while the timecode is being
    >> stuffed appropriately, the underlying NTPD daemon doesn't like it -
    >> after a half-hour or so (running with debug turned up) and watching it
    >> log things, it fails to lock on and resets the time source, dropping
    >> and restarting the clock.
    >>
    >> I assume this means it is unable to get "happy enough" with the
    >> stability of the timestamps to formulate a "solution", declares the
    >> clock "broken", and then restarts....... yes?
    >>
    >> The obvious question is "can a time source that outputs only with 1
    >> second resolution and only when polled generate
    >> sufficiently-high-quality reference time for the system to use it?"
    >>
    >> If the answer is "no", then the curtain needs to be drawn on this
    >> attempt. If the answer is "yes", then I need to figure out how to
    >> accomplish getting better input resolution I suspect - perhaps with a
    >> helper application that polls at a higher rate of speed (e.g. several
    >> times per second) and "stuffs" timecode events into the receive buffer
    >> (e.g. via a named pipe or similar)
    >>

    >
    > Subject to correction by someone who knows what he's talking about the
    > answer is not just "no" but "HELL NO"!
    >
    > The resolution of 1 second is a killer. This is going to make the
    > jitter a function of exactly when each poll is received. I doubt that
    > ntpd cares very much exactly when a poll is sent. If this device has a
    > PPS output, it might be useable. . . .


    It doesn't, which sucks. Severely.

    I will contact Multitech and see if there's a solution to this (either
    in the form of better resolution or a PPS output option somehow.) If
    not, well, it was a nice try :->

    --
    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  10. Re: Driver Help?

    Well I guess I should speak up with a correction... :P

    Actually more of just an addendum, what you are saying isn't incorrect.

    I know from some experience with the TrueTime driver that the sysplex output
    only has second resolution, *however* it outputs the time and the trailing
    is supposed to be within X milliseconds of "on time". When you go into
    polling mode, then it gives you three digits past the decimal when it
    returns the time.

    So the issue here is, you either need a way for the device to go into an
    auto-output mode where it gives the time on the second, or give better
    resolution when polled. Also helpful would be if it followed the sysplex
    flags to know if the time was actually in sync or not with the radio source.

    Jason

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


  11. Re: Driver Help?

    "Karl Denninger" wrote in message
    news:sVJbi.122151$NK5.94621@newsfe23.lga...
    [...]
    > The obvious question is "can a time source that outputs only with 1
    > second resolution and only when polled generate
    > sufficiently-high-quality reference time for the system to use it?"


    Perhaps not on its own, but I can imagine a scheme where you look
    for its top-of-second point, by polling at random intervals or
    intervals of slightly more or less than one second.

    If its internal clock is good enough, then given time it could be
    made acceptable. It's not unlike TSC interpolation.

    Groetjes,
    Maarten Wiltink



  12. Re: Driver Help?

    Maarten Wiltink wrote:
    > "Karl Denninger" wrote in message
    > news:sVJbi.122151$NK5.94621@newsfe23.lga...
    > [...]
    >> The obvious question is "can a time source that outputs only with 1
    >> second resolution and only when polled generate
    >> sufficiently-high-quality reference time for the system to use it?"

    >
    > Perhaps not on its own, but I can imagine a scheme where you look
    > for its top-of-second point, by polling at random intervals or
    > intervals of slightly more or less than one second.
    >
    > If its internal clock is good enough, then given time it could be
    > made acceptable. It's not unlike TSC interpolation.
    >
    > Groetjes,
    > Maarten Wiltink
    >
    >


    That's kinda what I'm thinking.

    If Multitech can't get me something better than what I have I may try to
    synthesize it with a daemon that attempts to "find" the change and then
    stuffs NTPD via a named pipe or something similar.

    --
    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  13. Re: Driver Help?

    On 2007-06-13, Karl Denninger wrote:

    > If Multitech can't get me something better than what I have I may try
    > to synthesize it with a daemon that attempts to "find" the change and
    > then stuffs NTPD via a named pipe or something similar.


    This what the SHM driver is for.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  14. Re: Driver Help?

    Steve Kostecke wrote:
    > On 2007-06-13, Karl Denninger wrote:
    >
    >> If Multitech can't get me something better than what I have I may try
    >> to synthesize it with a daemon that attempts to "find" the change and
    >> then stuffs NTPD via a named pipe or something similar.

    >
    > This what the SHM driver is for.
    >


    Yep.

    But I'm going to try to get something from Multitech first. If no
    response or nothing constructive, then I'll start writing code.

    --
    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  15. Re: Driver Help?


    >The resolution of 1 second is a killer. This is going to make the
    >jitter a function of exactly when each poll is received. I doubt that
    >ntpd cares very much exactly when a poll is sent. If this device has a
    >PPS output, it might be useable. . . .


    Some GPS units can be put into a mode where they send a report
    on each second tick. So although the resolution in their
    data format is only one second, you get the message close
    to that second tick.

    There might be an option in the polling mode where it
    waits until the second ticks before answering.

    You might be able to fake it by polling every few ms until you
    see the answer change. Then you know that the second ticked
    between two polls so your time resolution is the poll interval.
    Skipping the useless polls is left as an exercise ....

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


  16. Re: Driver Help?

    > From: Karl Denninger
    > Date: Wed, 13 Jun 2007 12:07:22 -0500
    > Sender: questions-bounces+oberman=es.net@lists.ntp.isc.org
    >
    > Steve Kostecke wrote:
    > > On 2007-06-13, Karl Denninger wrote:
    > >
    > >> If Multitech can't get me something better than what I have I may try
    > >> to synthesize it with a daemon that attempts to "find" the change and
    > >> then stuffs NTPD via a named pipe or something similar.

    > >
    > > This what the SHM driver is for.
    > >

    >
    > Yep.
    >
    > But I'm going to try to get something from Multitech first. If no
    > response or nothing constructive, then I'll start writing code.


    Carl,

    We use CDMA and can keep time within a couple of microseconds. I am using
    an EndRun Technologies CDMA clock which provides PPS, but the jitter on
    the raw (TrueTime emulated) once a second update is about 4 ms at
    worst. This sucks compared to the PPS, but should be good for most cases
    where high precision is not an issue.

    By the way, the external CDMA clock from EndRun is pretty well hidden on
    the web pages under "Other Products". It is found at:
    http://www.endruntechnologies.com/ne...ime-source.htm
    --
    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

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (FreeBSD)
    Comment: Exmh version 2.5 06/03/2002

    iD8DBQFGcDPJkn3rs5h7N1ERAmyFAJ96zEYOdQD6s3afGcb3jH OrIDhe1gCeNji/
    7rk8+b5N5L0VEe5xyId6AbE=
    =1c+W
    -----END PGP SIGNATURE-----


  17. Re: Driver Help?

    Kevin Oberman wrote:
    >>From: Karl Denninger
    >>Date: Wed, 13 Jun 2007 12:07:22 -0500
    >>Sender: questions-bounces+oberman=es.net@lists.ntp.isc.org
    >>
    >>Steve Kostecke wrote:
    >>
    >>>On 2007-06-13, Karl Denninger wrote:
    >>>
    >>>
    >>>>If Multitech can't get me something better than what I have I may try


    >
    > Carl,
    >
    > We use CDMA and can keep time within a couple of microseconds. I am using
    > an EndRun Technologies CDMA clock which provides PPS, but the jitter on
    > the raw (TrueTime emulated) once a second update is about 4 ms at
    > worst. This sucks compared to the PPS, but should be good for most cases
    > where high precision is not an issue.
    >
    > By the way, the external CDMA clock from EndRun is pretty well hidden on
    > the web pages under "Other Products". It is found at:
    > http://www.endruntechnologies.com/ne...ime-source.htm
    >


    They say "Email or call us for a competitive price quote...."
    Why do I always get nervous when someone says that? It generally means
    "all the traffic will bear and then some!" I much prefer to deal with
    someone who says, up front, "it's $1253.99 plus shipping from. . . ."
    It saves us both a bit of time because there's no way I'm going to pay
    that much. It might be different if I had a corporate sponsor but
    nowadays it's strictly out of my pocket!


  18. Re: Driver Help?

    Richard B. Gilbert wrote:

    >
    > They say "Email or call us for a competitive price quote...."
    > Why do I always get nervous when someone says that? It generally means
    > "all the traffic will bear and then some!" I much prefer to deal with
    > someone who says, up front, "it's $1253.99 plus shipping from. . . ." It
    > saves us both a bit of time because there's no way I'm going to pay that
    > much. It might be different if I had a corporate sponsor but nowadays
    > it's strictly out of my pocket!
    >


    You got that right. Its over $1,000 (I DID email them.)

    Give me a break. A GPS receiver is a hell of a lot less expensive.

    Competitive my tailfeathers.

    --
    Karl Denninger (karl@denninger.net)
    http://www.denninger.net

  19. Re: Driver Help?

    On 2007-06-13, Richard B. Gilbert wrote:

    > They say "Email or call us for a competitive price quote..."
    > Why do I always get nervous when someone says that? It generally means
    > "all the traffic will bear and then some!" I much prefer to deal with
    > someone who says, up front, "it's $1253.99 plus shipping from. . . ."
    > It saves us both a bit of time because there's no way I'm going to pay
    > that much. It might be different if I had a corporate sponsor but
    > nowadays it's strictly out of my pocket!


    Based on a quote I received 2 years ago I'd guess the current base price
    is in the ball park of $1200. An OCXO is extra...

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  20. Re: Driver Help?

    On 2007-06-13, Karl Denninger wrote:

    > Give me a break. A GPS receiver is a hell of a lot less expensive.
    >
    > Competitive my tailfeathers.


    There are some applications where GPS won't work (due to antenna siting
    restrictions); CDMA may be the best solution in those cases.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

+ Reply to Thread
Page 1 of 2 1 2 LastLast