[ntp:questions] ntpd on embedded risc

Unruh unruh-spam at physics.ubc.ca
Sat Feb 21 04:24:25 UTC 2009

cnm3332 at gmail.com writes:

>On Feb 19, 3:16=A0pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
>> cnm3... at gmail.com writes:
>> >On Feb 19, 11:32=3DA0am, Rob <nom... at example.com> wrote:
>> >> Unruh <unruh-s... at physics.ubc.ca> wrote:
>> >> > But a snapshot taken before the system has settled down to its long =
>> >m
>> >> > behaviour is especially useless. The way ntp works is that intially =
>> >> > takes a while to settle down to its long term behaviour. With PPS co=
>> >ol
>> >> > it usually settles down to usec offset but it takes of order of 10 h=
>> >s to
>> >> > do so. Thus snapshots taken long before that are especially useless.=
> If
>> >> > after 10 hours the system still has msec offsets from a PPS then the=
>re =3D
>> >is
>> >> > something seriously wrong.
>> >> He is not using a PPS in the sense that you are talking about.
>> >> He uses the PPS support in gpsd which is written in user space and
>> >> will settle to around 10us on a fast system that is not overloaded.
>> >> On a slow embedded board it may be different, I have no experience
>> >> with running gpsd on those.
>> >The server is not running all the time, and it used on platform that
>> >once
>> >booted, which need accurate time within minutes. =A0We already run these
>> Then do not use ntp. Its behaviour is converging to the correct time is
>> very very slow. It is a completely inappropriate tool for the requirement
>> that you have. chrony is much better.
>> >tools on a fast x86 machine, and it syncs very quickly and provides
>> >very
>> >good accuracy. =A0We are trying to migrate to the MOXA board, but
>> >performance is much poorer. =A0I was more curious about things I could
>> >configure so that NTP would be usable on this slower machine, even if
>> >it took longer to get stable. =A0Should I look into increasing baud rate
>> >of
>> >serial, less polling interval, etc? =A0The linux distro is very small,
>> It is the algorithm that is at fault, not the machine. (well, the machine
>> may also be at fault, but the algorithm simply cannot supply the accuracy
>> you wish at the speed you want it).
>> >and provides
>> >practically no tools, I'm not even sure how loaded the processor
>> >becomes
>> >with gpsd and ntpd. =A0Is there an effective way of checking that it is
>> >not
>> >too much for machine? =A0Thanks.
>> ps
>> top
>> Anyway, it isnot too much. Far far slower machines can handle it.

>We have been using NTP for long time, and it always converged to
>sub millisecond accuracy very quickly.  Of course we used burst
>and iburst options in conf file, but I had disabled those on MOXA
>board, out of worries about CPU usage.  I would say our
>requirements are at least 100usec accuracy for time, and that it
>synchronize within 5 minutes.  NTP on our fast x86 machine

Youwill not get that from ntp. Mills has explicitely stated that he is
completely uninterested in any questin of speed of convergence of ntp. For
him the slow convergence is a feature, not a bug.

>always satisifed this, but having trouble on MOXA board.

>I was not aware of other programs for this purpose.  I'm guessing
>chrony can act as NTP server for other machines running NTP
>to get time from?  Does it provide level of accuracy and
>convergence time required?

Ye, Yes. BUT. It cannot ( yet) get its time from a hardware clock (eg PPS).
I have been meaning to try to add that but I am busy doing my physics, and
a bit scared about messing up since I do not have that much faith in my
coding skills, or in roperly designing the interface to a=a hardware clock
in chrony.

>The data was collected after about 30 minutes I believe.  I guess
>I'm so used to super fast convergence, that 30 minutes seemed
>like long time.

Wait 10 hours and then look at the data. ntp is espeically intollerant of
rate errors. Recent linux kernels have a bug in their tsc calibration
routines and will make 50PPM errors in the clock rate on bootup. ntp takes
about 8-10 hours to correct these errors (experimental evidence).

>Thanks for tip on uptime/ ps ax will try.  Doesn't have top program
>built in, may try compiling it if first method doesnt work out. Thanks
>for the help so far, much appreciated.

More information about the questions mailing list