Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The most important early product on the way to developing a good product is an imperfect version.


devel / comp.arch.embedded / Re: newlib and time()

SubjectAuthor
* newlib and time()pozz
+* Re: newlib and time()David Brown
|`* Re: newlib and time()pozz
| +* Re: newlib and time()Clifford Heath
| |+* Re: newlib and time()pozz
| ||`* Re: newlib and time()Richard Damon
| || `- Re: newlib and time()Clifford Heath
| |`* Re: newlib and time()Don Y
| | `* Re: newlib and time()Clifford Heath
| |  `- Re: newlib and time()Don Y
| +- Re: newlib and time()David Brown
| `* Re: newlib and time()Don Y
|  `* Re: newlib and time()pozz
|   +* Re: newlib and time()Don Y
|   |`* Re: newlib and time()pozz
|   | `* Re: newlib and time()Don Y
|   |  `* Re: newlib and time()George Neuner
|   |   `- Re: newlib and time()Don Y
|   `- Re: newlib and time()Tauno Voipio
+- Re: newlib and time()Clifford Heath
`- Re: newlib and time()Theo

1
newlib and time()

<th62c5$ufge$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1043&group=comp.arch.embedded#1043

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: newlib and time()
Date: Fri, 30 Sep 2022 08:29:25 +0200
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <th62c5$ufge$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Sep 2022 06:29:25 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="84580276b9c01f09266083f5e733fe8d";
logging-data="998926"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+g9QBb8IsTX8YaR0Ufu/m0PARWquLiBGo="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:N9ZagZLHdfV66MxcuNDIHSj6dv0=
 by: pozz - Fri, 30 Sep 2022 06:29 UTC

I often use newlib standard C libraries with gcc toolchain for Cortex-M
platforms. It sometimes happens I need to manage calendar time: seconds
from 1970 or broken down time. And it sometimes happens I need to manage
timezone too, because the time reference comes from NTP (that is UTC).

newlib as expected defines a time() function that calls a syscall
function _gettimeofday(). It should be defined as in [1].

What is it? There's an assembler instruction that I don't understand:

asm ("swi %a1; mov %0, r0" : "=r" (value): "i" (SWI_Time) : "r0");

What is the cleanest way to override this behaviour and let newlib
time() to return a custom calendar time, maybe counted by a local RTC,
synchronized with a NTP?

The solution that comes to my mind is to override _gettimeofday() by
defining a custom function.

[1] https://github.com/eblot/newlib/blob/master/libgloss/arm/syscalls.c

Re: newlib and time()

<th64eh$uo0n$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1044&group=comp.arch.embedded#1044

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Fri, 30 Sep 2022 09:04:49 +0200
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <th64eh$uo0n$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Sep 2022 07:04:50 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="79b1f5bd2135063fd89e42c7a0162292";
logging-data="1007639"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dxEhgEzEOyWmI7YimbeFIcL/afbJlAJo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:/kPQ/VXH/59MO+t/AzbepFDa714=
Content-Language: en-GB
In-Reply-To: <th62c5$ufge$1@dont-email.me>
 by: David Brown - Fri, 30 Sep 2022 07:04 UTC

On 30/09/2022 08:29, pozz wrote:
> I often use newlib standard C libraries with gcc toolchain for Cortex-M
> platforms. It sometimes happens I need to manage calendar time: seconds
> from 1970 or broken down time. And it sometimes happens I need to manage
> timezone too, because the time reference comes from NTP (that is UTC).
>
> newlib as expected defines a time() function that calls a syscall
> function _gettimeofday(). It should be defined as in [1].
>
> What is it? There's an assembler instruction that I don't understand:
>
>   asm ("swi %a1; mov %0, r0" : "=r" (value): "i" (SWI_Time) : "r0");
>

It is a "software interrupt" instruction. If you have a separation of
user-space and supervisor-space code in your system, this is the way you
make a call to supervisor mode.

> What is the cleanest way to override this behaviour and let newlib
> time() to return a custom calendar time, maybe counted by a local RTC,
> synchronized with a NTP?
>
> The solution that comes to my mind is to override _gettimeofday() by
> defining a custom function.
>

Yes, that's the way to do it.

Or define your own time functions that are appropriate to the task. I
have almost never had a use for the standard library time functions -
they are too much for most embedded systems which rarely need all the
locale stuff, time zones, and tracking leap seconds, while lacking the
stuff you /do/ need like high precision time counts.

Use a single 64-bit monotonic timebase running at high speed (if your
microcontroller doesn't support that directly, use a timer with an
interrupt for tracking the higher part). That's enough for nanosecond
precision for about 600 years.

For human-friendly time and dates, either update every second or write
your own simple second-to-human converter. It's easier if you have
your base point relatively recently (there's no need to calculate back
to 01.01.1970).

If you have an internet connection, NTP is pretty simple if you are
happy to use the NTP pools as a rough reference without trying to do
millisecond synchronisation.

>
>
> [1] https://github.com/eblot/newlib/blob/master/libgloss/arm/syscalls.c
>

Re: newlib and time()

<171991e71244cb80$2$2901337$30dd3a6f@news.thecubenet.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1045&group=comp.arch.embedded#1045

 copy link   Newsgroups: comp.arch.embedded
Date: Fri, 30 Sep 2022 17:12:36 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: newlib and time()
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <th62c5$ufge$1@dont-email.me>
From: no_s...@please.net (Clifford Heath)
In-Reply-To: <th62c5$ufge$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 25
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!news.thecubenet.com!not-for-mail
NNTP-Posting-Date: Fri, 30 Sep 2022 07:12:38 +0000
Organization: theCubeNet - www.thecubenet.com
X-Complaints-To: abuse@thecubenet.com
Message-ID: <171991e71244cb80$2$2901337$30dd3a6f@news.thecubenet.com>
X-Received-Bytes: 1985
 by: Clifford Heath - Fri, 30 Sep 2022 07:12 UTC

