[ntp:questions] Re: Time sync over bad modem line
belus at petra.hos.u-szeged.hu
Thu Oct 28 07:42:46 UTC 2004
> 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?
Well, as usual, the most accuracy possible for the least money.
(12 hours costs simply too much)
> >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.
Good news. So, roughly speaking, the ping times show the accuracy (?).
> 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
Plus-minus 100 ms is OK for me.
I'll try to combine this solution with the one that Harlan Stenn
recommended (local clock with high stratum and dyn. ip and dynamic
reconfiguration + burst, but it's likely that burst wont work because
I don't permissions for this).
By the way, which ntp servers do you recommend for me?
(I'm in Hungary and I know only one: time.kfki.hu)
> 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. . . .
Thank you for your help. During this weekend I test these tricks.
Und danke sehr.
More information about the questions