eport from the 20160501 F2

[Hal Murray]

[Context is "simple NTP broadcast client"]

> The primary target audience is IoT devices. Expect nothing impressive in
> terms of timekeeping precision.

I like the idea of a small/simple implementation.

There are 2 parts to a ntp client.  One is getting the time right.  The other 
is calibrating the local crystal so that the time stays close(er).  Are you 
planning to implement the drift?  Does the OS even support the idea?  (It's 
not hard, but may take some double precision arithmetic.)

One of the advantages of all the complexity of ntpd is that you can monitor 
and debug things.  The builtin server allows monitoring even without logging 
anything on the target machine.

How are people going to monitor/debug IoT devices?

---------

Drift correction gets complicated in seriously low power environments.  The 
trick is that there are usually two clocks used for timekeeping.  The normal 
CPU clock is used while the CPU is powered up, but the RTC/TOY clock is used 
when the CPU is powered off.  We probably need 2 drifts, one for each clock.  
Our current code doesn't do this.  This may show up on phones before we see 
it on IoT class devices.  Mumble.  I don't have a good answer.



-- 
These are my opinions.  I hate spam.