On 30/9/22 16:29, pozz wrote:
> I often use newlib standard C libraries with gcc toolchain for Cortex-M
> platforms. It sometimes happens I need to manage calendar time: seconds
> from 1970 or broken down time. And it sometimes happens I need to manage
> timezone too, because the time reference comes from NTP (that is UTC).
>
> newlib as expected defines a time() function that calls a syscall
> function _gettimeofday(). It should be defined as in [1]. > What is it? There's an assembler instruction that I don't understand:

It's the internal implementation of a bog-standard BSD Unix system call.
Have you tried `man 2 gettimeofday`?

The first parameter points to a struct timeval with time_t tv_sec and
suseconds_t tv_usec, and the second one (both optional) to a struct
timezone with two ints called tz_minuteswest and tz_dsttime.

>   asm ("swi %a1; mov %0, r0" : "=r" (value): "i" (SWI_Time) : "r0");
> What is the cleanest way to override this behaviour and let newlib
> time() to return a custom calendar time, maybe counted by a local RTC,
> synchronized with a NTP?

That depends on details of newlib and your tool chain.

Clifford Heath

Re: newlib and time()

<th6cu8$ufgd$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1046&group=comp.arch.embedded#1046

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Fri, 30 Sep 2022 11:29:44 +0200
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <th6cu8$ufgd$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Sep 2022 09:29:44 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="84580276b9c01f09266083f5e733fe8d";
logging-data="998925"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/A7sPukYhdlZ5Kl3m9ykQpZJrf/zncfgY="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:PPA+x4EsSP+faOCpnzRHpKUrT2E=
In-Reply-To: <th64eh$uo0n$1@dont-email.me>
 by: pozz - Fri, 30 Sep 2022 09:29 UTC

Il 30/09/2022 09:04, David Brown ha scritto:
> On 30/09/2022 08:29, pozz wrote:
>> I often use newlib standard C libraries with gcc toolchain for
>> Cortex-M platforms. It sometimes happens I need to manage calendar
>> time: seconds from 1970 or broken down time. And it sometimes happens
>> I need to manage timezone too, because the time reference comes from
>> NTP (that is UTC).
>>
>> newlib as expected defines a time() function that calls a syscall
>> function _gettimeofday(). It should be defined as in [1].
>>
>> What is it? There's an assembler instruction that I don't understand:
>>
>>    asm ("swi %a1; mov %0, r0" : "=r" (value): "i" (SWI_Time) : "r0");
>>
>
> It is a "software interrupt" instruction.  If you have a separation of
> user-space and supervisor-space code in your system, this is the way you
> make a call to supervisor mode.

Ok, but how that instruction helps in returning a value from
_gettimeofday()?

>> What is the cleanest way to override this behaviour and let newlib
>> time() to return a custom calendar time, maybe counted by a local RTC,
>> synchronized with a NTP?
>>
>> The solution that comes to my mind is to override _gettimeofday() by
>> defining a custom function.
>>
>
> Yes, that's the way to do it.
>
> Or define your own time functions that are appropriate to the task.  I
> have almost never had a use for the standard library time functions -
> they are too much for most embedded systems which rarely need all the
> locale stuff, time zones, and tracking leap seconds, while lacking the
> stuff you /do/ need like high precision time counts.
>
> Use a single 64-bit monotonic timebase running at high speed (if your
> microcontroller doesn't support that directly, use a timer with an
> interrupt for tracking the higher part).  That's enough for nanosecond
> precision for about 600 years.
>
> For human-friendly time and dates, either update every second or write
> your own simple second-to-human converter.   It's easier if you have
> your base point relatively recently (there's no need to calculate back
> to 01.01.1970).
>
> If you have an internet connection, NTP is pretty simple if you are
> happy to use the NTP pools as a rough reference without trying to do
> millisecond synchronisation.

I agree with you and I used to implement my own functions to manage
calendar times. Sometimes I used internal or external RTC that gives
date and time in broken down fields (seconds, minutes, ...).

However most RTCs don't manage automatic DST (daylight saving time), so
I started using a different approach.
I started using a simple 32-bits timer that increments every 1 second.
Maybe a timer clocked from an accurate 32.768kHz quartz with a 32768
prescaler (many RTC can be configured as a simple 32-bit counter).
Rarely I need calendar times with a resolution better than 1 second.

Now the big question: what the counter exactly represents? Of course,
seconds elapsed from an epoch (that could be Unix 1970 or 2000 or 2020
or what you choose). But the real question is: UTC or localtime?

I started using localtime, for example the timer counts seconds since
year 2020 (so avoiding wrap-around at year 2038) in Rome timezone.
However this approach pulls-in other issues.

How to convert this number (seconds since 2020 in Rome) to broken-down
time (day, month, hours...)? It's very complex, because you should count
for leap years, but mostly for DST rules.
In Rome we have a calendar times that occur two times, when the clock is
moved backward by one hour for DST. What is the counter value of this
times as seconds from epoch in Rome for this time?

It's much more simple to start from seconds in UTC, as Linux (and maybe
Windows) does. In this way you can use standard functions to convert
seconds in UTC to localtime. For example, you can use localtime() (or
localtime_r() that is better).

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.

Re: newlib and time()

<1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1047&group=comp.arch.embedded#1047

 copy link   Newsgroups: comp.arch.embedded
