(Why is) getLocalTime() on ESP32 taking several seconds to complete successfully

Question

This is a cross-post from https://github.com/espressif/arduino-esp32/discussions/8653 as it didn't yield any results there.

I noticed that getLocalTime() is consistently taking 5-10+ seconds to complete. So far I haven't been able to find the root cause.

I am testing on a ESP32-WROVER-B module. On startup the device first connects to WiFi and then tries to sync time.

boolean initTime() {
 struct tm timeinfo;
 log_i("Synchronizing time.");
 // Connect to NTP server with 0 TZ offset, call setTimezone() later
 configTime(0, 0, "pool.ntp.org");
 // getLocalTime uses a default timeout of 5s -> the loop takes at most 3*5s to complete
 for (int i = 0; i < 3; i++) {
 if (getLocalTime(&timeinfo)) {
 log_i("UTC time: %s.", getCurrentTimestamp(SYSTEM_TIMESTAMP_FORMAT).c_str());
 return true;
 }
 }
 log_e("Failed to obtain time.");
 return false;
}

 ...
 10:12:28.118 > [ 3634][I][connectivity.h:17] startWiFi(): ...done. IP: 192.168.0.57, WiFi RSSI: -55.
- 10:12:28.118 > [ 3700][I][util.h:25] initTime(): Synchronizing time.
| 
->10:12:34.025 > [ 11572][I][util.h:37] initTime(): UTC time: 2023年09月19日 08:12:34.
 10:12:34.037 > [ 11572][I][util.h:60] setTimezone(): Setting timezone to 'CET-1CEST,M3.5.0,M10.5.0/3'.
 10:12:34.042 > [ 11574][I][main.cpp:175] syncTime(): Current local time: 2023年09月19日 10:12:34
 ...

In the above example it took ~6s for a "valid" timestamp to become available.

• st2000: 1) Have you tried a different NTP server? 2) Why is it important to synchronize your local clock in as few seconds as possible?
• Nick Gammon: Try replacing pool.ntp.org with (one of) its IP addresses eg. 159.196.3.239
• Marcel Stör: @st2000 I tried different servers but all by-name so far (i.e. implicitly using DNS). I want this to be done as quickly as possible as it's part of the setup() sequence. The sketch should only proceed with an accurately synced clock.
• dandavis: it should connect to the server just once at boot, and then every so often, which is the 4th argument to the NTPClient constructor (the refresh time in ms). On the ESP32, every 15 mins is fine to keep well under 1s drift, which is the resolution of the interface anyway.
• Juraj: try sntp_set_sync_mode(SNTP_SYNC_MODE_IMMED);

Answer 1

Based on the wording in the question, it appears you are requesting an NTP re-synchronizing event often. Perhaps as often as possible. Consider that most Arduino projects request an NTP re-synchronizing event once to set the local RTC. Then perhaps once a day to check if the RTC is accurate.

Keep in mind that many NTP servers defend them selves from attack by throttling the service from an IP address who utilize them excessively. This quote:

The NTP server may throttle traffic, especially for clients making frequent requests.

... is from this web site.

---

In case you are not aware, if time is important for your Arduino project, consider adding RTC hardware. This can be set to the the local time just after the NTP re-synchronizing. From that point forward, the local RTC can provide the time. Later, it may be prudent to check the local RTC against the NTP reported time. But this is usually not necessary for days at a time for the vast majority of Arduino projects.

• Marcel Stör: That is a very plausible explanation, thanks! While working on a new sketch I go through the compile-upload-reboot loop (far to) often. Since my initTime() is triggered from setup(), requests from my IP address hit the NTP servers very frequently. I guess I should consider running my own NTP server (e.g. a cturra/ntp Docker container) and rewire my sketches to hit that one.
• st2000: Thanks. I am curious. If you do not make an NTP request for, say 24 hours. Do you see an improvement in NTP response time?
• Marcel Stör: Appears indeed to have been the root cause. Being away from sketch development for a couple of days solved it.