On 1/4/2023 9:09 AM, pozz wrote:
> Il 31/12/2022 01:35, Don Y ha scritto:
>> On 12/30/2022 9:08 AM, pozz wrote:
>>>>> At startup, if NTP server is not available and I don't have any notion of
>>>>> "now", I start from a date in the past, i.e. 01/01/2020.
>>>>
>>>> Then you have to be able to accept a BIG skew in the time when the first
>>>> update arrives.  What if that takes an hour, a day or more (because the
>>>> server is down, badly configured or incorrect routing)?   What if it
>>>> *never* arrives?
>>>
>>> Certainly there's an exception at startup. When the *first* NTP response
>>> received, the code should accept a BIG shock of the current notion of now
>>> (that could be undefined or 2020 or another epoch until now).
>>> I read that ntpd accepts -g command line option that enable one (and only
>>> one) big difference between current system notion of now and "NTP now".
>>
>> Yes.  But, your system design still has to "make sense" if it NEVER gets
>> told the current time.
>
> Yes, the only solution that comes to my mind is to have a startup calendar
> time, such as 01/01/2023 00:00:00. Until a new time is received from NTP, that
> is the calendar time that the system will use.

To be clear, that is the *initial* time that it will use; you still want
time to move forward and not "stall" there, indefinitely.

> Of course, with this wrong "now", any event that is related to a calendar time
> would fail.

And how will the user react to this? Will he even consider it
to be a possibility? Will a big red light come on to remind him
that the product doesn't know what time/day it is?

The technological issues are easy to address (e.g., if being "close to
correct" in your initial assessment of time is crucial, then you include
provisions to know that "on board"). The tougher parts are trying to
match your implementation to the users' expectations. Principle
of least surprise, etc.