Date: Fri, 30 Sep 2022 21:51:57 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: newlib and time()
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me> <th6cu8$ufgd$1@dont-email.me>
From: no_s...@please.net (Clifford Heath)
In-Reply-To: <th6cu8$ufgd$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 43
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!news.thecubenet.com!not-for-mail
NNTP-Posting-Date: Fri, 30 Sep 2022 11:51:59 +0000
Organization: theCubeNet - www.thecubenet.com
X-Complaints-To: abuse@thecubenet.com
Message-ID: <1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>
X-Received-Bytes: 2748
 by: Clifford Heath - Fri, 30 Sep 2022 11:51 UTC

On 30/9/22 19:29, pozz wrote:
> Il 30/09/2022 09:04, David Brown ha scritto:
>> On 30/09/2022 08:29, pozz wrote:
>>> I often use newlib standard C libraries with gcc toolchain for
>>> Cortex-M platforms. It sometimes happens I need to manage calendar
>>> time: seconds from 1970 or broken down time. And it sometimes happens
>>> I need to manage timezone too, because the time reference comes from
>>> NTP (that is UTC).
>>>
>>> newlib as expected defines a time() function that calls a syscall
>>> function _gettimeofday(). It should be defined as in [1].
>>>
>>> What is it? There's an assembler instruction that I don't understand:
>>>
>>>    asm ("swi %a1; mov %0, r0" : "=r" (value): "i" (SWI_Time) : "r0");
>>
>> It is a "software interrupt" instruction.  If you have a separation of
>> user-space and supervisor-space code in your system, this is the way
>> you make a call to supervisor mode.
>
> Ok, but how that instruction helps in returning a value from
> _gettimeofday()?

It traps into Kernel mode, with a different stack. The kernel uses
memory manipulation to push return values into user-mode registers or
the user stack as needed to simulate a procedure return.

> It's much more simple to start from seconds in UTC, as Linux (and maybe
> Windows) does. In this way you can use standard functions to convert
> seconds in UTC to localtime

That's a good way to always get the wrong result. You are ignoring the
need for leap seconds. If you want a monotonic counter of seconds since
some epoch, you must not use UTC, but TAI:

<https://en.wikipedia.org/wiki/International_Atomic_Time>

When I implmented this, I used a 64-bit counter in 100's of nanoseconds
since a date about 6000BC, measuring in TAI. You can convert to UTC
easily enough, and then use the timezone tables to get local times.

Clifford Heath.

Re: newlib and time()

<th6o0l$10l6p$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1048&group=comp.arch.embedded#1048

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Fri, 30 Sep 2022 14:38:44 +0200
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <th6o0l$10l6p$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Sep 2022 12:38:45 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="79b1f5bd2135063fd89e42c7a0162292";
logging-data="1070297"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/9U6wXK40VUNQso6VfCARRZFER+YbSojw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:iSqM981SRqH5QQJ+VvDXfKMLUvA=
In-Reply-To: <th6cu8$ufgd$1@dont-email.me>
Content-Language: en-GB
 by: David Brown - Fri, 30 Sep 2022 12:38 UTC

On 30/09/2022 11:29, pozz wrote:
> Il 30/09/2022 09:04, David Brown ha scritto:
>> On 30/09/2022 08:29, pozz wrote:
>>> I often use newlib standard C libraries with gcc toolchain for
>>> Cortex-M platforms. It sometimes happens I need to manage calendar
>>> time: seconds from 1970 or broken down time. And it sometimes happens
>>> I need to manage timezone too, because the time reference comes from
>>> NTP (that is UTC).
>>>
>>> newlib as expected defines a time() function that calls a syscall
>>> function _gettimeofday(). It should be defined as in [1].
>>>
>>> What is it? There's an assembler instruction that I don't understand:
>>>
>>>    asm ("swi %a1; mov %0, r0" : "=r" (value): "i" (SWI_Time) : "r0");
>>>
>>
>> It is a "software interrupt" instruction.  If you have a separation of
>> user-space and supervisor-space code in your system, this is the way
>> you make a call to supervisor mode.
>
> Ok, but how that instruction helps in returning a value from
> _gettimeofday()?

It will work if you have an OS that provides services to user-level
code. The service type is passed in the SWI instruction (in this case,
"SWI_Time"), and the service should return a value in r0.

Calls like this are part of the "hosted" C library functions - they rely
on a host OS to do the actual work.

>
>
>>> What is the cleanest way to override this behaviour and let newlib
>>> time() to return a custom calendar time, maybe counted by a local
>>> RTC, synchronized with a NTP?
>>>
>>> The solution that comes to my mind is to override _gettimeofday() by
>>> defining a custom function.
>>>
>>
>> Yes, that's the way to do it.
>>
>> Or define your own time functions that are appropriate to the task.  I
>> have almost never had a use for the standard library time functions -
>> they are too much for most embedded systems which rarely need all the
>> locale stuff, time zones, and tracking leap seconds, while lacking the
>> stuff you /do/ need like high precision time counts.
>>
>> Use a single 64-bit monotonic timebase running at high speed (if your
>> microcontroller doesn't support that directly, use a timer with an
>> interrupt for tracking the higher part).  That's enough for nanosecond
>> precision for about 600 years.
>>
>> For human-friendly time and dates, either update every second or write
>> your own simple second-to-human converter.   It's easier if you have
>> your base point relatively recently (there's no need to calculate back
>> to 01.01.1970).
>>
>> If you have an internet connection, NTP is pretty simple if you are
>> happy to use the NTP pools as a rough reference without trying to do
>> millisecond synchronisation.
>
> I agree with you and I used to implement my own functions to manage
> calendar times. Sometimes I used internal or external RTC that gives
> date and time in broken down fields (seconds, minutes, ...).
>
> However most RTCs don't manage automatic DST (daylight saving time), so
> I started using a different approach.
> I started using a simple 32-bits timer that increments every 1 second.
> Maybe a timer clocked from an accurate 32.768kHz quartz with a 32768
> prescaler (many RTC can be configured as a simple 32-bit counter).
> Rarely I need calendar times with a resolution better than 1 second.
>
> Now the big question: what the counter exactly represents? Of course,
> seconds elapsed from an epoch (that could be Unix 1970 or 2000 or 2020
> or what you choose). But the real question is: UTC or localtime?
>
> I started using localtime, for example the timer counts seconds since
> year 2020 (so avoiding wrap-around at year 2038) in Rome timezone.
> However this approach pulls-in other issues.
>
> How to convert this number (seconds since 2020 in Rome) to broken-down
> time (day, month, hours...)? It's very complex, because you should count
> for leap years, but mostly for DST rules.
> In Rome we have a calendar times that occur two times, when the clock is
> moved backward by one hour for DST. What is the counter value of this
> times as seconds from epoch in Rome for this time?
>
> It's much more simple to start from seconds in UTC, as Linux (and maybe
> Windows) does. In this way you can use standard functions to convert
> seconds in UTC to localtime. For example, you can use localtime() (or
> localtime_r() that is better).
>
> 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.
>

