Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31249

Re: newlib and time()

Show all headers | View raw

On 10/2/2022 3:09 PM, pozz wrote:
> Il 30/09/2022 20:42, Don Y ha scritto:
>> On 9/30/2022 2:29 AM, pozz wrote:
>>> Another bonus is when you have NTP, that returns seconds in UTC, so you can 
>>> set your counter with the exact number retrived by NTP.
>>
>> No.  You always have to ensure that time keeps flowing in one direction.
>>
>> So, time either "doesn't exist" before your initial sync with the
>> time server (what if the server isn't available when you want to
>> do that?)
> 
> 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?

If you apply the new time in a step function, then all of the potential
time related events between ~1/1/2020 and "now" will appear to occur
at the same instant -- *now* -- or, not at all.  And, any time-related
calculations will be grossly incorrect.

     start_time := now()
     dispenser(on)
     wait_until(start_time + interval)

Imagine what will happen if the time is changed during this fragment.
If the change adds >= interval to the local notion of now, then the
dispenser will be "on" only momentarily.  If it adds (0,interval),
then it will be on for some period LESS than the "interval" intended.

[I'm ignoring the possibility of it going BACKWARDS, for now]

Note that wait_until() could have been expressed as delay(interval)
and, depending on how this is internally implemented, it might be
silently translated to a wait_until() and thus dependant on the
actual value of now().

Likewise, imagine trying to measure the duration of an event:

     wait_until(event)
     start_time := now()
     wait_until(!event)
     duration = now() - start_time

Similarly, any implied ordering of actions is vulnerable:

     do(THIS, time1)
     do(THAT, time2)

What if the value of now() makes a jump from some time prior to
time1 to some time after time1, but before time2.  Will THIS happen?
(i.e., will it be scheduled to happen?)  How much ACTUAL (execution)
time will there be between THIS being started and THAT?

What if the value of now() makes a jump from some time prior to
time1 to some time after time2.  Will THIS happen before THAT?
Will both start (be made ready) concurrently?  Who will win the
unintended race?

[Note that many NTP clients won't "accept" a time declaration that is
"too far" from the local notion of now.  If you want to *set* the
current time, you use something like ntpdate to impose a specific time
regardless of how far that deviates from your own notion.]

>> *or* you have to look at your current notion of "now"
>> and ensure that the "real" value of now, when obtained from the
>> time server, is always in the future relative to your notion.
> 
> Actually I don't do that and I replace the timer counter with the value 
> retrieved from NTP.

Then you run the risk that the local counter may have already surpassed
the NTP "count" by, for example, N seconds.  And, time now jerks backwards
as the previous N seconds appear to be relived.

Will you AGAIN do the task that was scheduled for "a few seconds ago"?
(even though it has already been completed)  Will you remember to ALSO
do the task that expected to be done an hour before that -- if the "jerk
back" wasn't a full hour?

You likely wrote your code (or, your user scheduled events) on the assumption
that there are roughly 60 seconds between any two "minutes", etc.  And, that
time1 precedes time2 by (time2 - time1) actual seconds.

> What happens if the local timer is clocked by a faster clock then nominal? For 
> example, 16.001MHz with 16M prescaler.
> If I try to NTP re-sync every 1-hour, it's probably the local counter is 
> greater than the value retrieved from NTP. I'm forced to decrease the local 
> counter, my notion of "now".

No.  You change the rate at which you run the local "clock" -- whatever
timebase you are counting.  So, if your jiffy was designed to happen at
100ms intervals (counted down from some XTAL reference by a divisor of
MxN) and you now discover that your notion of 100 was actually 98.7 REAL ms
(because your time has been noted as moving faster than the NTP reference),
then you change the divisor used to generate the jiffy to something slightly 
larger to effectively slow the jiffy down to 100+ ms (the "+" being present
to ensure the local time eventually slows enough so that "real" time
falls into sync).

This is an continuous process.  (read the NTP sources and how the kernel
implements "adjtime()")

> 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

>> [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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

newlib and time() pozz <pozzugno@gmail.com> - 2022-09-30 08:29 +0200
  Re: newlib and time() David Brown <david.brown@hesbynett.no> - 2022-09-30 09:04 +0200
    Re: newlib and time() pozz <pozzugno@gmail.com> - 2022-09-30 11:29 +0200
      Re: newlib and time() Clifford Heath <no_spam@please.net> - 2022-09-30 21:51 +1000
        Re: newlib and time() pozz <pozzugno@gmail.com> - 2022-09-30 15:32 +0200
          Re: newlib and time() Richard Damon <Richard@Damon-Family.org> - 2022-09-30 09:48 -0400
            Re: newlib and time() Clifford Heath <no_spam@please.net> - 2022-10-01 08:43 +1000
        Re: newlib and time() Don Y <blockedofcourse@foo.invalid> - 2022-09-30 11:55 -0700
          Re: newlib and time() Clifford Heath <no_spam@please.net> - 2022-10-01 08:48 +1000
            Re: newlib and time() Don Y <blockedofcourse@foo.invalid> - 2022-09-30 16:11 -0700
      Re: newlib and time() David Brown <david.brown@hesbynett.no> - 2022-09-30 14:38 +0200
      Re: newlib and time() Don Y <blockedofcourse@foo.invalid> - 2022-09-30 11:42 -0700
        Re: newlib and time() pozz <pozzugno@gmail.com> - 2022-10-03 00:09 +0200
          Re: newlib and time() Don Y <blockedofcourse@foo.invalid> - 2022-10-02 19:02 -0700
            Re: newlib and time() pozz <pozzugno@gmail.com> - 2022-12-30 17:08 +0100
              Re: newlib and time() Don Y <blockedofcourse@foo.invalid> - 2022-12-30 17:35 -0700
                Re: newlib and time() pozz <pozzugno@gmail.com> - 2023-01-04 17:09 +0100
                Re: newlib and time() Don Y <blockedofcourse@foo.invalid> - 2023-01-04 12:19 -0700
                Re: newlib and time() George Neuner <gneuner2@comcast.net> - 2023-01-04 20:12 -0500
                Re: newlib and time() Don Y <blockedofcourse@foo.invalid> - 2023-01-04 19:40 -0700
          Re: newlib and time() Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2022-10-03 10:20 +0300
  Re: newlib and time() Clifford Heath <no_spam@please.net> - 2022-09-30 17:12 +1000
  Re: newlib and time() Theo <theom+news@chiark.greenend.org.uk> - 2022-09-30 14:06 +0100

csiph-web