NTP does not reply to IP addresses that start with 69 - NTP

This is a discussion on NTP does not reply to IP addresses that start with 69 - NTP ; hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes: >>>No. All you need is refclock_nmea (127.127.20.x) for a directly >>>connected NMEA device. Assuming that you're using a Linux kernel with >>>PPS-kit or a BSD kernel (or another kernel which directly supports PPS). >> >>OK, lets ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 44 of 44

Thread: NTP does not reply to IP addresses that start with 69

  1. Re: Setting up a NTP Time Server

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>>No. All you need is refclock_nmea (127.127.20.x) for a directly
    >>>connected NMEA device. Assuming that you're using a Linux kernel with
    >>>PPS-kit or a BSD kernel (or another kernel which directly supports PPS).

    >>
    >>OK, lets assume the kernel does NOT have the PPS support. Then what?


    >If you setup a NMEA refclock, it runs off the text strings
    >on the serial port. It works, it just doesn't keep as good
    >time as you normally get from PPS.


    Yes. I was wondering how to use the PPS output even if the kernel does not
    have pps support.

    There is the shm support.

    >How good depends on your GPS device. A lot of them have
    >a lot of jitter.


    The net ouput from a GArmin 18LVC into a Linux box, via my own interrupt
    routine, is about plus or minus 2usec ( that includes any jitter in the GPS
    pps signal, the clock reading jitter).
    I use my own parallel interrupt routine (based on the O'Reiley book by
    Alessandro Rubini and Jonathan Corbet "Linux Device Drivers"-- the short.c
    driver). which is read by an adapted shm driver.



    >You also get jitter from the OS (and serial port hardware).
    >There should be a simple recipe to minimize that. I haven't
    >seen one and several tries haven't produced anything that
    >I'd call good-enough. (When I run out of other things to
    >work on...)


    What is good enough?


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



  2. Re: Setting up a NTP Time Server


    >>You also get jitter from the OS (and serial port hardware).
    >>There should be a simple recipe to minimize that. I haven't
    >>seen one and several tries haven't produced anything that
    >>I'd call good-enough. (When I run out of other things to
    >>work on...)


    >What is good enough?


    Something I can easily measure.

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


  3. Re: Setting up a NTP Time Server

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>>You also get jitter from the OS (and serial port hardware).
    >>>There should be a simple recipe to minimize that. I haven't
    >>>seen one and several tries haven't produced anything that
    >>>I'd call good-enough. (When I run out of other things to
    >>>work on...)


    >>What is good enough?


    >Something I can easily measure.


    Well, apparently you can measure it-- "You also get jitter from the OS..."
    suggests that you measured something. But that is not good enough.

    The serial port I seem to recall has a worse behaviour of the interrupt
    than does the parallel port.
    But what you can do is a loopback-- put some output onto one of the output
    pins of the serial port which loops back into the interrupt port. timestamp
    the raising of the pin on the output and timestamp the interrupt and see by
    how much they differ. That of course measures only the total out-in time
    but it is an indication of how the serial interrupt works. do the same for
    the parallel port.


  4. Re: Setting up a NTP Time Server

    >>>What is good enough?
    >
    >>Something I can easily measure.

    >
    >Well, apparently you can measure it-- "You also get jitter from the OS..."
    >suggests that you measured something. But that is not good enough.


    I can easily see that it's much worse than I expect.

    What I haven't been able to get is clean results from tests
    before/after applying a fix.

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


+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3