That should all be fine.

Re: newlib and time()

<i8b*XPBZy@news.chiark.greenend.org.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1049&group=comp.arch.embedded#1049

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!nntp.terraraq.uk!nntp-feed.chiark.greenend.org.uk!ewrotcd!.POSTED.chiark.greenend.org.uk!not-for-mail
From: theom+n...@chiark.greenend.org.uk (Theo)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: 30 Sep 2022 14:06:12 +0100 (BST)
Organization: University of Cambridge, England
Message-ID: <i8b*XPBZy@news.chiark.greenend.org.uk>
References: <th62c5$ufge$1@dont-email.me>
Injection-Info: chiark.greenend.org.uk; posting-host="chiark.greenend.org.uk:212.13.197.229";
logging-data="1776"; mail-complaints-to="abuse@chiark.greenend.org.uk"
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-15-amd64 (x86_64))
Originator: theom@chiark.greenend.org.uk ([212.13.197.229])
 by: Theo - Fri, 30 Sep 2022 13:06 UTC

pozz <pozzugno@gmail.com> wrote:
> I often use newlib standard C libraries with gcc toolchain for Cortex-M
> platforms. It sometimes happens I need to manage calendar time: seconds
> from 1970 or broken down time. And it sometimes happens I need to manage
> timezone too, because the time reference comes from NTP (that is UTC).
>
> newlib as expected defines a time() function that calls a syscall
> function _gettimeofday(). It should be defined as in [1].
>
> What is it? There's an assembler instruction that I don't understand:
>
> asm ("swi %a1; mov %0, r0" : "=r" (value): "i" (SWI_Time) : "r0");
>
> What is the cleanest way to override this behaviour and let newlib
> time() to return a custom calendar time, maybe counted by a local RTC,
> synchronized with a NTP?

It appears 'libgloss' is the system-dependent part of newlib. It has
various ideas of what those low level system functions should do, in
particular linux-syscalls0.S, redboot-syscalls.c and syscalls.c (which
appears to be calling Arm's Angel monitor).

There's a guide for porting newlib to a new platform that describes what
libgloss is and how to port it:
https://sourceware.org/newlib/libgloss.html
as well as:
https://www.embecosm.com/appnotes/ean9/ean9-howto-newlib-1.0.html
https://wiki.osdev.org/Porting_Newlib

So the cleanest way wouldn't be to override _gettimeofday() as such, you'd
make your own libgloss library that implemented the backend functions you
wanted.

Theo

Re: newlib and time()

<th6r4t$ufge$2@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1050&group=comp.arch.embedded#1050

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Fri, 30 Sep 2022 15:32:13 +0200
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <th6r4t$ufge$2@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me>
<1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Sep 2022 13:32:13 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="84580276b9c01f09266083f5e733fe8d";
logging-data="998926"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+YpANdHZwp+b4F7kgDFrp+sTfWf9+TuV0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:q9h+CWANVDylP1gZQTSKQIN4AHU=
In-Reply-To: <1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>
 by: pozz - Fri, 30 Sep 2022 13:32 UTC

Il 30/09/2022 13:51, Clifford Heath ha scritto:
> On 30/9/22 19:29, pozz wrote:
>> Il 30/09/2022 09:04, David Brown ha scritto:
>>> On 30/09/2022 08:29, pozz wrote:

[...]

>> It's much more simple to start from seconds in UTC, as Linux (and
>> maybe Windows) does. In this way you can use standard functions to
>> convert seconds in UTC to localtime
>
> That's a good way to always get the wrong result. You are ignoring the
> need for leap seconds. If you want a monotonic counter of seconds since
> some epoch, you must not use UTC, but TAI:
>
> <https://en.wikipedia.org/wiki/International_Atomic_Time>
>
> When I implmented this, I used a 64-bit counter in 100's of nanoseconds
> since a date about 6000BC, measuring in TAI. You can convert to UTC
> easily enough, and then use the timezone tables to get local times.

What happens if the counter is UTC instead of IAT in a typical embedded
application? There's a time when the counter is synchronized (by a
manual operation from the user, by NTP or other means). At that time the
broken-down time shown on the display is precise.

You should wait for the next leap second to have an error of... 1 second.

Re: newlib and time()

<VsCZK.65920$JZK5.24376@fx03.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1051&group=comp.arch.embedded#1051

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.13.1
Subject: Re: newlib and time()
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me>
<1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>
<th6r4t$ufge$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <th6r4t$ufge$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 50
Message-ID: <VsCZK.65920$JZK5.24376@fx03.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 30 Sep 2022 09:48:37 -0400
X-Received-Bytes: 3124
 by: Richard Damon - Fri, 30 Sep 2022 13:48 UTC