>>> The code I'm thinking of is not the one that manages normal timers that can
>>> depend on a local reference (XTAL, ceramic resonator, ...) completely
>>> independent from calendar counter. Most of the time, the precision of timers
>>> isn't strict and intervals are short: we need to activate a relay for 3
>>> seconds (but nothing happens if it is activated for 3.01 seconds) or we need
>>> to generate a pulse on an output of 100ms (but no problem if it is 98ms).
>>> This means having a main counter clocked at 10ms (or whatever) from a local
>>> clock of 100Hz (or whatever). This counter isn't corrected with NTP.
>>> The only code that must be fixed is the one that manages events that must
>>> occurs at specific calendar times (at 12 o'clock of 1st January, at 8:30 of
>>> everyday, and so on). So you should have *another* counter clocked at 1Hz
>>> (or 10Hz or 100Hz) that is adjusted by NTP. And abrupt changes should be
>>> taken into account (event if I don't know how).
>>
>> You can use NTP to discipline the local oscillator so that times
>> measured from it are "more accurate".  This, regardless of whether
>> or not the local time tracks the wall time.
>
> Yes, but I don't remember an application I worked on that didn't track the wall
> time and, at the same time, needed a greater precision than the local oscillator.

I use time in many of my data acquisition techniques. I try to
design so that I don't care how *accurate* the timebase is but
I want it to be stable/repeatable.

A "crystal" often drifts (temperature). I don't want measurements
made at one time of day (temperature) to differ from those made
at another time of day. (or, any other attribute that can affect
my notion of time)

I designed a product that had a really sensitive "front end".
To reduce the impact of the ACmains on our signal, I would
run the acquisition system at the mains frequency -- and,
included a setting for 50 vs. 60Hz selection (domestic/foreign
markets).

We found that blindly assuming the ACmains frequency was
as stated wasn't enough. Errors in the local oscillator
and variations in the ACmains introduced differences
so we had to frequency lock to the actual mains. Then,
use that to derive all related timing based on the
observed frequency as expressed by the local oscillator.

[I've been using a similar technique since the 70's to
build timepieces that exhibit excellent long term
accuracy with crappy crystals]

>> So, if (now() == CONSTANT) may NEVER be satisfied!  E.g., if the code
>> runs at time CONSTANT+1, then you can know that it's never going to
>> meet that condition (imagine it in a wait_till loop)
>>
>> If, instead, you assume that something may delay that statement from
>> being executed *prior* to CONSTANT, you may, instead, want to
>> code it as "if (now() >= CONSTANT)" to ensure it gets executed.
>> (and, if you only want it to be executed ONCE, then take steps to
>> note when you *have* executed it so you don't execute it again)
>>
>> For example, my system is real-time so every action has an
>> associated deadline.  But, it is entirely possible that some
>> actions will be blocked until long after their deadlines
>> have expired.  Checking for "now() == deadline" would lead
>> to erroneous behavior; the time between deadline and now()
>> effectively doesn't exist, from the perspective of the
>> action in question.  So, the deadline handler should be
>> invoked for ANY now() >= deadline.
>
> Suppose you have some alarms scheduled weekly, for example at 8:00:00 every
> Monday and at 9:00:00 every Saturday.
> In the week you have 604'800 seconds.
> 8:00 on Monday is at 28'800 seconds from the beginning of the week (I'm
> considering Monday as the first day of the week).
> 9:00 on Saturday is at 194'400 secs.
>
> If the alarms manager is called exactly one time each second, it should be very
> simple to understand if we are on time for an alarm:
>
>    if (now_weekly_secs == 28800) fire_alarm(ALARM1);
>    if (now_weekly_secs == 194400) fire_alarm(ALARM2);

Can you *guarantee* that it will always be called once and
exactly once per second? Regardless of other activities that
may be going on in your design? Including those that you
haven't yet imagined?

It is unlikely that this "needs" to be a high priority job.
If you have to MAKE it such, then you're bastardizing the
design needlessly.

> Note the equality test. With disequality you can't use this:
>
>    if (now_weekly_secs > 28800) fire_alarm(ALARM1);
>    if (now_weekly_secs > 194400) fire_alarm(ALARM2);
>
> otherwise alarms will occur countinuously after the deadline. You should tag
> the alarm as occured for the current week to avoid firing it again at the next
> call.

if (!alarm1_done && now_weekly_seconds > 28800) {
fire_alarm(ALARM1);
alarm1_done = TRUE;
}

assuming that your code doesn't implicitly do this (e.g., one typically
designs a timer service that lets you schedule alarms and then
*clears* them (removes them) once they have expired.

> Is it so difficult to *guarantee* calling alarms_manager(weekly_secs) every
> second?

You tell me. There are times when I see "not responding" in the window
frame of apps on my PC. Why? Do their designers KNOW that this will
happen? Are *they* busy -- or, is the *system* busy (disk thrashing, etc.)?

Will you (and anyone else who comes after you) remember that this
MUST happen? If an alarm fails to fire, will you know? Will you
know that it is because it took 1.001 seconds for that iteration
of the loop to be serviced?

My approach has always been to make each job as independant of the rest of
the system as possible. I don't want to have to revisit some code because
the system load has changed or some other job was considerably more
important AND costly than I had originally imagined would be the case
(when I designed some OTHER job)

>>> Some problems could occur when time1 and time2 are calendar times. One
>>> solution could be to have one module that manages calendar events with the
>>> following interface:
>>>
>>>    cevent_hdl_t cevent_add(time_t time, cevent_fn fn, void *arg);
>>>    void cevents_do(time_t now);
>>>
>>> Every second cevents_do() is called with the new calendar time (seconds from
>>> an epoch).
>>
>> What if a "second" is skipped (because some higher priority activity
>> was using the processor)?
>
> A second is a very long interval. It's difficult to think of a system that
> isn't able to satisfy programmatically a deadline of a second.

Think harder. :>

If you don't operate in a preemptive environment, then any "task"
that hogs the processor can screw you over. Or, any *series*
of task invocations can screw you without individually misbehaving.

In a preemptive environment, any *effective* change in priorities
can screw you over.

In each of these cases, the problem may or may not be repeatable.
Fear the case where it screws up occasionally -- enough to piss
off a user but not enough to be traceable (by you, after you've
forgotten this dependency, or your successor -- who may be unaware
of it!)

E.g., I *need* my deadline handlers to be invoked when a task
misses its deadline. *They* ensure the system remains in a
consistent state, even if the tasks can't meet their intended
goals. I can't afford to rely on them being invoked at a
specific time which might not be noticed because "things were
busy".

>>>>> What happens if the time doesn't flow in one direction only?
>>>>
>>>> Then everything that (implicitly) relies on time to be monotonic is
>>>> hosed.
>>>>
>>>> Repeat the examples at the start of my post with the case of time
>>>> jumping backwards and see what happens.
>>>>
>>>> What if time goes backwards enough to muck with some calculation
>>>> or event sequence -- but, not far enough to cause the code that
>>>> *schedules* those events to reflect the difference.
>>>>
>>>> What would you do if you saw entries in a log file:
>>>>
>>>> 12:01:07  start something
>>>> 12:01:08  did whatever
>>>> 12:01:15  did something else
>>>> 12:01:04  finished up
>>>
>>> In a real world, could this happen?
>>
>> In a multithreaded application, of course it can!
>>
>> task0() {
>>      spawn(task1);
>>      log("finished up");
>> }
>>
>> task1() {
>>      log("start something");
>>      ...
>>      log("did whatever");
>>      log("did something else")
>> }
>>
>> Assume log() prepends a timestamp to the message emitted.
>> Assume task1 is lower priority than task0.  It is spawned by
>> task0 but doesn't get a chance to execute until after
>> task0 has already printed its final message and quit.
>>
>> If multiple processors/nodes are involved, then the uncertainty
>> between their individual clocks further complicates this.
>>
>> And, of course, what do you do if <something> deliberately
>> introduces a delta to the current time?
>>
>> Imagine Bob wants to set an alarm for a meeting at 5:00PM.
>> He then changes the current time to one hour later -- presumably
>> because he noticed that the clock was incorrect.  Does that
>> mean the meeting will be one hour *sooner* than it would
>> appear to have been, previously?
>
> No. The meeting is always at 5:00PM.

But *which* 5:00PM? There's the 5:00PM on his wristwatach,
the 5:00PM in your device, the 5:00PM on his *boss's* wristwatch
(which trumps his), etc.

And, was it *today* at 5:00PM? Which "today"? (given that all
of these are arbitrary time references)

>> What if he notices the date is off and it's really "tomorrow"
>> and advances the date by one day.  Should the alarm be
>> canceled as the appointed time has already passed?  Or,
>> should the date component of the alarm time be similarly
>> advanced?
>
> IMHO if the user set a time using the wall clock convention (shut the door at
> 8:00PM every afternoon), it shouldn't be changed when the calendar time used by
> the system is adjusted. Anyway this should be application dependent.

It's 7:00. I set the device's time to 8:09. Do you close the door,
"9 minutes late"?

I realize my mistake and set the time back to *7*:09. Now what?
It's not yet 8:00 -- why is the door closed?

>>>>>> [Note that NTP slaves don't blindly assume the current time is
>>>>>> as reported but *slew* to the new value, over some interval.]
>>>>>>
>>>>>> This also ignores the possibility of computations with relative
>>>>>> *intervals* being inconsistent with these spontaneous "resets".
>>>>
>>>> It's important that the RATE of time passage is reasonably accurate
>>>> and consistent (and monotonically increasing).  But, the notion of
>>>> the "time of day" is dubious and exists just as a convenience for
>>>> humans to order events relative to the outside world (which uses
>>>> wall clocks).  How accurate is YOUR wall clock?  Does it agree
>>>> with your cell phone's notion of now?  The alarm clock in your
>>>> bedroom?  Your neighbor's timepiece when he comes to visit?  etc.