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.
newlib and time()
Started by ●September 30, 2022
Reply by ●January 4, 20232023-01-04
Reply by ●January 4, 20232023-01-04
On Wed, 4 Jan 2023 12:19:55 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>On 1/4/2023 9:09 AM, pozz wrote:>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.You can't assume AC frequency will be held ... generator spin rates are not constant under changing loads, and rectification is more difficult because of the high voltages and the fact that generators typically are 4..12 multiphase (for efficiency) being squashed into (some resemblance of) a sine wave. But the utilities are required to provide the expected number of cycles in a given period. In the US, that period is contractual (not law) and typically is from 6..24 hours. If you've ever seen cycle driven wall clocks run slow all morning or afternoon and then suddenly run fast for several minutes just before noon, or 6pm, or midnight (or all three) ... that's the electric utility catching up on a low cycle count.>> 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?'exactly once' semantics are impossible to guarantee open loop. Lacking positive feedback, the best you can achieve is 'at most once' or 'at least once'.>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.Exactly. The above is an example of 'at most once'. But incomplete: it fails to reset for next week. ;-)>> ... >> 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.Yup!.>>>>>> What happens if the time doesn't flow in one direction only? >>>>> >>>>> Then everything that (implicitly) relies on time to be monotonic is >>>>> hosed.Simple enough to maintain monotonically increasing system time (at least until the counter rolls over, but that's easily handled).>>> 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)The washer repairman says "I have you down for Tuesday". But where is down? And which Tuesday? -- Erma Bombeck George
Reply by ●January 4, 20232023-01-04
On 1/4/2023 6:12 PM, George Neuner wrote:> On Wed, 4 Jan 2023 12:19:55 -0700, Don Y <blockedofcourse@foo.invalid> > wrote: >> 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. > > You can't assume AC frequency will be held ... generator spin rates > are not constant under changing loads, and rectification is more > difficult because of the high voltages and the fact that generators > typically are 4..12 multiphase (for efficiency) being squashed into > (some resemblance of) a sine wave.Yes. Which is why you need a Line Frequency Clock (LFC) in the design. Anything related to that frequency must be derived from frequency locking your local oscillator to the "period" sensed on the LFC.> But the utilities are required to provide the expected number of > cycles in a given period. In the US, that period is contractual (not > law) and typically is from 6..24 hours.I'm not sure of that, anymore. There was a move to break this arrangement. That wasn't approved. Then it was (?). But, my LFC controlled timepieces still keep good time so I wonder if the utilities just kept it up even if not obligated to do so (?)>> 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. > > Exactly. The above is an example of 'at most once'. > But incomplete: it fails to reset for next week. ;-)Details included on sheet #2...>>>>>>> What happens if the time doesn't flow in one direction only? >>>>>> >>>>>> Then everything that (implicitly) relies on time to be monotonic is >>>>>> hosed. > > Simple enough to maintain monotonically increasing system time (at > least until the counter rolls over, but that's easily handled).For many devices, there's nothing wrong with starting the counter from 0 at each reset. As most don't run for years on end, the possibility of overrun is greatly minimized. The important thing is not to tie your internal representation of "time" to the wall clock. Handle that separately so you can let the latter shift back and forth, relative to the former, without mucking up the timing of algorithms. Too often, I've seen folks think they are clever by using ONE notion of time throughout their design. This forces them to deal with the issue of allowing one *representation* to be changed without impacting the other concurrent uses. [What do you do if someone wants to set your clock/calendar to unusual times -- e.g., during the Gregorian switchover. Or, to "prehistory"? Or, to a specific leap-second??] Human-Time is just a royal PITA.
