Il 04/01/2023 21:46, goldsi...@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.
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users