[ntp:questions] NTP on CubieBoard

Rob nomail at example.com
Tue Oct 14 13:01:09 UTC 2014


Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
> 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.

I would think a sleep would end when an interrupt occurs...

>> 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.

That is why I asked my question.

>>> 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.

Ok so I have tried it on a CubieBoard2 that for now is connected only
to network, not PPS yet.
I compiled ntp-dev and the results look not too bad:

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.7p448 at 1.2483-o Tue Oct 14 11:13:59 UTC 2014 (1)",
processor="armv7l", system="Linux/3.4.79-sun7i", leap=00, stratum=2,
precision=-19, rootdelay=2.071, rootdisp=22.273, refid=192.168.1.8,
reftime=d7e79b76.5cb090cb  Tue, Oct 14 2014 12:54:14.362,
clock=d7e79cc8.d6eb7bc3  Tue, Oct 14 2014 12:59:52.839, peer=18810, tc=6,
mintc=3, offset=0.278662, frequency=-14.087, sys_jitter=10.790207,
clk_jitter=4.872, clk_wander=0.413

the timeserver now is via WiFi which causes some jitter, the next thing
is to try to connect the GPSDO and see how it fares with PPS.

>>> 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.

The application is a receiver and/or a transmitter.  This is not related
to ntpd itself.  For a receiver we can get away with 1-10ms accuracy,
which as shown above will be OK when the network is local.

For a transmitter we do require better than 10us accuracy.  This is possible
on a PC, we have to see if it will work on the CubieBoard.



More information about the questions mailing list