On 9/30/22 9:32 AM, pozz wrote:
> Il 30/09/2022 13:51, Clifford Heath ha scritto:
>> On 30/9/22 19:29, pozz wrote:
>>> Il 30/09/2022 09:04, David Brown ha scritto:
>>>> On 30/09/2022 08:29, pozz wrote:
>
> [...]
>
>>> It's much more simple to start from seconds in UTC, as Linux (and
>>> maybe Windows) does. In this way you can use standard functions to
>>> convert seconds in UTC to localtime
>>
>> That's a good way to always get the wrong result. You are ignoring the
>> need for leap seconds. If you want a monotonic counter of seconds
>> since some epoch, you must not use UTC, but TAI:
>>
>> <https://en.wikipedia.org/wiki/International_Atomic_Time>
>>
>> When I implmented this, I used a 64-bit counter in 100's of
>> nanoseconds since a date about 6000BC, measuring in TAI. You can
>> convert to UTC easily enough, and then use the timezone tables to get
>> local times.
>
> What happens if the counter is UTC instead of IAT in a typical embedded
> application? There's a time when the counter is synchronized (by a
> manual operation from the user, by NTP or other means). At that time the
> broken-down time shown on the display is precise.
>
> You should wait for the next leap second to have an error of... 1 second.
>
>

The key thing to remember is there is more than one system of time.

As I remember time() returns UTC seconds since the epoch, which ignores
leap seconds. This means the time() function will either pause for 1
second during the leap second, or some systems smear the 1 second
anomoly over a period of time. (This smeared UTC is monotonic, if not
exactly accurate during the smear period).

For time() ALL days are 24*60*60 seconds long.

There are other time systems (Like the TAI) that keep track of leap
seconds, but then to use those to convert to wall-clock time, you need a
historical table of when leap seconds occured, and you need to either
refuse to handle the farther future or admit you are needing to "Guess"
when those leap seconds will need to be applied.

Most uses of TAI time are for just short intervals without a need to
convert to wall clock.

Re: newlib and time()

<th7da7$12qsd$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1052&group=comp.arch.embedded#1052

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Fri, 30 Sep 2022 11:42:04 -0700
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <th7da7$12qsd$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Sep 2022 18:42:15 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="f33c7294a815895513f05f8832d9b33d";
logging-data="1141645"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/zd1f1bxB8bnVz+wHtB8l7"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:FkodR6sGh6Wqf+wksadEGSt4+ck=
Content-Language: en-US
In-Reply-To: <th6cu8$ufgd$1@dont-email.me>
 by: Don Y - Fri, 30 Sep 2022 18:42 UTC

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?) *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.

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

Re: newlib and time()

<th7e2e$12qsd$2@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1053&group=comp.arch.embedded#1053

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Fri, 30 Sep 2022 11:55:01 -0700
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <th7e2e$12qsd$2@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me>
<1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Sep 2022 18:55:10 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="f33c7294a815895513f05f8832d9b33d";
logging-data="1141645"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18tgmUsRJAuNiKwW8skd4S4"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:wHWtkl0Gn+ctqcbzFRoM/4kkPFk=
Content-Language: en-US
In-Reply-To: <1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>
 by: Don Y - Fri, 30 Sep 2022 18:55 UTC

On 9/30/2022 4:51 AM, Clifford Heath wrote:
> When I implmented this, I used a 64-bit counter in 100's of nanoseconds since a
> date about 6000BC, measuring in TAI. You can convert to UTC easily enough, and
> then use the timezone tables to get local times.

How did you address calls for times during the Gregorian changeover?
Or, times before leap seconds were "created" (misnomer)?

Going back "too far" opens the door for folks to think values
before "recent times" are valid.

I find it easier to treat "system time" as an arbitrary metric
that runs at a nominal 1Hz per second and is never "reset".
(an external timebase allows you to keep adjusting your
notion of a "second"). This ensures that there are always
N seconds between any two *system* times, X and X+N (for all X).

Then, "wall time" is a bogus concept introduced just for human
convenience. Do you prevent a user (or an external reference)
from ever setting the wall time backwards? What if he *wants*
to? Then, anything you've done relying on that is suspect.

You don't FORCE system time to remain in sync with wall time
(even at a specific relative offset) but, rather, treat them
as separate things.

So, if I (the user) want to "schedule an appointment" at 9:00AM,
the code uses the *current* notion of the wall time -- which might
change hundreds of times between now and then, at the whim of the
user. If the wall time suddenly changes, then the time to the
appointment will also change -- including being overshot.

Damn near everything else wants to rely on relative times
which track the system time.

If a user wants to do something "in 5 minutes", you don't
convert that to "current wall time + 5 minutes" but, rather,
schedule it at "current SYSTEM time + 300 seconds".

OTOH, if it is now 11:50 and he wants something to happen at
11:55 (now+5 minutes) then he must *say* "11:55".

This allows a user to know what to expect in light of the
fact that he can change one notion of time but not the other.

Re: newlib and time()

<1719c4af8c944ba6$7$1119599$24dd2e6e@news.thecubenet.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1054&group=comp.arch.embedded#1054

 copy link   Newsgroups: comp.arch.embedded
