[ntp:questions] NTP on CubieBoard
Brian.Inglis at SystematicSw.ab.ca
Tue Oct 14 09:13:15 UTC 2014
On 2014-10-14 01:30, Rob wrote:
> Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
>> The SoC implementation seems to be an AllWinner Technology A20
>> designed for low power mobile uses.
>> There is a lack of tech docs about these implementations available.
>> When I see low power mobile, I expect power and speed throttling,
>> so usability for NTP will depend on how well you can disable those
>> features to run with power always on.
> It does not really matter if the CPU is sleeping, as long as it can
> wakeup on an interrupt quickly and as long as there is a real time
> counter (e.g. a clock cycle counter) that ticks at a constant rate.
I am not talking here about wait states, I am talking about variable
frequency/voltage sleep states used to conserve power.
The problem with sleep states is that they delay all interrupt handling
inconsistently and vary clock rates so ntpd will be unable to estimate the
system frequency drift and network delay to get a reasonable offset because
of high jitter.
> The only thing required to run realtime is an interrupt routine that
> reads the content of the highres timing counter when an input line
> changes state. All the other things can run at kernel and user level
> at varying speed and priority, and the result will still be good.
You would think so, but experience in this forum indicates otherwise with ntpd.
It's easy on PCs because most chips now support invariant TSCs, and you can
disable all power saving features either in the BIOS or in the OS, but those
capabilities may not be available in many SoC cores.
>> But there is a reference to enabling Cubian Kernel PPS.
>> Whether that works or well seems to be answerable only by buy it and try it.
> I will do the experiment, indeed I see that PPS is enabled in the config
> after some change so maybe it works out of the box.
>> You may be better targeting a non-mobile platform or one of the Intel
>> embedded Linux boards designed to address the plethora of ARM boards.
> The fact that is is low-power helps us. But we need to keep the clock
> accurate. When this is not achievable we can still use the board for
> only a receiver, but not for a transmitting station.
Whether ntpd works depends on how consistent all the interrupts and clock
rates are, and the role of server or client plays no part; unless you are
referring to an application use that does not require accurate system clocks.
Take care. Thanks, Brian Inglis
More information about the questions