[ntp:questions] syncing two machines, microsecond precision?
Dan B. Phung
phung at cs.columbia.edu
Wed Dec 5 20:06:19 UTC 2007
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:
<iteration> <server - client> <server - client - server>
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 at 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
More information about the questions
mailing list