eriksl wrote:Yeah, understandable.
Can't you use one specific server and skip the DNS lookup? I guess you're using something like 0.pool.ntp.org?
Is it a requirement to have a quick time sync after boot? Or is it because you want to have actively powered on as short as possible? Otherwise I guess it wouldn't hurt to wait a few seconds for the time to sync?
Snap - that's exactly why, on both topics.
I set two time servers at index 0 and 1 - 0 is the closest local ntp pool server (so here in Melbourne it's au.pool.ntp.org), and 1 is the generic pool.ntp.org. I change the local pool server depending on which country the system is deployed. I had originally decided to put in a DNS cache that survived deep sleep, but then I checked the TTL on all the host names I need and they all have very short lifetimes, so a DNS lookup is unfortunately required.
WRT the time sync, I store and cache all my various events as an ordered list of absolute times and my timer subsystem converts them into intervals when required for os_timer and deep sleep routines. This means I can cope with the dodgy RTC wake timer, and also events that happen monthly or weekly, or at specific hours of a day, or at specific intervals, or immediately, etc.
However, it also means I need the time synced each time I wake, and sometimes the only reason I'm waking is because the next timer is longer than the deep sleep maximum interval and I need to hit the snooze button . Other times I'll need to take a sensor reading and only send it to the platform if it's outside a threshold. And then if I actually do have to connect to the platform I need the time synced in order to do secure comms negotiation.
So yes, the faster I can wake up and reset the alarm clock, the faster I can get back to sleep!