search

ropg / ezTime

ezTime — pronounced "Easy Time" — is a very easy to use Arduino time and date library that provides NTP network time lookups, extensive timezone support, formatted time and date strings, user events, millisecond precision and more.
MIT License
327 stars 92 forks source link

Fix bugs 23 and 28, change references from olsen to olson. #29

Closed mike-s123 closed 5 years ago

mike-s123 commented 5 years ago

Bug fixes have been tested locally. "Olsen" was a misspelling of "Olson" (changed s/lsen/lson in cpp, h, keywords and README files). Fixes described in bug discussions.

For Olson - may cause backward compat issues - it's a KEYWORD2.

ropg commented 5 years ago

Wow, you're amazing. Will have a look tomorrow!

mike-s123 commented 5 years ago

Hey, you built the house, I'm just painting some walls. Thanks for your work, the library is just right for what I need.

mike-s123 commented 5 years ago

Added another change:

#define NTP_INTERVAL                    1801
#define NTP_RETRY                       1801
#define NTP_STALE_AFTER                 3602

Since many users will point their devices toward the pool.ntp.org servers, the above was changed to ensure the default settings comply with their Terms of Service ( https://www.ntppool.org/tos.html ). ezTime operates as an SNTP client, which shall not "Request time from the Services more than once every thirty (30) minutes" or "Set up a regular time sync interval such as ... “at minute or second X”." The existing defaults violated both.

ropg commented 5 years ago

Hey... Just having more time to look at it. Good work...

Just one thing. NTP is a single UDP packet. They easily get lost sometimes, and I'd hate to have someone's Arduino project wake up with no time for half an hour just because one single UDP packet (so soon after waking up) got lost in the mail. I would say a retry is not the same thing as a resync, because you have no idea of knowing whether the packet ever reached the NTP server. Now it might make sense to back off after three (?) tries and indeed wait half an hour. But that introduces an extra counter.

Does that make sense to you?

mike-s123 commented 5 years ago

I have no issue if it initially tries 2 or 3 times, as long as it then backs off. You can also get fancy, and do another dns lookup if you don't get a response. For the pool servers, that will usually give you a different server, which can fix an issue if the first server is temporarily down.

But after getting an initial sync, any project which can't keep reasonable time for an hour or two on its own has hardware issues which should be addressed. Without a limit on short period retries, trying more often than allowed can be counterproductive. Especially at the 5 second level, where some servers may deliberately stop responding because they consider it excessive/abusive. The code should also probably recognize and respect ntp Kiss-o'-Death packets, if it doesn't already.

ropg commented 5 years ago

My plan is to write the try-3-times-then-back-off-for-1801-secs mechanism and then release a new version. At some point I need to really sit down and contemplate the serious implications of the discussion surrounding #10 and probably roll a new major version.