Date: Sat, 1 Oct 2022 08:43:13 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: newlib and time()
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me> <th6cu8$ufgd$1@dont-email.me> <1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com> <th6r4t$ufge$2@dont-email.me> <VsCZK.65920$JZK5.24376@fx03.iad>
From: no_s...@please.net (Clifford Heath)
In-Reply-To: <VsCZK.65920$JZK5.24376@fx03.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!news.thecubenet.com!not-for-mail
NNTP-Posting-Date: Fri, 30 Sep 2022 22:43:15 +0000
Organization: theCubeNet - www.thecubenet.com
X-Complaints-To: abuse@thecubenet.com
Message-ID: <1719c4af8c944ba6$7$1119599$24dd2e6e@news.thecubenet.com>
X-Received-Bytes: 1795
 by: Clifford Heath - Fri, 30 Sep 2022 22:43 UTC

On 30/9/22 23:48, Richard Damon wrote:
> There are other time systems (Like the TAI) that keep track of leap
> seconds, but then to use those to convert to wall-clock time, you need a
> historical table of when leap seconds occured,

There haven't been that many of them, so it's not a very big table.

> and you need to either
> refuse to handle the farther future or admit you are needing to "Guess"
> when those leap seconds will need to be applied.

There is a proposal to never add more leap seconds anyhow. They never
did anyone any good. Astronomers don't use UTC anyway.

> Most uses of TAI time are for just short intervals without a need to
> convert to wall clock.

Yes. But if you're going to implement a monotonic system, you may as
well do it properly.

Clifford Heath

Re: newlib and time()

<1719c4fc46095b95$1$1902888$28dd226e@news.thecubenet.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1055&group=comp.arch.embedded#1055

 copy link   Newsgroups: comp.arch.embedded
Date: Sat, 1 Oct 2022 08:48:43 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: newlib and time()
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me> <th6cu8$ufgd$1@dont-email.me> <1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com> <th7e2e$12qsd$2@dont-email.me>
From: no_s...@please.net (Clifford Heath)
In-Reply-To: <th7e2e$12qsd$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 27
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!news.thecubenet.com!not-for-mail
NNTP-Posting-Date: Fri, 30 Sep 2022 22:48:45 +0000
X-Complaints-To: abuse@thecubenet.com
Organization: theCubeNet - www.thecubenet.com
Message-ID: <1719c4fc46095b95$1$1902888$28dd226e@news.thecubenet.com>
X-Received-Bytes: 2158
 by: Clifford Heath - Fri, 30 Sep 2022 22:48 UTC

On 1/10/22 04:55, Don Y wrote:
> On 9/30/2022 4:51 AM, Clifford Heath wrote:
>> When I implmented this, I used a 64-bit counter in 100's of
>> nanoseconds since a date about 6000BC, measuring in TAI. You can
>> convert to UTC easily enough, and then use the timezone tables to get
>> local times.
>
> How did you address calls for times during the Gregorian changeover?

You're asking a question about calendars, not time. Different problem.

> I find it easier to treat "system time" as an arbitrary metric
> that runs at a nominal 1Hz per second and is never "reset".
....> Then, "wall time" is a bogus concept introduced just for human
> convenience.  Do you prevent a user (or an external reference)
> from ever setting the wall time backwards?

That doesn't work for someone who's travelling between timezones.
Time keeps advancing regardless, but wall clock time jumps about.
Same problem for DST. Quite a lot of enterprise (financial) systems are
barred from running any transaction processing for an hour during DST
switch-over, because of software that might malfunction.

Correctness is difficult, especially when you build systems on shifting
sands.

Clifford Heath.

Re: newlib and time()

<th7t3l$14eg7$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1056&group=comp.arch.embedded#1056

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Fri, 30 Sep 2022 16:11:39 -0700
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <th7t3l$14eg7$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me>
<1719a125872a8577$1$3262674$e2dde862@news.thecubenet.com>
<th7e2e$12qsd$2@dont-email.me>
<1719c4fc46095b95$1$1902888$28dd226e@news.thecubenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Sep 2022 23:11:49 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="3c521dd1aa07a7a883f832269c2b3a96";
logging-data="1194503"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18vMTgO+UWAQLer3Xlu8okB"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:/z9Xc2DYGR62wdqoFPGSW9Xu1Nc=
In-Reply-To: <1719c4fc46095b95$1$1902888$28dd226e@news.thecubenet.com>
Content-Language: en-US
 by: Don Y - Fri, 30 Sep 2022 23:11 UTC

On 9/30/2022 3:48 PM, Clifford Heath wrote:
> On 1/10/22 04:55, Don Y wrote:
>> On 9/30/2022 4:51 AM, Clifford Heath wrote:
>>> When I implmented this, I used a 64-bit counter in 100's of nanoseconds
>>> since a date about 6000BC, measuring in TAI. You can convert to UTC easily
>>> enough, and then use the timezone tables to get local times.
>>
>> How did you address calls for times during the Gregorian changeover?
>
> You're asking a question about calendars, not time. Different problem.

They are related as time is often interpreted relative to some
*other* "bogus concept" (e.g., calendar) related to how humans want
to frame time references.

>> I find it easier to treat "system time" as an arbitrary metric
>> that runs at a nominal 1Hz per second and is never "reset".
>> Then, "wall time" is a bogus concept introduced just for human
>> convenience.  Do you prevent a user (or an external reference)
>> from ever setting the wall time backwards?
>
> That doesn't work for someone who's travelling between timezones.

Or for someone who wants to change the current wall time.
Note that these library functions were created when "only god"
(sysadm) could change the current notion of time -- and didn't
do so casually.

Now, damn near ever device (c.a.EMBEDDED) allows the user to
dick with the wall clock with impunity. Including intentionally
setting the time incorrectly (e.g., folks who set their alarm clocks
"5 minutes fast" thinking it will somehow trick them to getting
out of bed promptly whereas the CORRECT time might not?)

And, one can have a suite of devices in a single environment
each with their own notion of "now".

> Time keeps advancing regardless, but wall clock time jumps about.

Because wall time has an ill-defined reference point -- that can often
be changed, at will!

