[ntp:questions] NTP on CubieBoard
rick.jones2 at hp.com
Tue Oct 14 16:56:48 UTC 2014
Rob <nomail at example.com> wrote:
> 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...
I think the point Brian is trying to make here is that how long it
takes to "awaken" for the interrupt can and so will vary depending on
just how "deeply asleep" the processor gets in the name of power
saving. It may not be as "alseep" each time the interrupt
happens. Whether that matters for your specific situation will, I
suppose, depend on just how much jitter you can tolerate.
I don't interest myself in "why." I think more often in terms of
"when," sometimes "where;" always "how much." - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
More information about the questions