ESP8266 Community Forum

- Sun Apr 14, 2019 6:42 pm #81804

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!

- Mon Apr 15, 2019 11:38 am #81814 How about selecting a very dependable NTP server, record it's ip address and use that instead of the ntp pool? At my work we're using an internet provider that doesn't provide NTP service so I need to use public ones. I spent some time selecting a few real good ones (good stratum, near to us in network terms, little deviation in timestamps, availability). I have done that about ten years ago and almost all of them are still working as expected. Especially universities and university faculity services tend to have good, solid and public servers, over here.

If you were to make your own SNTP implementation (like I did), you could "broadcast" a request to, say, 10 servers at the same time and just use the first reply. I would be very unrealistic if all of them would cease working in a short time.

- Sun May 05, 2019 8:16 am #82159 Last time I wrote that association is quite quick here, but it doesn't seem to be the case anymore. Just association from boot takes almost three seconds (measured now). That used to be quite a bit quicker. The code on my side didn't change, so the same approach applies: if opmode, ssid and password are OK, use the SDK autoconnect. I checked it and indeed it uses the autoconnect feature. No explicit disconnection by me.

Then the question remains, why used this to be quicker in the past... What also strikes me is that a cold boot (power cycle) is just as slow in association as a reset. There should be a difference there, the current channel should be stored in RTC so no multi-channel scan should have to be required.

- Sun May 05, 2019 5:26 pm #82162 Is this with latest SDK?

My start time doing it as in this example hasn't changed and I'm on latest