khoih-prog
commented
3 years ago Hi Frank,
Again I'd appreciate your sharing of NTP experience, which certainly will be very helpful to me as well as other users.
However, I truely accidentally found out that my local router also provides NTP services. As the router often is the gateway, the IP address is also known without the need for additional configuration. So instead of "time.nist.gov" or "0.pool.ntp.org" I am addressing "192.168.84.254" (my local router's address). Since I started doing that, my NTP requests are blazing fast and almost 100% reliable.
This is so new and good, at least to me. I'll try to test and if OK will apply to many NTP-server related code by try the local router/cached NTP server first before asking outside servers.
happy coding - stay well
You too,
Best Regards,
As this libray allows us to deal with the local time zone and the examples show how to actually make use of that, I guess this feature will actually be used more often. Therefore I'd like to share some tips and thoughts that worked for me over the past few years when working with NTP-services, hoping that others find some use in them.
DNS resolves take quite an amout of time on small devices, especially the esp8266, during which they are blocked. I found it to be much faster to resolve the address on the first request only and directly use the received IP address on subsequent calls. Beware though that, especially on the "pool" domains, specifc time servers are not available all time. An IP that worked today might not tomorrow. So You will have to implement a fallback mechanism or repeat the resolve every now and then.
More and more devices make use of these services today. First it were our computers only, now all the smart devices follow. Whoever tried to manualy update a clock from a NTP-Service might have realized that they tend to time out quite often, possibly due to high trafic.. So I think it is good behaviour not to uses these services more that necessary. Do us all a favour and test the actual drift of Your device by simply comparing the time before and after synchronization, better yet the actual correction necessary. Also ask Yourself "how much accuracy is needed for my scenario?" Does it really matter if the clock is off by one or two seconds? I am watching an esp8266 for about three years now. It is synchronized twice a day and off by +/- 1 second at max. most of the time the difference is 0. No need to synchronize every few minutes, not even every hour. I could easily reduce NTP requests to once a day or one request every two days without having any impact on my specific use case.... but I am using Tip No. 3
While DNS resolves take some time, the actual NTP-request sometimes takes, what for a micro controller seems to be a life time. As mentioned earlier, depending on the service, NTP-requests tend to time out and block the controller during the wait time (depending on the implementation). After a time out another sync request has to be made and maybe an additional one after that... However, I truely accidentally found out that my local router also provides NTP services. As the router often is the gateway, the IP address is also known without the need for additional configuration. So instead of "time.nist.gov" or "0.pool.ntp.org" I am addressing "192.168.84.254" (my local router's address). Since I started doing that, my NTP requests are blazing fast and almost 100% reliable. You might check if Your router also priovides NTP services by simply trying to use it as a sync server.
happy coding - stay well
Frank