[ntp:questions] ntpd on embedded risc
unruh-spam at physics.ubc.ca
Wed Feb 18 21:16:01 UTC 2009
cnm3332 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=
>> > 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=
>> > it usually settles down to usec offset but it takes of order of 10 hour=
>> > 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 =
>> > 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
>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
>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
>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).
>practically no tools, I'm not even sure how loaded the processor
>with gpsd and ntpd. Is there an effective way of checking that it is
>too much for machine? Thanks.
Anyway, it isnot too much. Far far slower machines can handle it.
More information about the questions