[ntp:questions] ntpd on embedded risc

cnm3332 at gmail.com cnm3332 at gmail.com
Wed Feb 18 22:31:43 UTC 2009

On Feb 19, 3:16 pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
> cnm3... at gmail.com writes:
> >On Feb 19, 11:32=A0am, 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 ter=
> >m
> >> > behaviour is especially useless. The way ntp works is that intially it
> >> > takes a while to settle down to its long term behaviour. With PPS contr=
> >ol
> >> > it usually settles down to usec offset but it takes of order of 10 hour=
> >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 there =
> >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.  We 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.  We are trying to migrate to the MOXA board, but
> >performance is much poorer.  I 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.  Should I look into increasing baud rate
> >of
> >serial, less polling interval, etc?  The 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.  Is there an effective way of checking that it is
> >not
> >too much for machine?  Thanks.
> 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
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?

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.

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