E.g., we don't observer DST, here. So, the broadcast TV schedules
are "off" by an hour. When something is advertised as airing at
X mountain time (or pacific time), what does that really mean for us?

> Same problem for DST. Quite a lot of enterprise (financial) systems are barred
> from running any transaction processing for an hour during DST switch-over,
> because of software that might malfunction.
>
> Correctness is difficult, especially when you build systems on shifting sands.

The issue is considerably larger than many folks would think. Because
there are a multitude of time references in most environments; what
your phone claims, what your TV thinks, what your PC/time server thinks,
how you've set the clock on your microwave, bedside alarm, etc.

If you have two "systems" (appliances) interacting, which one's
notion of time should you abide?

How do you *report* a timestamp on an event that happened 5 minutes
ago -- if the wall clock was set BACKWARDS by an hour in the intervening
interval? Should the timestamp reflect a *future* time ("The event
happen-ED 55 minutes *from* now")? Should it be adjusted to reflect
the time at which it occurred relative to the current notion of
wall time?

How do you *order* events /ex post factum/ in the presence of such
ambiguity?

(i.e., I map everything, internally, to system time as that lets
me KNOW their relative orders, regardless of what the "wall clock"
said at the time.)

If you've scheduled "something" to happen at 11:55 and the user
sets the wall clock forward, an hour (perhaps accidentally), do you
trigger that event (assuming the new "now" > 11:55) instantly? If
you automatically clear "completed events", then setting the wall
clock back to the "correct" time won't resurrect the 11:55 event
at the originally intended "absolute time".

Re: newlib and time()

<thd269$1rfjh$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1057&group=comp.arch.embedded#1057

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Mon, 3 Oct 2022 00:09:12 +0200
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <thd269$1rfjh$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me> <th7da7$12qsd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 2 Oct 2022 22:09:13 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="8d7df676d08003c8bab9f6ceb6a4d80e";
logging-data="1949297"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19EVNP8Qbnyf5Xx5nRwJYzgmpwdS5HSnvY="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:zotLi0E2uvlBC+I/SdHhSHwffi4=
In-Reply-To: <th7da7$12qsd$1@dont-email.me>
 by: pozz - Sun, 2 Oct 2022 22:09 UTC

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.

> *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.
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".

What happens if the time doesn't flow in one direction only?

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

Re: newlib and time()

<thdfsd$21rf1$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1058&group=comp.arch.embedded#1058

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Sun, 2 Oct 2022 19:02:52 -0700
Organization: A noiseless patient Spider
Lines: 140
Message-ID: <thdfsd$21rf1$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me> <th7da7$12qsd$1@dont-email.me>
<thd269$1rfjh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 3 Oct 2022 02:02:53 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="2a53f64825e3da12b00fb7c71849c1d8";
logging-data="2158049"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184lVqU3c0KquzyxODlKFzD"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:BpuhrZ890UX/XA2iXoNLReaG4SI=
In-Reply-To: <thd269$1rfjh$1@dont-email.me>
Content-Language: en-US
 by: Don Y - Mon, 3 Oct 2022 02:02 UTC

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.

Re: newlib and time()

<the2gr$241o8$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1059&group=comp.arch.embedded#1059

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: tauno.vo...@notused.fi.invalid (Tauno Voipio)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Mon, 3 Oct 2022 10:20:57 +0300
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <the2gr$241o8$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me> <th7da7$12qsd$1@dont-email.me>
<thd269$1rfjh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 3 Oct 2022 07:20:59 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="851d11aff2905d560bb7db081ccc4a2f";
logging-data="2230024"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181b/44+0FMCaQFA79808/cafUdEDE0D2k="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.3.1
Cancel-Lock: sha1:088Q8YN6iLJc9K+8i3PB3wZ8tvY=
In-Reply-To: <thd269$1rfjh$1@dont-email.me>
 by: Tauno Voipio - Mon, 3 Oct 2022 07:20 UTC

NTP has solved this question, just get publications of prof. Mills.

There is a short description in Wikipedia article on NTP.

--

-TV

On 3.10.22 1.09, 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.
>
>
>> *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.
> 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".
>
> What happens if the time doesn't flow in one direction only?
>
>
>> [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".
>>
>
>

Re: newlib and time()

<tp48cg$2dln8$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1227&group=comp.arch.embedded#1227

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Wed, 4 Jan 2023 17:09:52 +0100
Organization: A noiseless patient Spider
Lines: 405
Message-ID: <tp48cg$2dln8$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me> <th7da7$12qsd$1@dont-email.me>
<thd269$1rfjh$1@dont-email.me> <thdfsd$21rf1$1@dont-email.me>
<ton2d3$jumb$1@dont-email.me> <too04s$q50i$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 4 Jan 2023 16:09:52 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="8b97628ae398b54715119c43eb001a13";
logging-data="2545384"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+IEYXLgIj7stCRKgWYo9UktncBWvADigs="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:1enfPO0PF23gNKbv2wDCt+hga90=
In-Reply-To: <too04s$q50i$2@dont-email.me>
 by: pozz - Wed, 4 Jan 2023 16:09 UTC

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.

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

>> I admit that this could lead to odd behaviours as you explained. IMHO
>> however there aren't many solutions at startup, mainly if the embedded
>> device should be autonomous and can't accept suggestions from the user.
>
> Note that "wall/calendar time" is strictly a user convenience.  A device
> need only deal with it if it has to interact with a world in which the
> user relates to temporal events using some external timepiece -- which
> may actually be inaccurate!

Yes, of course. At the contrary, NTP is useless at all.

> But, your device can always have its own notion of time that monotonically
> increases -- even if the rate of time that it increases isn't entirely
> accurate wrt "real units" (i.e., if YOUR second is 1.001 REAL seconds,
> that's likely not too important)
>
> So, if you can postpone binding YOUR "system time" (counting jiffies)
> to "wall time", then the problem is postponed.
>
> E.g., I deal with events as referenced to *my* timebase (bogounits):
>   00000006 system initialized
>   00001003 network on-line
>   00001100 accepting requests
>   00020348 request from 10.0.1.88
>   00020499 reply to 10.0.1.88 issued
>   ...
> Eventually, there will be an entry:
>   XXXXXXXX NTPclient receives update (12:42:00.444)
>
> At this point, you can retroactively update the times in the "log" with
> "real" times, relative to the time delivered to the NTP client.
> (or, leave the log in bogounits and not worry about it)

Yes, a log with timestamps can be managed in these ways.

> The real problem comes when <someone> wants <something> to happen at
> some *specific* wall time -- and, you don't yet know what the current
> wall time happens to be!
>
> If that will be guaranteed to be sufficiently far in the future that
> you (think!) the actual wall time will be known to you, then you
> can just cross your fingers and wait to sort out "when" that will be.

Yes.

>> One is to suspend, at startup, all the device activites until a "fresh
>> now" is received from NTP server. After that, the normal tasks are
>> started. As you noted, this could introduce a delay (even a BIG delay,
>> depending on Internet connection and NTP servers) between the power on
>> and the start of tasks. I think this isn't compatible with many
>> applications.
>>
>> Another solution is to fix the code in such a way it correctly faces
>> the situation of a big afterward or backward step in the "now" counter.
>
> You're better off picking a time you KNOW to be in the past so that
> any adjustments continue to run time *forwards*.  We inherently think
> of A happening after B implying that time(A) > time(B).  It's so
> fundamental that you likely don't even notice these dependencies in
> your code/algorithms.
>
>> 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.

>>> 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().
>>
>> Good point. As I wrote before, events that aren't strictly related to
>> wall clock shouldn't be coded with functions() that use now(). If the
>> code that makes a 100ms pulse at an output uses now(), it is wrong and
>> must be corrected.
>
> Time should always be treated "fuzzily".
>
> 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);


Click here to read the complete article
Re: newlib and time()

<tp4jh1$2i50g$2@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1228&group=comp.arch.embedded#1228

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!rocksolid2!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Wed, 4 Jan 2023 12:19:55 -0700
Organization: A noiseless patient Spider
Lines: 294
Message-ID: <tp4jh1$2i50g$2@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me> <th7da7$12qsd$1@dont-email.me>
<thd269$1rfjh$1@dont-email.me> <thdfsd$21rf1$1@dont-email.me>
<ton2d3$jumb$1@dont-email.me> <too04s$q50i$2@dont-email.me>
<tp48cg$2dln8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 4 Jan 2023 19:20:01 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="f50cc2545f1ad66b81b1cb65e3463050";
logging-data="2692112"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19XJUBbrB4t6FnFmJNOeLIk"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:pFnul09tNiUmQRUjUSpHngIDFj0=
Content-Language: en-US
In-Reply-To: <tp48cg$2dln8$1@dont-email.me>
 by: Don Y - Wed, 4 Jan 2023 19:19 UTC

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.


Click here to read the complete article
Re: newlib and time()

<jj7crhlfbshdcscioheuui5e6vuaqv58ae@4ax.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1229&group=comp.arch.embedded#1229

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: gneun...@comcast.net (George Neuner)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Wed, 04 Jan 2023 20:12:14 -0500
Organization: A noiseless patient Spider
Lines: 137
Message-ID: <jj7crhlfbshdcscioheuui5e6vuaqv58ae@4ax.com>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me> <th6cu8$ufgd$1@dont-email.me> <th7da7$12qsd$1@dont-email.me> <thd269$1rfjh$1@dont-email.me> <thdfsd$21rf1$1@dont-email.me> <ton2d3$jumb$1@dont-email.me> <too04s$q50i$2@dont-email.me> <tp48cg$2dln8$1@dont-email.me> <tp4jh1$2i50g$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader01.eternal-september.org; posting-host="f1a118ce40cba3fcd9f2fa0b2d02a7bb";
logging-data="2757985"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/PILb2R245B10h/61kjWIGSjEoK0KcVUE="
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:tS8qcIK4ZKAarf4wradraDIi0CE=
 by: George Neuner - Thu, 5 Jan 2023 01:12 UTC

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

Re: newlib and time()

<tp5dbt$2nb2q$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1230&group=comp.arch.embedded#1230

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: newlib and time()
Date: Wed, 4 Jan 2023 19:40:54 -0700
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <tp5dbt$2nb2q$1@dont-email.me>
References: <th62c5$ufge$1@dont-email.me> <th64eh$uo0n$1@dont-email.me>
<th6cu8$ufgd$1@dont-email.me> <th7da7$12qsd$1@dont-email.me>
<thd269$1rfjh$1@dont-email.me> <thdfsd$21rf1$1@dont-email.me>
<ton2d3$jumb$1@dont-email.me> <too04s$q50i$2@dont-email.me>
<tp48cg$2dln8$1@dont-email.me> <tp4jh1$2i50g$2@dont-email.me>
<jj7crhlfbshdcscioheuui5e6vuaqv58ae@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Jan 2023 02:41:01 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d3b20f6c92cd51eafde47fecbc453a61";
logging-data="2862170"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/AcXRdGN0XYAFr5Ml5kt97"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:lqvav8sUsec4ryBWXxebLB3uGhY=
In-Reply-To: <jj7crhlfbshdcscioheuui5e6vuaqv58ae@4ax.com>
Content-Language: en-US
 by: Don Y - Thu, 5 Jan 2023 02:40 UTC

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.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor