Time Source Problem

[Rampler]

Hi Community,
i am wondering, why my ESP's (esp8266) have the wrong time.
Under advanced, i set "use NTP" .

Screenshot 2024-08-30 at 14-29-31 Gartenhaus.png (13.24 KiB) Viewed 2212 times

Under Main i see that NTP is succesfully initialzed:

Screenshot 2024-08-30 at 14-31-43 Gartenhaus.png (6.15 KiB) Viewed 2212 times

But TIME Source says ESPEASY p2p:

Screenshot 2024-08-30 at 14-33-41 Gartenhaus.png (18.58 KiB) Viewed 2212 times

After Restart/Reboot the ESP time source is again NTP.
Why this could happen ?

regards Klaus

[Ath]

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.

[TD-er]

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.

[Rampler]

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 ?

[Ath]

What mean the number in brackest after p2p: ??
Time Source: ESPEasy p2p (8)

That's the unit number that has provided the time via P2P.

[TD-er]

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.

[Rampler]

....
I will have a look as this could indeed lead to serious time differences.
...
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.

In the meanwhile i activate NTP also on my deepsleep nodes.

[Rampler]

NTP activation on the deppesleep devices is not a solution. Timedrift is still happening...
Now i deactivate p2p on the deepsleep devices...

[Rampler]

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.

[Rampler]

Now i do a test with p2p disabled, i will report here ..