TimeStamp - NTP

This is a discussion on TimeStamp - NTP ; Dear all, I'm very confused on how ntp do the timestamp. I'm running ntpd on vxworks. It seems to me that the receive timestamp and the Transmit timestamp are using two different clocks, because when I use ethereal/ wireshark to ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: TimeStamp

  1. TimeStamp

    Dear all,
    I'm very confused on how ntp do the timestamp. I'm running ntpd on
    vxworks. It seems to me that the receive timestamp and the Transmit
    timestamp are using two different clocks, because when I use ethereal/
    wireshark to look up the information of the ntp packet,
    the Recevie Time Stamp is: Jan 1, 1970 00:21:26.0827 UTC
    the Transmit Time Stamp is : Oct 29, 2007 15:20:30.1500 UTC

    However, the actual time period between these two time stamps is only
    a couple second apart. It makes me think that they are using to
    different clock to stamp the packet. Am I Right???

    Kevin


  2. Re: TimeStamp


    >I'm very confused on how ntp do the timestamp. I'm running ntpd on
    >vxworks. It seems to me that the receive timestamp and the Transmit
    >timestamp are using two different clocks, because when I use ethereal/
    >wireshark to look up the information of the ntp packet,
    >the Recevie Time Stamp is: Jan 1, 1970 00:21:26.0827 UTC
    >the Transmit Time Stamp is : Oct 29, 2007 15:20:30.1500 UTC
    >
    >However, the actual time period between these two time stamps is only
    >a couple second apart. It makes me think that they are using to
    >different clock to stamp the packet. Am I Right???


    It looks like a bug in the Receive timestamp code.

    (That's assuming your clock is within a day or so.)

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


  3. Re: TimeStamp

    On Oct 30, 3:51 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
    Murray) wrote:
    > >I'm very confused on how ntp do the timestamp. I'm running ntpd on
    > >vxworks. It seems to me that the receive timestamp and the Transmit
    > >timestamp are using two different clocks, because when I use ethereal/
    > >wireshark to look up the information of the ntp packet,
    > >the Recevie Time Stamp is: Jan 1, 1970 00:21:26.0827 UTC
    > >the Transmit Time Stamp is : Oct 29, 2007 15:20:30.1500 UTC

    >
    > >However, the actual time period between these two time stamps is only
    > >a couple second apart. It makes me think that they are using to
    > >different clock to stamp the packet. Am I Right???

    >
    > It looks like a bug in the Receive timestamp code.
    >
    > (That's assuming your clock is within a day or so.)
    >
    > --
    > These are my opinions, not necessarily my employer's. I hate spam.


    I don't know think it's a bug, because when both the server and the
    client are Windows. NTP runs perfectly fine. Just something wrong with
    VxWorks.


  4. Re: TimeStamp


    >> It looks like a bug in the Receive timestamp code.


    >I don't know think it's a bug, because when both the server and the
    >client are Windows. NTP runs perfectly fine. Just something wrong with
    >VxWorks.


    I was trying to suggest a bug in the vxworks receive timestamp code.

    I could have misinterpreted your initial data.

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


  5. Re: TimeStamp

    Aggie wrote:
    > Dear all,
    > I'm very confused on how ntp do the timestamp. I'm running ntpd on
    > vxworks. It seems to me that the receive timestamp and the Transmit
    > timestamp are using two different clocks, because when I use ethereal/
    > wireshark to look up the information of the ntp packet,
    > the Recevie Time Stamp is: Jan 1, 1970 00:21:26.0827 UTC
    > the Transmit Time Stamp is : Oct 29, 2007 15:20:30.1500 UTC
    >
    > However, the actual time period between these two time stamps is only
    > a couple second apart. It makes me think that they are using to
    > different clock to stamp the packet. Am I Right???
    >
    > Kevin
    >


    I don't know much about VxWorks, but if it supports the SO_TIMESTAMP
    socket option, then ntpd will use it to get the receive timestamp.
    However, the transmit timestamp will be retrieved via the gettimeofday
    system call. I don't think that it would be too hard to believe that
    VxWorks is using an uptime counter rather than the timeofday clock
    to provide the timestamp. If you set the debug level of ntpd to 4,
    it will print out the timestamp associated with a packet in a message
    that begins "fetch_timestamp". This value is the raw seconds and
    microseconds before the correction to 1970. If this value is near
    zero or rather near the uptime in seconds, then I think that would
    amount to a smoking gun.

    Brian Utterback

  6. How do I know my GPS-based NTP server is actuallyworking properly?

    Yes, I know this sounds weird. I've successfully set up my NTP server:
    an old 850MHz P3 box running FreeBSD 6.2-STABLE (kernel built with
    option PPS_SYNC), and a Garmin GPS-18LVC "hokey puck", powered off the
    USB port, with its PPS wire connected to the serial port's DCD line (pin
    1 on the DB9 connector). /etc/ntp.conf reads:

    server 127.127.20.1 mode 1 prefer
    fudge 127.127.20.1 time1 0.000 flag3 1 refid PPS

    So far so good. It seems to be keeping time and synchronizing to GPS.
    But...

    What's the proper way of telling whether the PPS signal is actually
    having an effect? That is, what behavior/measurements would show me
    that the PPS signal is or is not being used? What should I be monitoring
    (my guess would be "offset" and "jitter" from the netq -c rv output),
    and what kind of statistical analysis would tell me whether PPS is or is
    not being used?

    Thanks,

    /ji

    PS: the easy way to disable the use of the PPS signal is to set flag3 to
    0, right? Reloading a kernel and rebooting is a bit of a pain on
    antiquated hardware.

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

    > Date: Wed, 31 Oct 2007 13:19:46 -0400
    > From: John Ioannidis
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > Yes, I know this sounds weird. I've successfully set up my NTP server:
    > an old 850MHz P3 box running FreeBSD 6.2-STABLE (kernel built with
    > option PPS_SYNC), and a Garmin GPS-18LVC "hokey puck", powered off the
    > USB port, with its PPS wire connected to the serial port's DCD line (pin
    > 1 on the DB9 connector). /etc/ntp.conf reads:
    >
    > server 127.127.20.1 mode 1 prefer
    > fudge 127.127.20.1 time1 0.000 flag3 1 refid PPS
    >
    > So far so good. It seems to be keeping time and synchronizing to GPS.
    > But...
    >
    > What's the proper way of telling whether the PPS signal is actually
    > having an effect? That is, what behavior/measurements would show me
    > that the PPS signal is or is not being used? What should I be monitoring
    > (my guess would be "offset" and "jitter" from the netq -c rv output),
    > and what kind of statistical analysis would tell me whether PPS is or is
    > not being used?
    >
    > Thanks,
    >
    > /ji
    >
    > PS: the easy way to disable the use of the PPS signal is to set flag3 to
    > 0, right? Reloading a kernel and rebooting is a bit of a pain on
    > antiquated hardware.


    On FreeBSD for PPS you want something like this:
    server 127.127.5.1 prefer minpoll 4 maxpoll 4
    fudge 127.127.5.1 time1 .010
    server 127.127.22.1 minpoll 4 maxpoll 4

    You will probably want to add a time fudge once you see how much the
    processing delays the update of the data from the GPS. It is variable,
    depending on the speed of the system, but probably around .01 sec.

    For connected reference clocks the minpoll and maxpoll should be short,
    hence the value of '4'.

    The refid should be 'GPS', not 'PPS'. (Actually, it shouldn't be needed
    at all. It should default to GPS.)

    Once you have PPS configured, you should see:
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    +NMEA GPS(1) .GPS. 0 l 4 16 377 0.000 0.190 1.929
    oPPS(1) .PPS. 0 l 12 16 377 0.000 0.005 0.002

    I'm guessing on the content of the 'remote' field for clock 20.

    The 'o' on the PPS line indicates that it is 'training' the value of the
    associated clock.

    Make sure that your ntpd is built to include the needed drivers. By
    default FreeBSD does not build the drivers. You need to re-build ntpd
    with CLOCK_NMEA defined.
    --
    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

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

    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).

    Cheers,

    /ji

  9. Re: How do I know my GPS-based NTP server isactuallyworking properly?

    > What's the proper way of telling whether the PPS signal is actually
    > having an effect? That is, what behavior/measurements would show me
    > that the PPS signal is or is not being used? What should I be monitoring
    > (my guess would be "offset" and "jitter" from the netq -c rv output),
    > and what kind of statistical analysis would tell me whether PPS is or is
    > not being used?


    Did you connect the data lines too? To receive the NMEA info, or just the
    PPS line?

    You don't need to run a separate config for the PPS as PPS support is built
    into the NMEA driver.

    Run 'ntptime' and 'ntpq -c rv' for more info on what's going on... If your
    root dispersion is less than 1 then it's working. Also the refid should tell
    you the source.

    As others have suggested set your minpoll & maxpoll to 4 for the driver.
    Also you might want / need to disable the FIFO for better stability / lower
    jitter:

    http://support.ntp.org/bin/view/Supp...HardwareIssues

    > PS: the easy way to disable the use of the PPS signal is to set flag3 to
    > 0, right? Reloading a kernel and rebooting is a bit of a pain on
    > antiquated hardware.


    'flag 3' is only a switch that lets you choose between the kernel's hard pps
    (if you rebuilt your kernel with the appropriate options), or to use NTP's
    built into disciplining (which filters longer and does other magic). There's
    a big debate as to which works better and die hard fans on both sides, you
    can try it both ways and see what works best for you.

    There is no way to disable the PPS signal itself via any software switch, if
    it's present on the line then its used.

    Easiest thing would be to use just the generic kernel and ntp's filtering
    (no fudge flags needed, though you might need to specify a time fudge due to
    processing / cable delays.)

    If you are familiar with NTP on linux then I'm sure you have run 'ntpstat'.
    I took the source and made a couple little modifications to get it to
    compile on FreeBSD (also just finding the source was a treasure hunt in
    itself)... You can download it from:

    http://files.extremeoverclocking.com/file.php?f=193

    I've been meaning to make it a little more robust and fix some little issues
    with the program, but it should do the job. It's a little more convient than
    running other commands and deciphering all the raw info.

  10. Re: How do I know my GPS-based NTP server is actually working properly?

    John Ioannidis wrote:
    > 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).
    >
    > Cheers,
    >
    > /ji


    John,

    There is information on how I monitor here:

    http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html

    The GPS-locked accuracy is some three orders or magnitude better than
    Internet only. Compare the top graph (+/- 20 microseconds) and the lower
    graphs (+/- 100 milliseconds). In my particular case, with a limited view
    of the sky from quite far north (56 degrees), The drift which starts when
    there are too few satellites to allow the GPS-18 to declare "lock" is very
    obvious. You could simulate that by disconnecting the GPS, of course. My
    simple notes are here:

    http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm

    Search for the word "pixie" to see the effect of PPS_SYNC, with extra
    lines in the "ntpdc -c kern" output.

    Cheers,
    David



+ Reply to Thread