[ntp:questions] Re: Time sync over bad modem line
Richard B. Gilbert
rgilbert88 at comcast.net
Thu Oct 28 02:54:04 UTC 2004
Nagy Bela wrote:
>Thanks for your help.
>>NTP cannot really synchronize your clock with an intermittent connection
>>of poor quality. What you can do is SET your clock whenever you connect
>>to the internet; ntpdate is good for this. One or two phone calls a
>>day could keep your clock within a few seconds of the correct time.
>What if the delay is over a second? Can ntpdate handle this?
>(Sometimes it happens.)
The error is bounded by the round trip delay. The time the server sent
you actually occurred somewhere in the interval between sending the
request and receiving the reply. Ideally, it would be found quite close
to the middle of the interval but the world is seldom ideal!
>>In order to work as designed, ntpd must query one or more (four are
>>good, five or more better) servers at intervals of, at most, 1024
>>seconds. The intervals normally start at 64 seconds and increase to
>>128, 256, 512, and 1024 seconds as the clock synchronizes. ntpd expects
>>a connection "on demand"; the delay involved in making a phone call each
>>time would introduce a ten or fifteen second error!
>Can I change this with maxpoll=minpoll=64 sec?
>Does it help anything?
Not much. Fifteen minutes is a very short interval in which to
synchronize a clock. I have watched a late model Compaq/HP PC (D530)
running Solaris 8 Intel Platform Edition synchronize to a local server
(500 microsecond delay). Fifteen minutes allowed only a crude
correction of the clock. After about 12 hours, the clock was as well
synchronized as it's ever likely to be and the time was within a 500
microseconds or so of the server.
>Because most of the time, this computer is connected to the net only for
>10-15 minutes and I would like to have my clock as accurate as possible.
How much accuracy do you need? How much are you willing to pay for?
>Or a "reverse" question: If my computer is connected to the net for,
>say, 15 minutes and we assume nothing about the line (i.e. several second
>long delay may occur and this delay may vary widely), then
>how accurately can ntp set my clock?
The error is bounded by the delay; it may be less than the delay but it
can't be worse.
The first thing you need to do is decide what accuracy is acceptable!
Must your clock be within 1 second, 100 milliseconds, 10 milliseconds, 1
millisecond . . . ?
With the required accuracy known, you can then select the technolgy
required to attain it! Within one second you can set it manually using
a broadcast time reference. For within 100 milliseconds you can set
your clock once per day with ntpdate or ntpd -g. For time within 10
milliseconds you will almost certainly need a continuous internet
connection and four or five servers, each with a round-trip delay of
less than 20 milliseconds. For time within one millisecond, you will
probably need a hardware reference clock. Und so weiter. . . .
More information about the questions