Question to NTP developers - NTP

This is a discussion on Question to NTP developers - NTP ; Eugen, You don't need a level converter. Compile the kernel with options PPS_SYNC device pps and connect the PPS signal to the parallel port ACK pin (I forget which pin). Configure MINPOLL and MAXPOLL for 4. Use the fudge time1 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: Question to NTP developers

  1. Re: Question to NTP developers

    Eugen,

    You don't need a level converter. Compile the kernel with

    options PPS_SYNC
    device pps

    and connect the PPS signal to the parallel port ACK pin (I forget which
    pin). Configure MINPOLL and MAXPOLL for 4. Use the fudge time1 option to
    wiggle the serial timecode offset close to the PPS offset. I do that
    here with two servers and find them within 30 microseconds of true tick.

    The ATOM driver is useful to reduce residual jitter and as a means for
    fudge.

    Dave

    Eugen COCA wrote:
    > David L. Mills wrote:
    >
    >>Eugen,
    >>
    >>Are you using the PPS driver (22)?

    >
    >
    > Dave,
    >
    > No, I have FreeBSD and I use PPS to discipline the kernel.
    >
    > I made in this morning a change, and I use now the 22 driver and see is
    > there are any differences form the previous situation. I must think to
    > use a MAX232 and an inverter to generate true RS232 levels (as the
    > inverter will add some delay and, I'm sure, a small portion of jitter
    > due to it's own 5V supply and MAX232 internal +/- 10V inverters).
    >
    > I made a temperature stabilization of one of the servers mainboard
    > crystal, and the results are quite encouraging. After all, I'm decided
    > to buy this year a Rb box, to see if there are any changes !
    >


  2. Re: Question to NTP developers

    Dave,

    I have already compiled the kernels with these options. I used FreeBSD
    kernel time discipline until now, with this ntpd.conf:

    server 127.127.20.1 minpoll 6 maxpoll 6 prefer
    fudge 127.127.20.1 flag3 1 time1 0.000

    >From today morning at 11 o'clock local time, I changed the

    configuration to see what's happening:

    server 127.127.20.1 minpoll 6 maxpoll 6 prefer
    fudge 127.127.20.1 flag3 0 time1 0.000

    server 127.127.22.1 minpoll 4 maxpoll 4
    fudge 127.127.22.1 flag3 0 time1 0.000

    Now, I have no pps sync disabled message, but I have *a lot* of:

    Aug 25 20:03:40 ntp1 ntpd[49227]: kernel time sync enabled 2301
    Aug 25 20:03:58 ntp1 ntpd[49227]: kernel time sync enabled 2101

    from 5 to 30 per hour !

    The results seems to be better than before:

    https://ecoca.eed.usv.ro/mrtg/time_s..._internet.html

    Are there long term statistics collected somewhere ? With ntpdc/dmpeers
    I can see:

    remote local st poll reach delay offset disp
    ================================================== =====================
    ..GPS_NMEA(1) 127.0.0.1 0 64 377 0.00000 0.000000 0.03076
    ntp3.usv.ro 80.96.120.253 1 64 377 0.00046 0.000016 0.03291
    GPS-1.MIT.EDU 80.96.120.253 1 256 377 0.14668 0.000830 0.13341
    ..ntp2.usv.ro 80.96.120.253 1 64 377 0.00026 -0.000005 0.05095
    gps-2.mit.edu 80.96.120.253 1 256 377 0.14603 0.000258 0.09396
    ptbtime1.ptb.de 80.96.120.253 1 256 377 0.04810 -0.001051 0.11606
    ptbtime2.ptb.de 80.96.120.253 1 256 277 0.04805 0.000228 0.11227
    *PPS(1) 127.0.0.1 0 16 377 0.00000 0.000000 0.01576
    ntp-p1.obspm.fr 80.96.120.253 1 256 377 0.06244 0.002924 0.10201
    ntps1-1.cs.tu-b 80.96.120.253 1 256 277 0.05400 -0.000325 0.07597


  3. Re: Question to NTP developers

    Eugen,

    It's not a good idea to use ntpdc for precision comparisons; ntpq is
    much more useful and truthful.

    The display makes no sense. How is it that the GPS and PPS show huge
    jitter while the offsets are zero? Take a look with ntpq at
    rackety.udel.edu and note the offset and jitter. The jitter should
    settle down to the precision limit and the offset should not be much worse.

    Dave

    Eugen COCA wrote:
    > Dave,
    >
    > I have already compiled the kernels with these options. I used FreeBSD
    > kernel time discipline until now, with this ntpd.conf:
    >
    > server 127.127.20.1 minpoll 6 maxpoll 6 prefer
    > fudge 127.127.20.1 flag3 1 time1 0.000
    >
    >>From today morning at 11 o'clock local time, I changed the

    > configuration to see what's happening:
    >
    > server 127.127.20.1 minpoll 6 maxpoll 6 prefer
    > fudge 127.127.20.1 flag3 0 time1 0.000
    >
    > server 127.127.22.1 minpoll 4 maxpoll 4
    > fudge 127.127.22.1 flag3 0 time1 0.000
    >
    > Now, I have no pps sync disabled message, but I have *a lot* of:
    >
    > Aug 25 20:03:40 ntp1 ntpd[49227]: kernel time sync enabled 2301
    > Aug 25 20:03:58 ntp1 ntpd[49227]: kernel time sync enabled 2101
    >
    > from 5 to 30 per hour !
    >
    > The results seems to be better than before:
    >
    > https://ecoca.eed.usv.ro/mrtg/time_s..._internet.html
    >
    > Are there long term statistics collected somewhere ? With ntpdc/dmpeers
    > I can see:
    >
    > remote local st poll reach delay offset disp
    > ================================================== =====================
    > .GPS_NMEA(1) 127.0.0.1 0 64 377 0.00000 0.000000 0.03076
    > ntp3.usv.ro 80.96.120.253 1 64 377 0.00046 0.000016 0.03291
    > GPS-1.MIT.EDU 80.96.120.253 1 256 377 0.14668 0.000830 0.13341
    > .ntp2.usv.ro 80.96.120.253 1 64 377 0.00026 -0.000005 0.05095
    > gps-2.mit.edu 80.96.120.253 1 256 377 0.14603 0.000258 0.09396
    > ptbtime1.ptb.de 80.96.120.253 1 256 377 0.04810 -0.001051 0.11606
    > ptbtime2.ptb.de 80.96.120.253 1 256 277 0.04805 0.000228 0.11227
    > *PPS(1) 127.0.0.1 0 16 377 0.00000 0.000000 0.01576
    > ntp-p1.obspm.fr 80.96.120.253 1 256 377 0.06244 0.002924 0.10201
    > ntps1-1.cs.tu-b 80.96.120.253 1 256 277 0.05400 -0.000325 0.07597
    >


  4. Re: Question to NTP developers

    David L. Mills wrote:
    > Eugen,
    >
    > It's not a good idea to use ntpdc for precision comparisons; ntpq is
    > much more useful and truthful.
    >
    > The display makes no sense. How is it that the GPS and PPS show huge
    > jitter while the offsets are zero? Take a look with ntpq at
    > rackety.udel.edu and note the offset and jitter.


    Dave,

    on the best of my servers, ntpq/pe looks like:

    remote local st poll reach delay offset disp
    ================================================== =====================
    =GPS_NMEA(1) 127.0.0.1 0 64 377 0.00000 -0.000000 0.03049
    =ntp3.usv.ro 80.96.120.253 1 64 377 0.00049 0.000053 0.04402
    =gps-1.mit.edu 80.96.120.253 1 256 377 0.14613 0.000446 0.12549
    =ntp2.usv.ro 80.96.120.253 1 64 377 0.00026 -0.000012 0.06828
    =gps-2.mit.edu 80.96.120.253 1 256 377 0.14575 0.000113 0.10460
    =ptbtime1.ptb.de 80.96.120.253 1 256 377 0.04861 -0.001742 0.10022
    =ptbtime2.ptb.de 80.96.120.253 1 256 377 0.04829 0.000012 0.11932
    *PPS(1) 127.0.0.1 0 16 377 0.00000 -0.000000 0.01567
    =ntp-p1.obspm.fr 80.96.120.253 1 256 377 0.05722 0.000721 0.09496
    =ntps1-1.cs.tu-b 80.96.120.253 1 256 357 0.05438 -0.000242 0.09479


    and at the server you indicated is:

    remote local st poll reach delay offset disp
    ================================================== =====================
    =239.1.1.1 128.4.1.1 16 64 0 0.00000 0.000000 4.00000
    =SPECTRACOM(1) 127.0.0.1 0 64 377 0.00000 -0.000007 0.03073
    *PPS(0) 127.0.0.1 0 16 377 0.00000 -0.000008 0.01608
    =mizbeaver.udel. 128.4.1.1 1 64 377 0.00410 -0.000018 0.05716

    I must run the servers with kernel sync disabled in order to see the
    differences between the to situation: kernel PPS or driver 22. I wonder
    if it make sense to put "flag3 1" - enable kernel pps in the line for
    the 22 driver, say "127.127.22.1 flag3 1" ?


  5. Re: Question to NTP developers

    Eugen,

    I say for the >third< time: the ntpdc billboards are misleading and
    wrong. See the ntpq billboards with truthful tally codes and jitter
    estimates. The GPS and PPS offsets you claim are zero, which is very
    rarely the case in normal operation. Remember, at least some NMEA
    drivers do the PPS thing internally and do not rely on the atom driver.
    In such cases you are completely on your own and any errant behavior
    should be reported to the driver author.

    Dave

    Eugen COCA wrote:
    > David L. Mills wrote:
    >
    >>Eugen,
    >>
    >>It's not a good idea to use ntpdc for precision comparisons; ntpq is
    >>much more useful and truthful.
    >>
    >>The display makes no sense. How is it that the GPS and PPS show huge
    >>jitter while the offsets are zero? Take a look with ntpq at
    >>rackety.udel.edu and note the offset and jitter.

    >
    >
    > Dave,
    >
    > on the best of my servers, ntpq/pe looks like:
    >
    > remote local st poll reach delay offset disp
    > ================================================== =====================
    > =GPS_NMEA(1) 127.0.0.1 0 64 377 0.00000 -0.000000 0.03049
    > =ntp3.usv.ro 80.96.120.253 1 64 377 0.00049 0.000053 0.04402
    > =gps-1.mit.edu 80.96.120.253 1 256 377 0.14613 0.000446 0.12549
    > =ntp2.usv.ro 80.96.120.253 1 64 377 0.00026 -0.000012 0.06828
    > =gps-2.mit.edu 80.96.120.253 1 256 377 0.14575 0.000113 0.10460
    > =ptbtime1.ptb.de 80.96.120.253 1 256 377 0.04861 -0.001742 0.10022
    > =ptbtime2.ptb.de 80.96.120.253 1 256 377 0.04829 0.000012 0.11932
    > *PPS(1) 127.0.0.1 0 16 377 0.00000 -0.000000 0.01567
    > =ntp-p1.obspm.fr 80.96.120.253 1 256 377 0.05722 0.000721 0.09496
    > =ntps1-1.cs.tu-b 80.96.120.253 1 256 357 0.05438 -0.000242 0.09479
    >
    >
    > and at the server you indicated is:
    >
    > remote local st poll reach delay offset disp
    > ================================================== =====================
    > =239.1.1.1 128.4.1.1 16 64 0 0.00000 0.000000 4.00000
    > =SPECTRACOM(1) 127.0.0.1 0 64 377 0.00000 -0.000007 0.03073
    > *PPS(0) 127.0.0.1 0 16 377 0.00000 -0.000008 0.01608
    > =mizbeaver.udel. 128.4.1.1 1 64 377 0.00410 -0.000018 0.05716
    >
    > I must run the servers with kernel sync disabled in order to see the
    > differences between the to situation: kernel PPS or driver 22. I wonder
    > if it make sense to put "flag3 1" - enable kernel pps in the line for
    > the 22 driver, say "127.127.22.1 flag3 1" ?
    >


  6. Re: Question to NTP developers

    Sorry - three time sorry - due to speed I misstyped ...

    Here are the numbers reported by ntpq on my best server:

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    +GPS_NMEA(1) .GPS. 0 l 42 64 377 0.000 0.000
    0.004
    -ptbtime1.ptb.de .PTB. 1 u 220 256 377 48.516 -0.772
    0.381
    -ntps1-1.cs.tu-b .PPS. 1 u 237 256 375 54.191 0.039
    1.023
    -ntp-p1.obspm.fr .1PPS. 1 u 199 256 377 55.164 -0.540
    1.607
    -gps-2.mit.edu .GPS. 1 u 229 256 377 147.056 0.018
    1.822
    oPPS(1) .PPS. 0 l 9 16 377 0.000 0.000
    0.004
    +ntp2.usv.ro .PPS. 1 u 61 64 377 0.273 -0.008
    0.036
    -ntp3.usv.ro .PPS. 1 u 19 64 377 0.509 0.036
    0.014
    -ptbtime2.ptb.de .PTB. 1 u 217 256 377 48.336 -0.307
    0.350
    -gps-1.mit.edu .GPS. 1 u 217 256 377 147.112 -0.037
    0.342


  7. Re: Question to NTP developers

    Eugen,

    The data for all servers except your GPS and PPS show nominal behavior
    similar to the behavior observed here. The jitter for your serial
    timecode and PPS both show 4 us, which is limited by the precision. So
    far, no surprises. Hoever, your serial timecode and PPS offsets both
    show zero, which is not

    Dave

    Eugen COCA wrote:
    > Sorry - three time sorry - due to speed I misstyped ...
    >
    > Here are the numbers reported by ntpq on my best server:
    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > +GPS_NMEA(1) .GPS. 0 l 42 64 377 0.000 0.000
    > 0.004
    > -ptbtime1.ptb.de .PTB. 1 u 220 256 377 48.516 -0.772
    > 0.381
    > -ntps1-1.cs.tu-b .PPS. 1 u 237 256 375 54.191 0.039
    > 1.023
    > -ntp-p1.obspm.fr .1PPS. 1 u 199 256 377 55.164 -0.540
    > 1.607
    > -gps-2.mit.edu .GPS. 1 u 229 256 377 147.056 0.018
    > 1.822
    > oPPS(1) .PPS. 0 l 9 16 377 0.000 0.000
    > 0.004
    > +ntp2.usv.ro .PPS. 1 u 61 64 377 0.273 -0.008
    > 0.036
    > -ntp3.usv.ro .PPS. 1 u 19 64 377 0.509 0.036
    > 0.014
    > -ptbtime2.ptb.de .PTB. 1 u 217 256 377 48.336 -0.307
    > 0.350
    > -gps-1.mit.edu .GPS. 1 u 217 256 377 147.112 -0.037
    > 0.342
    >


  8. Re: Question to NTP developers

    > The jitter for your serial
    > timecode and PPS both show 4 us, which is limited by the precision. So
    > far, no surprises. Hoever, your serial timecode and PPS offsets both
    > show zero, which is not


    Dave,

    The serial offset captured with ntpq and represented with mrtg are:

    For the best server - ntp1 (Intel PII/366MHz - brand Fujitsu)

    https://ecoca.eed.usv.ro/mrtg/ntp1usvro_offset.html

    and, a zoom-ed version of the same graph

    https://ecoca.eed.usv.ro/mrtg/ntp1usvro_offset_10.html

    For the second server - ntp2 (AMD K6III/400MHz - no brand)

    https://ecoca.eed.usv.ro/mrtg/ntp2usvro_offset.html

    For the third one - ntp3 (Intel P1/200MHz - no brand)

    https://ecoca.eed.usv.ro/mrtg/ntp3usvro_offset.html


    I made (at the end of June 2006) for the second server ntp2 a
    temperature oven for the 14MHz crystal on the motherboard (a basic
    circuit as for an OCXO) and the graph looks better (it loocked as the
    graph for ntp3).

    The yesterday steps in the graphs 2 and 3 at 8 o'clock and 11 o'clock
    are due to switching off and respectivelly on the air conditioning in
    the lab - an experiment to see if Kernel PPS is better than driver 22.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2