Re: [lwip-users] [OT] Sync local time to NTP

[Giuseppe Modugno]

Il 04/01/2023 21:46, goldsimon@gmx.de ha scritto:
> Am 30.12.2022 um 17:10 schrieb Giuseppe Modugno:
> > The typical scenario of lwip is an embedded platform. When a wall clock
> > is needed and the device is network connected, NTP is usually used to
> > retrieve automatically the correct time at startup and stay in sync with
> > an accurate reference (in other cases, the user can set a time as he 
> > wants).
> >
> > Consider an embedded device without a battery. At startup there's no
> > notion of current time, so we can start from an epoch (1970, 2020 or
> > whatever) and consider it the correct time. Another approach is
> > considering the time not initialized at all.
> >
> > lwip has a SNTP client implementation that magically calls a function
>
> Absolutely no magic in there: when a response from a server is received,
> it is parsed and this callback is called with the time received.

Sure, I wrote "magically" just to mean that I (lwip user) don't do 
anything else than enabling NTP and setting servers.


> > SNTP_SET_SYSTEM_TIME_NTP(s, f) when a response from a SNTP server is
> > received. Now the question is what to do with s, seconds from 1970 epoch
> > (ignore fractional part, just to simplify).
>
> This is one level upwards from lwIP. We provide the protocol
> implementations, not your system design.

Indeed I prefixed the subject of the post with [OT]. I'd like to 
exchange some experiences with other lwip users.


> > One possibility is to have a system counter clocked at 1s that counts
> > seconds from 1970. So SNTP_SET_SYSTEM_TIME_NTP() could simply overwrite
> > the counter value. However this simple approach brings to a counter that
> > isn't monotonic and continuous. I know the best approach is to slowed
> > down or accelerate the reference clock of the system counter that tracks
> > seconds from epoch.
> >
> > Do you really implement something similar or are you happy with
> > replacing the counter with the new value reported by NTP?
>
> That totally depends on what you desire for your product (what you use
> the timestamp for). For example, if you only use it for logging, it
> might be enough to add a line to your log that states the received time
> and the delta.

First of all, in my application I need "wall clock" for logging certain 
important
events, with a resolution of seconds. I never measured it, but I think 
NTP jitter should
be much smaller, maybe under 1 second. So brutally replacing the system 
counter
with NTP counter (as it is received and calculated by lwip SNTP) should 
be acceptable.

The big problem is that my application should make some actions at 
specific times
configured by the user. For example, switch on a lamp at 8:00AM every 
Mon-Fri and switch
off the lamp at 8:00PM every Mon-Fri.

If I use a simple counter of seconds from an epoch clocked by a local 
reference, no problem
occur. This couter will monotonic and will *not* experience any delta 
greater than 1 sec.
However I want to keep in sync this "local" counter with the counter 
received by NTP.
If I brutally replace local counter with NTP counter, some problem could 
occur.

What happens if NTP 8:01AM is reiceived when the local counter is at 
7:59AM? There's a risk
the event scheduled for 8:00AM won't be executed. What happens if NTP 
7:59AM is
reiceived when local counter is at 8:01AM? There's the risk one event is 
fired two times.

This is my concern that motivated me to post on this group asking how to 
do with the
counter received from NTP.


> Linux, on the other hand has at least 2 clocks, one "monotinic" clock
> (e.g. ticks since boot) and one "wall" clock. Timsync daemons may still
> vote to add a syslog line if the received SNTP time differs too much
> from what they would expect.
Linux shoud implement a full NTP client, so it filters replies from many 
servers and decides
when a big step (against the local counter) must be accepted or ignored.

There's only one reason to have a big step: at startup, when the wall 
clock isn't known.
After the first time sync (the first NTP response), the delta between 
local counter and
NTP counter should be very small. Anyway the decision to accept only one 
big delta
after startup is risky, because other and obscure reasons could happen 
that bring to a
wrong local counter that will not be ever adjusted if big deltas are 
ignored.

It appears a simple task, but it hides many complex issues.