Time Source Problem
Moderators: grovkillen, Stuntteam, TD-er
Time Source Problem
Hi Community,
i am wondering, why my ESP's (esp8266) have the wrong time.
Under advanced, i set "use NTP" .
Under Main i see that NTP is succesfully initialzed:
But TIME Source says ESPEASY p2p:
After Restart/Reboot the ESP time source is again NTP.
Why this could happen ?
regards Klaus
i am wondering, why my ESP's (esp8266) have the wrong time.
Under advanced, i set "use NTP" .
Under Main i see that NTP is succesfully initialzed:
But TIME Source says ESPEASY p2p:
After Restart/Reboot the ESP time source is again NTP.
Why this could happen ?
regards Klaus
Re: Time Source Problem
Most likely, the ESPEasy P2P Network is faster in responding than the NTP server. (That P2P network is quite fast... as it's all local ) Depending on several factors, later it may switch to NTP once/if that offers a reliable connection.
NB: You don't need to configure an explicit NTP server by name, just leaving the field empty will use pool.ntp.org, that automatically returns a result from the nearest NTP source, based on your externally exposed IP-address.
NB2: To avoid an 'NTP-storm' when all devices come back on-line after f.e. a power failure, ESPEasy has built-in some randomness in time to get the latest NTP time, but a better solution could be to have 2 or maybe 3 ESPEasy units in your P2P that are always running, to have NTP configured, and all others to rely on these to get the time via P2P. Most likely, the accuracy provided via P2P is good enough, and NTP will also be re-synched from time to time, to iron out the small differences that occur in an ESP, when counting its own time, and that updated time will also be shared via P2P.
NB: You don't need to configure an explicit NTP server by name, just leaving the field empty will use pool.ntp.org, that automatically returns a result from the nearest NTP source, based on your externally exposed IP-address.
NB2: To avoid an 'NTP-storm' when all devices come back on-line after f.e. a power failure, ESPEasy has built-in some randomness in time to get the latest NTP time, but a better solution could be to have 2 or maybe 3 ESPEasy units in your P2P that are always running, to have NTP configured, and all others to rely on these to get the time via P2P. Most likely, the accuracy provided via P2P is good enough, and NTP will also be re-synched from time to time, to iron out the small differences that occur in an ESP, when counting its own time, and that updated time will also be shared via P2P.
/Ton (PayPal.me)
Re: Time Source Problem
ESPEasy does keep track of time sources and their expected inaccuracy.
Also the last time sync of that time source is taken into account to decide which one is best.
For example, the most accurate one is GPS with a fix and used PPS pin. (order of usec in expected error)
One of the least accurate/precise time sources is the one restored from RTC memory at reboot as we simply have no clue whether the ESP may have been stuck for a while before the watchdog kicked in.
There are several in-between options and one of them could be some p2p node in your network which either just had its time updated via NTP or GPS.
If such a time sync was exceptionally fast (e.g. <15 msec round trip time to NTP server) and it "just happened", then it is unlikely any new NTP query from your node will yield a more accurate time.
So in such situations, your node may decide to use the system time as provided via that source, also to lessen the load on public NTP servers.
Typically the time sync via p2p has an expected time inaccuracy of just a few msec, however I have recently noticed there might be situations where some access points are set to use a longer DTIM interval and those may cache/buffer UDP broadcast packets. (N.B. You can also get a longer DTIM interval if you have your ESPEasy node set to "ECO" mode)
This is not yet taken into account, but it might cause an error of a few-100 msec which is of course not acceptable.
Also the last time sync of that time source is taken into account to decide which one is best.
For example, the most accurate one is GPS with a fix and used PPS pin. (order of usec in expected error)
One of the least accurate/precise time sources is the one restored from RTC memory at reboot as we simply have no clue whether the ESP may have been stuck for a while before the watchdog kicked in.
There are several in-between options and one of them could be some p2p node in your network which either just had its time updated via NTP or GPS.
If such a time sync was exceptionally fast (e.g. <15 msec round trip time to NTP server) and it "just happened", then it is unlikely any new NTP query from your node will yield a more accurate time.
So in such situations, your node may decide to use the system time as provided via that source, also to lessen the load on public NTP servers.
Typically the time sync via p2p has an expected time inaccuracy of just a few msec, however I have recently noticed there might be situations where some access points are set to use a longer DTIM interval and those may cache/buffer UDP broadcast packets. (N.B. You can also get a longer DTIM interval if you have your ESPEasy node set to "ECO" mode)
This is not yet taken into account, but it might cause an error of a few-100 msec which is of course not acceptable.
Re: Time Source Problem
Thanks for your quick reply.
I have deleted my specific NTP Server entry, as suggested.
All your explanations make sense, but do not explain why a have around 6 days time difference !!
I use 10 ESP's with NTP enabled, 2 ESP's without NTP. On all devices p2p is active.
The 2 ESP''s without NTP are configured with deepsleep. It seems that some devices got the time and date from one of this two devices.
What mean the number in brackest after p2p: ??
Time Source: ESPEasy p2p (8)
6 days ago i flashed all devices with the actual firmware form 20240822.
The deepsleep devices were flashed at last.
Maybe i should disable p2p for the 2 deep sleep devices which don't use NTP ?
I have deleted my specific NTP Server entry, as suggested.
All your explanations make sense, but do not explain why a have around 6 days time difference !!
I use 10 ESP's with NTP enabled, 2 ESP's without NTP. On all devices p2p is active.
The 2 ESP''s without NTP are configured with deepsleep. It seems that some devices got the time and date from one of this two devices.
What mean the number in brackest after p2p: ??
Time Source: ESPEasy p2p (8)
6 days ago i flashed all devices with the actual firmware form 20240822.
The deepsleep devices were flashed at last.
Maybe i should disable p2p for the 2 deep sleep devices which don't use NTP ?
Re: Time Source Problem
p2p time sync may indeed have some issue when they are awake for a short time.
I will have a look as this could indeed lead to serious time differences.
The RTC time should at least be compensated for with the estimated sleep time, however this is absolutely not a stable timer.
If you set 2 separate nodes to sleep for an hour at the same time, one may wake up tens of seconds before the other.
Also this RTC time should get an even larger penalty than it has right now as it should only be used by other nodes as a last resort.
So this should never be advertised via p2p when using deep sleep even though it might have been set "just now", it will seriously impact time sync.
I will have a look as this could indeed lead to serious time differences.
The RTC time should at least be compensated for with the estimated sleep time, however this is absolutely not a stable timer.
If you set 2 separate nodes to sleep for an hour at the same time, one may wake up tens of seconds before the other.
Also this RTC time should get an even larger penalty than it has right now as it should only be used by other nodes as a last resort.
So this should never be advertised via p2p when using deep sleep even though it might have been set "just now", it will seriously impact time sync.
Re: Time Source Problem
In the meanwhile i activate NTP also on my deepsleep nodes.
Re: Time Source Problem
NTP activation on the deppesleep devices is not a solution. Timedrift is still happening...
Now i deactivate p2p on the deepsleep devices...
Now i deactivate p2p on the deepsleep devices...
Re: Time Source Problem
OK, it doesnt mater what i configure.
The time drift is after a few days at least 15 seconds.
At the moment, i have all devices with ntp defined, exept the deepsleep devices, this devices havent a time defined.
The time drift is after a few days at least 15 seconds.
At the moment, i have all devices with ntp defined, exept the deepsleep devices, this devices havent a time defined.
Re: Time Source Problem
Now i do a test with p2p disabled, i will report here ..
Who is online
Users browsing this forum: Ahrefs [Bot] and 0 guests