syncing two machines, microsecond precision? - NTP

This is a discussion on syncing two machines, microsecond precision? - NTP ; Hi, I'm trying to sync two machines, one as the server the other as the client, both sitting on a private switched network. After ntp settles in, the client has a 10-30 ms offset that continues to increase in offset, ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: syncing two machines, microsecond precision?

  1. syncing two machines, microsecond precision?

    Hi, I'm trying to sync two machines, one as the server the other as the

    client, both sitting on a private switched network. After ntp settles

    in, the client has a 10-30 ms offset that continues to increase in

    offset, but what I'm doing requires the two machines to be off by no

    more than 500 us. I've gone through the NTP debug routine and my PPM

    error is pretty small (see below)

    also, what's the huffpuff filter, I didn't try playing with that yet,

    and can't find much info on the web about it.

    Below is some info to help assess my situation, please let me know if

    there's more info I can provide.

    thanks,
    dan

    -----
    server = larry
    client = moe

    server (larry) conf:

    driftfile /var/lib/ntp/ntp.drift
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable
    server 127.127.1.1
    fudge 127.127.1.1 stratum 10
    restrict 127.0.0.1
    restrict ::1


    client (moe) conf:

    driftfile /var/lib/ntp/ntp.drift
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable
    server larry
    restrict 127.0.0.1
    restrict ::1


    ------------
    debugging info on larry:

    ~ # ntptime
    ntp_gettime() returns code 0 (OK)
    time cb004960.061de000 Tue, Dec 4 2007 16:47:12.023, (.023893),
    maximum error 24726 us, estimated error 0 us
    ntp_adjtime() returns code 0 (OK)
    modes 0x0 (),
    offset 0.000 us, frequency 1.004 ppm, interval 1 s,
    maximum error 24726 us, estimated error 0 us,
    status 0x1 (PLL),
    time constant 10, precision 1.000 us, tolerance 512 ppm,

    ~ # ntpq
    ntpq> rv
    assID=0 status44 leap_none, sync_local_proto, 4 events,

    event_peer/strat_chg,
    version="ntpd 4.2.4p4@1.1520-o Tue Oct 23 17:25:12 UTC 2007 (1)",
    processor="i686", system="Linux/2.6.21", leap\0, stratum,
    precision=-20, rootdelay=0.000, rootdispersion.367, peer9206,
    refid=LOCAL(1),
    reftime╦004947.144f23a0 Tue, Dec 4 2007 16:46:47.079, poll,
    clock╦004963.b7a2147e Tue, Dec 4 2007 16:47:15.717, state=4,
    offset=0.000, frequency=1.004, jitter=0.001, noise=0.001,
    stability=0.000, tai=0

    ntpq> pe
    remote refid st t when poll reach delay offset

    jitter
    ================================================== ========================*LOCAL(1) .LOCL. 10 l 29 64 377 0.000 0.000

    0.001
    ntpq> as

    ind assID status conf reach auth condition last_event cnt
    ================================================== ======1 39206 9614 yes yes none sys.peer reachable 1

    ------------
    debugging info on moe:

    ~ # ntptime
    ntp_gettime() returns code 0 (OK)
    time cb004b5c.e72ed000 Tue, Dec 4 2007 16:55:40.903, (.903058),
    maximum error 385388 us, estimated error 0 us
    ntp_adjtime() returns code 0 (OK)
    modes 0x0 (),
    offset 0.000 us, frequency 17.752 ppm, interval 1 s,
    maximum error 385388 us, estimated error 0 us,
    status 0x1 (PLL),
    time constant 4, precision 1.000 us, tolerance 512 ppm,

    ntpq> pe
    remote refid st t when poll reach delay offset

    jitter
    ================================================== ========================*larry LOCAL(1) 11 u 6 64 377 0.175

    -15.448 5.771

    ntpq> as

    ind assID status conf reach auth condition last_event cnt
    ================================================== ======1 46763 9624 yes yes none sys.peer reachable 2

    ntpq> rv
    assID=0 statusĂ44 sync_alarm, sync_ntp, 4 events, event_peer/strat_ch
    g,
    version="ntpd 4.2.4p0@1.1472-o Thu Oct 4 22:22:31 UTC 2007 (1)",
    processor="x86_64", system="Linux/2.6.22-10-generic", leap,
    stratum, precision=-20, rootdelay=0.000, rootdispersion.880,
    peerF763, refid=´┐Ż;´┐Ż,
    reftime\0000000.00000000 Thu, Feb 7 2036 1:28:16.000, poll=6,
    clock╦004b8a.3864b86c Tue, Dec 4 2007 16:56:26.220, state=2,
    offset=0.000, frequency.752, jitter=5.771, noise=0.001,
    stability=0.000, tai=0

    ntpq> rv 46763
    assIDF763 statusľ24 reach, conf, sel_sys.peer, 2 events, event_reac
    h,
    srcadr=larry, srcport3, dstadr8.59.23.25,
    dstport3, leap\0, stratum, precision=-20, rootdelay=0.000,
    rootdispersion.658, refid=LOCAL(1), reach77, unreach=0, hmode
    =3,
    pmode=4, hpoll=6, ppoll=6, flash\0 ok, keyid=0, ttl=0, offset
    =-15.448,
    delay=0.175, dispersion=0.943, jitter=5.771,
    reftime╦004b4a.14380139 Tue, Dec 4 2007 16:55:22.078,
    org╦004b7b.9cbb8dfb Tue, Dec 4 2007 16:56:11.612,
    rec╦004b7b.a0b5b9bf Tue, Dec 4 2007 16:56:11.627,
    xmt╦004b7b.a0a813d8 Tue, Dec 4 2007 16:56:11.627,
    filtdelay= 0.18 0.19 0.15 0.18 0.16 0.17 0.18 0.
    17,
    filtoffset= -15.45 -14.14 -12.85 -11.58 -10.29 -8.99 -7.69 -6.
    44,
    filtdisp= 0.00 0.98 1.97 2.91 3.90 4.88 5.85 6.
    80

    ntpdc> loopinfo
    offset: 0.000000 s
    frequency: 17.752 ppm
    poll adjust: 4
    watchdog timer: 880 s

    ntpdc> sysinfo
    system peer: larry
    system peer mode: client
    leap indicator: 11
    stratum: 16
    precision: -20
    root distance: 0.00000 s
    root dispersion: 0.01321 s
    reference ID: []
    reference time: 00000000.00000000 Thu, Feb 7 2036 1:28:16.000
    system flags: bclient monitor ntp kernel stats
    jitter: 0.005783 s
    stability: 0.000 ppm
    broadcastdelay: 0.003998 s
    authdelay: 0.000000 s

  2. Re: syncing two machines, microsecond precision?

    Dan,

    Dan B. Phung wrote:
    > Hi, I'm trying to sync two machines, one as the server the other as the
    > client, both sitting on a private switched network. After ntp settles
    > in, the client has a 10-30 ms offset that continues to increase in
    > offset, but what I'm doing requires the two machines to be off by no
    > more than 500 us. I've gone through the NTP debug routine and my PPM
    > error is pretty small (see below)
    > also, what's the huffpuff filter, I didn't try playing with that yet,
    > and can't find much info on the web about it.
    > Below is some info to help assess my situation, please let me know if
    > there's more info I can provide.


    Can you tell us which operating systems and which versions of NTP you are
    running?

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: syncing two machines, microsecond precision?

    Martin Burnicki wrote:
    > Can you tell us which operating systems and which versions of NTP you are
    > running?


    Oops, sorry. Didn't see this info at the end of your original message.
    Thought below "---" was just a signature.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  4. Re: syncing two machines, microsecond precision?

    On 2007-12-04, Dan B. Phung wrote:

    > Hi, I'm trying to sync two machines, one as the server the other
    > as the client, both sitting on a private switched network. After
    > ntp settles in, the client has a 10-30 ms offset that continues to
    > increase in offset, but what I'm doing requires the two machines to be
    > off by no more than 500 us. I've gone through the NTP debug routine
    > and my PPM error is pretty small (see below) also, what's the huffpuff
    > filter, I didn't try playing with that yet, and can't find much info
    > on the web about it.
    >
    > Below is some info to help assess my situation, please let me know if
    > there's more info I can provide.


    > server (larry) conf:
    >
    > driftfile /var/lib/ntp/ntp.drift
    > statistics loopstats peerstats clockstats
    > filegen loopstats file loopstats type day enable
    > filegen peerstats file peerstats type day enable
    > filegen clockstats file clockstats type day enable
    > server 127.127.1.1
    > fudge 127.127.1.1 stratum 10
    > restrict 127.0.0.1
    > restrict ::1
    >


    You have not provided your server with a stable timebase. So you don't
    really know if the server clock is drifting slowly in one direction or
    the other or swinging back and forth. This may, or may not, contribute
    to the problem you're experiencing.

    BTW: Your restrict lines are meaningless (and harmless) since you have
    not defined a default restriction.

    > client (moe) conf:
    > server larry


    As an enhancement you could append 'iburst' to that server line to speed
    up initial sync.

    > debugging info on larry:


    [snip]

    >remote refid st t when poll reach delay offset jitter
    >================================================== ==============
    >*LOCAL(1) .LOCL. 10 l 29 64 377 0.000 0.000 0.001


    That looks normal.

    > debugging info on moe:


    [snip]

    >remote refid st t when poll reach delay offset jitter
    >================================================== ==============
    >*larry LOCAL(1) 11 u 6 64 377 0.175 -15.448 5.771


    Keep in mind that this is only a snap shot and conveys more information
    when compared with other peer status billboards over time.

    [snip]

    > clock╦004b8a.3864b86c Tue, Dec 4 2007 16:56:26.220, state=2,


    ntpd is not fully synchronised until the state equals 4.

    ntpd spends about 20 minutes training the clock at start up if no drift
    file is present. During this time you may observe the clock being slewed
    back and forth. You need to allow ntpd to run long enough (~ 1 hour) for
    a drift file to be created. Has a drift file been created on moe?

    The states are (taken from ./ntpd/ntp_loopfilter.c):

    #define S_NSET 0 /* clock never set */
    #define S_FSET 1 /* frequency set from the drift file */
    #define S_SPIK 2 /* spike detected */
    #define S_FREQ 3 /* frequency mode */
    #define S_SYNC 4 /* clock synchronized */

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

  5. Re: syncing two machines, microsecond precision?

    on moe (the client) I added the 'iburst dynamic' flags to the server
    line, restarted, and waited an hour. I checked the 'rv' state and after
    it reached state 4, I checked the peers every once in a while (see
    below). Notice that the offset somewhat settles to -0.509, but then it
    starts deviating again. This data is pasted below at the end of this
    message.

    In addition, I do a separate ping-like test between the server and
    client where I take the timestamp at the server (s1), send a message to
    the client, which then takes a timestamp (c1) and sends it to the
    server. upon receiving the reply from the client I take a final
    timestamp (s2).

    From these timestamps, s2-s1 = round-trip time, which for me is about
    200 microseconds. c1-s1 should be half the round-trip time, which
    should be around 100 microseconds, but seen here, is about 4000
    microseconds!

    format:

    0: s->c 4485 s->c->s 194
    1: s->c 4495 s->c->s 212
    2: s->c 4499 s->c->s 199
    3: s->c 4504 s->c->s 210
    4: s->c 4512 s->c->s 203
    5: s->c 4519 s->c->s 206
    6: s->c 4526 s->c->s 183
    7: s->c 4533 s->c->s 213
    8: s->c 4537 s->c->s 214
    9: s->c 4546 s->c->s 190

    lastly, i got frustrated and tried to pound the client into shape by
    running 'ntpdate larry' about 100 times. As I did this, I saw the
    offset go down steadily. I then just ran a simple loop where I ran
    'ntpdate larry' every 5 seconds, and tried my simple ping test again and
    got what I expected.

    0: s->c 101 s->c->s 192
    1: s->c 119 s->c->s 180
    2: s->c 134 s->c->s 203
    3: s->c 140 s->c->s 193
    4: s->c 83 s->c->s 210
    5: s->c 104 s->c->s 178
    6: s->c 121 s->c->s 206
    7: s->c 143 s->c->s 175
    8: s->c 141 s->c->s 210
    9: s->c 79 s->c->s 204

    So...running ntpdate every 5 seconds isn't my ideal solution, and I know
    that ntpd is designed to provide the expected behavior...if only I could
    configure it correctly!


    =================
    NTP debugging output below
    =================

    ntpq> rv
    assID=0 status=0654 leap_none, sync_ntp, 5 events, event_peer/strat_chg,
    version="ntpd 4.2.4p0@1.1472-o Thu Oct 4 22:22:31 UTC 2007 (1)",
    processor="x86_64", system="Linux/2.6.22-10-generic", leap=00,
    stratum=4, precision=-20, rootdelay=99.233, rootdispersion=69.730,
    peer=18957, refid=larry,
    reftime=cb017301.1409283d Wed, Dec 5 2007 13:57:05.078, poll=6,
    clock=cb0173be.4fbb0ba0 Wed, Dec 5 2007 14:00:14.311, state=4,
    offset=8.817, frequency=7.245, jitter=2.042, noise=2.766,
    stability=3.108, tai=0

    ntpq> pe
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    *larry 128.59.16.20 3 u 59 64 377 0.158 8.817 0.955
    ntpq> pe
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    *larry 128.59.16.20 3 u 121 128 377 0.160 8.107 1.517
    ntpq> pe
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    *larry 128.59.16.20 3 u 82 128 377 0.163 7.911 3.368
    ntpq> pe
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    *larry 128.59.16.20 3 u 121 128 377 0.162 -0.509 3.788
    ntpq> pe
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    *larry 128.59.16.20 3 u 118 128 377 0.157 -6.695 2.161


    thanks again, and please let me know if I can provide any more
    information. could it be a bad hardware clock? the client is a
    intel-based mac laptop running linux with ACPI disabled.

    -dan

+ Reply to Thread