Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi, I was just literally about to send an email with pretty much the same arguments Kaspar wrote right now. So I skip them and throw in a +1 instead. > Below that, context switching takes the bulk of the time, so spinning (not > using a callback) is probably preferable. I think that the ws281x driver is currently one of the most timing-critical driver in RIOT. And in the worst case scenario it currently is useable, it needs a delay of exactly 2-3 CPU cycles. On the same hardware, it takes longer from an interrupt request coming in to the ISR being run than those 2-3 CPU cycles. To me, it is safe to say that there are simply use cases that just cannot be addressed with any high level timer API. So in my opinion focusing on the use cases that can reasonably be addressed with a high level API makes most sense. And based on this, follow up PRs can try to squeeze as much efficiency out of the implementation as possible without sacrificing something on the other metrics (e.g. ROM/RAM consumption, maintainability, flexibility, etc.). Kind regards, Marian On Mon, 9 Dec 2019 23:28:19 +0100 Kaspar Schleiser wrote: > Hey, > > On 12/9/19 10:32 PM, Oleg Hahm wrote: > > Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking > > here. CPU time or memory? Probably both, right? Regarding the CPU > > efficiency, I would assume that this also dictates the maximum precision, > > right? > > I don't think so. The hardware dictates the maximum precision. > > I wrote a test (its in tests/ztimer_overhead in the ztimer PR), that > sets a timer, which in its callback gets the current time, and then > calculates the differenve. > > Uncorrected (with XTIMER_OVERHEAD=0 or the ztimer equivalent), both add > a pretty constant ~7us, on an nrf52dk using a periph timer clocked at > 1MHz. There's not much happening in this simplest case. I don't think we > can carve off much in any high level timer implementation, compared to > using periph_timer or even skipping that and using plain register writes. > > Callback based (high-level) timers are only suitable for timeouts down > to a certain level (somewhere below 10us on our hardware scope). Below > that, context switching takes the bulk of the time, so spinning (not > using a callback) is probably preferable. > I mean, if a device can do 100k context switches per second, each takes > 10us. Setting a timer to anything below that might work, but doesn't > make much sense. > > Even ztimer using only 32bit arithmetic vs. xtimer sometimes needing > 64bit comparisons might show measurable differences when there are many > timers active, but I honestly don't know if this difference can become a > deal breaker, or even just relevant. > > Cycle wise, xtimer is not terrible to begin with. > > That said, if we get an alternative that matches or improves on most > metrics and is still more flexible, and allows proper sleeping, then I > take any percent improvement with a happy face. > > > Regarding > > memory we have probably different requirements: ROM for the whole thing, RAM > > per instance and for the module itself. > > > > Here, the requirement should be "needs to fulfill all other > requirements", and from that point on, less is better. > xtimer and ztimer are comparable in ROM and RAM usage. Again, I don't > think that any high level timer implementation can bring disruptive > reduction here. > > I'm not looking forward to coming up with requirements for accuracy. > Simple tests (like the overhead test from above) are easy to optimize so > a timer hits bang on the target time, by subtracting a measured overhead > from any interval. Figuring out the impact of having N timers in the > list is difficult, and more difficult to correct. > > Here we could come up with a test setting as many timers as fit in RAM > to random values, then measuring each timer's punctuality. All making > sure that the target times don't overlap. > > But all the requirements don't help over the fact that xtimer currently > just doesn't work for many identified use cases. Fixing that would > require substantial code changes, probably including API changes. > Knowning the complexity of xtimer, I decided to give a rewrite from > scratch a try, and IMO, the result is quite nice. > > I'd maybe roll up the discussion from a different side: If noone can > identify a conceptual flaw, something where a different implementation > or design might yield benefits compared to ztimer, and if ztimer does > not show regressions compared to xtimer, but improves on some relevant > aspects, why don't we consider going with better in the short term and > pursue provably best as a longer term goal? > > >>> Besides I'm missing a requirement regarding the maximum granularity and > >>> the maximum duration of a timer. > >> > >> You mean minimum granularity? > > > > In my understanding of the term maximum granularity translates to the finest > > granularity. > > Yup, got it. > > Kaspar >
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hey, On 12/9/19 10:32 PM, Oleg Hahm wrote: > Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking > here. CPU time or memory? Probably both, right? Regarding the CPU efficiency, > I would assume that this also dictates the maximum precision, right? I don't think so. The hardware dictates the maximum precision. I wrote a test (its in tests/ztimer_overhead in the ztimer PR), that sets a timer, which in its callback gets the current time, and then calculates the differenve. Uncorrected (with XTIMER_OVERHEAD=0 or the ztimer equivalent), both add a pretty constant ~7us, on an nrf52dk using a periph timer clocked at 1MHz. There's not much happening in this simplest case. I don't think we can carve off much in any high level timer implementation, compared to using periph_timer or even skipping that and using plain register writes. Callback based (high-level) timers are only suitable for timeouts down to a certain level (somewhere below 10us on our hardware scope). Below that, context switching takes the bulk of the time, so spinning (not using a callback) is probably preferable. I mean, if a device can do 100k context switches per second, each takes 10us. Setting a timer to anything below that might work, but doesn't make much sense. Even ztimer using only 32bit arithmetic vs. xtimer sometimes needing 64bit comparisons might show measurable differences when there are many timers active, but I honestly don't know if this difference can become a deal breaker, or even just relevant. Cycle wise, xtimer is not terrible to begin with. That said, if we get an alternative that matches or improves on most metrics and is still more flexible, and allows proper sleeping, then I take any percent improvement with a happy face. > Regarding > memory we have probably different requirements: ROM for the whole thing, RAM > per instance and for the module itself. > Here, the requirement should be "needs to fulfill all other requirements", and from that point on, less is better. xtimer and ztimer are comparable in ROM and RAM usage. Again, I don't think that any high level timer implementation can bring disruptive reduction here. I'm not looking forward to coming up with requirements for accuracy. Simple tests (like the overhead test from above) are easy to optimize so a timer hits bang on the target time, by subtracting a measured overhead from any interval. Figuring out the impact of having N timers in the list is difficult, and more difficult to correct. Here we could come up with a test setting as many timers as fit in RAM to random values, then measuring each timer's punctuality. All making sure that the target times don't overlap. But all the requirements don't help over the fact that xtimer currently just doesn't work for many identified use cases. Fixing that would require substantial code changes, probably including API changes. Knowning the complexity of xtimer, I decided to give a rewrite from scratch a try, and IMO, the result is quite nice. I'd maybe roll up the discussion from a different side: If noone can identify a conceptual flaw, something where a different implementation or design might yield benefits compared to ztimer, and if ztimer does not show regressions compared to xtimer, but improves on some relevant aspects, why don't we consider going with better in the short term and pursue provably best as a longer term goal? >>> Besides I'm missing a requirement regarding the maximum granularity and the >>> maximum duration of a timer. >> >> You mean minimum granularity? > > In my understanding of the term maximum granularity translates to the finest > granularity. Yup, got it. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hey! On Mon, Dec 09, 2019 at 10:07:16PM +0100, Kaspar Schleiser wrote: > > Anyway, I think we need to define what "very efficient timers for use in > > time-critical drivers" means in order to being able to check whether the > > proposal fulfills the requirement or not. > > We can try. What would that look like? > Something like "must not incur more than x us overhead on hardware of > class y"? Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking here. CPU time or memory? Probably both, right? Regarding the CPU efficiency, I would assume that this also dictates the maximum precision, right? Regarding memory we have probably different requirements: ROM for the whole thing, RAM per instance and for the module itself. > > Besides I'm missing a requirement regarding the maximum granularity and the > > maximum duration of a timer. > > You mean minimum granularity? In my understanding of the term maximum granularity translates to the finest granularity. Cheers Oleg -- T he bes thin gabou tTCPfl owcontr oljokesi sthatthey knowwhento backo ff ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Oleg et all, On 12/9/19 9:25 PM, Oleg Hahm wrote: > I think the problem statement and the requirements could indeed be more > precise - while I must admit that a lack of precise requirements is a failure > of the RIOT community. Yes, that could be. I intentionally did not add requirements. I just added a clarification on "adaptable to varying configurations of timers, RTTs, RTCs (use RTC if available for super-long-time timers)", trying to convey later on that xtimer just doesn't fulfill this requirement, and "fixing" that involves changing most of it. > Anyway, I think we need to define what "very efficient timers for use in > time-critical drivers" means in order to being able to check whether the > proposal fulfills the requirement or not. We can try. What would that look like? Something like "must not incur more than x us overhead on hardware of class y"? > Besides I'm missing a requirement regarding the maximum granularity and the > maximum duration of a timer. You mean minimum granularity? Anyway, good point. xtimer has 64bit range with 1us precision. ztimer makes the trade-off of only offering 32bit range, but with flexible precision. I'm not sure we can get away with that, if just for the fact that we have code using the 64bit functions, which means automatic code conversion using coccinelle is not (easily) possible. I think I'll just implement a 64bit version (as an extra module) so a possible transition gets easier. And to checkbox "any precision possible (if hardware keeps up), 64bit range supported". Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Folks! Can we get back to the actual problem at hand, please? Let me recap: Kaspar came up with a proposal for a new timer API, since xtimer has flaws (as identified by multiple members of the RIOT community during the last ~4 years) and is apparently not fixable (at least no one came up with a concrete proposal to fix it to the best of my knowledge). Having a concrete implementation proposal is great. Thanks for the effort of designing and implementing the current state of ztimer and thanks for the documentation of this effort! I think the problem statement and the requirements could indeed be more precise - while I must admit that a lack of precise requirements is a failure of the RIOT community. Anyway, I think we need to define what "very efficient timers for use in time-critical drivers" means in order to being able to check whether the proposal fulfills the requirement or not. Besides I'm missing a requirement regarding the maximum granularity and the maximum duration of a timer. Cheers Oleg -- The good thing about object oriented jokes is they bring their own laughter method. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Marian,
On 09/12/2019 21:00, Marian Buschsieweke wrote:
I'd like to point out that the research community has largely dismissed Karl
Poppers contribution to the demarcation problem, as largely accepted fields of
research are not falsifiable. E.g. the evolution theory cannot be falsified.
https://rationalwiki.org/wiki/Falsifiability_of_evolution ?
Maybe it is time for you to move on as well?
Well, if we give up rational argumentation, then we end up in blind
guesswork or insignificant conversation.
Statements such as "I really like my timer drift today!" are amusing,
but not helpful.
Cheers,
Thomas
On Mon, 9 Dec 2019 20:35:24 +0100
"Thomas C. Schmidt" wrote:
Hi Marian,
On 09/12/2019 20:06, Marian Buschsieweke wrote:
Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
"falsifiable" is a standard principle in science: It is sometimes
difficult to verify a statement, if application contexts cannot be
exhaustively enumerated ("It never rains in California"). Falsification
is often simpler, since only a counter-example is needed. A statement
that is neither verifiable nor falsifiable is useless for rigorous
argumentation.
"RIOT needs an easy to use, efficient and flexible timer system" is such
a poster child of a non-arguable statement and may move to the introduction.
Regarding xtimer:
If the current 1 us resolution in the API is the key problem, then this
should be stated clearly in the problem statement so that it can be
questioned and discussed.
Best,
Thomas
Do you want to be able to check that a given problem cannot be solved by
existing features?
This should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
The mayor issue is that the API uses a fixed 1 µs resolution. As an uint32_t in
1 µs resolution would overflow after ~72 minutes, an uint64_t is needed as a
direct consequence. This in turn results in the use of 64 bit arithmetic, which
is very ill suited on IoT devices, especially on 8 bit and 16 bit platforms.
Additionally, an API using 1µs resolution can be best implemented with fast
timer hardware. But those usually prevent any power saving modes. This is very
ill suited for the huge majority of IoT scenarios.
Simply changing xtimer to use an RTT instead would solve the power saving
issue. But RTTs usually operate at frequencies in the range of 1kHz -
32.678kHz. A base unit of 1µs makes very little sense in that case. And I'm
aware of places in RIOT that depend on xtimer having a resolution in the order
of microseconds; those would just break.
All those issues are direct consequences of the use of a fixed 1 µs resolution.
Allowing callers to specify the timer resolution would fix these. But that
requires an API change.
(All that reasoning is part of the wiki page already.)
Kind regards,
Marian
On Mon, 9 Dec 2019 18:48:39 +0100
"Thomas C. Schmidt" wrote:
Hi,
if this is a "problem statement and design document", then concise and
measurable requirements on power management should go into the
corresponding section.
Also, a clear and falsifiable problem statement should be given. This
should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
A long list of ztimer promises appears rather unessential and confusing.
Thomas
On 09/12/2019 17:45, Kaspar Schleiser wrote:
Hi,
On 12/9/19 4:52 PM, Kaspar Schleiser wrote:
Hi Robert,
On 12/9/19 4:25 PM, Robert Hartung wrote:
Do we need to put any thoughts in power management / low_power /
integration with pm_layered? Or are the possible issues addreses /
already talked about?
Yes and yes. ;)
I'll my thoughts so far.
I've added this to the wiki page:
# Power management considerations
- currently, ztimer is pm_layered agnostic. If a timer is set on a
periph_timer, this would probably not prevent sleep (timer would not
trigger), whereas if a ztimer is set on a rtt, it would behave as
expected (timer hardware keeps running in sleep, timer isr wakes up MCU).
- (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`),
the backend device blocks sleeping if necessary. IMO this is the minimum
requirement, but still needs to be implemented.
- Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC)
*keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU
enters sleep (unless a timeout is scheduled). This is current behaviour
*if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is
using RTT/RTC.
This would mean that `before = ztimer_now(clock); do something; diff =
ztimer_now(clock) - before;` only works if either `do_something` does
not schedule away the thread causing sleep *or* a clock is used that
runs in sleep mode.
- the behaviour could be accessible either through defines
(ZTIMER_USEC_LPM_MODE or
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Dear Thomas,
I'd like to point out that the research community has largely dismissed Karl
Poppers contribution to the demarcation problem, as largely accepted fields of
research are not falsifiable. E.g. the evolution theory cannot be falsified.
Maybe it is time for you to move on as well?
Kind regards,
Marian
On Mon, 9 Dec 2019 20:35:24 +0100
"Thomas C. Schmidt" wrote:
> Hi Marian,
>
> On 09/12/2019 20:06, Marian Buschsieweke wrote:
>
> >> Also, a clear and falsifiable problem statement should be given.
> >
> > could you elaborate on what you mean by a problem statement being
> > falsifiable?
>
> "falsifiable" is a standard principle in science: It is sometimes
> difficult to verify a statement, if application contexts cannot be
> exhaustively enumerated ("It never rains in California"). Falsification
> is often simpler, since only a counter-example is needed. A statement
> that is neither verifiable nor falsifiable is useless for rigorous
> argumentation.
> "RIOT needs an easy to use, efficient and flexible timer system" is such
> a poster child of a non-arguable statement and may move to the introduction.
>
> Regarding xtimer:
>
> If the current 1 us resolution in the API is the key problem, then this
> should be stated clearly in the problem statement so that it can be
> questioned and discussed.
>
> Best,
> Thomas
>
> > Do you want to be able to check that a given problem cannot be solved by
> > existing features?
> >
> >> This should IMO address the question, why timer problems cannot be fixed by
> >> simply repairing the xtimer (+ underlying HW abstractions).
> >
> > The mayor issue is that the API uses a fixed 1 µs resolution. As an
> > uint32_t in
> > 1 µs resolution would overflow after ~72 minutes, an uint64_t is needed as a
> > direct consequence. This in turn results in the use of 64 bit arithmetic,
> > which
> > is very ill suited on IoT devices, especially on 8 bit and 16 bit platforms.
> >
> > Additionally, an API using 1µs resolution can be best implemented with fast
> > timer hardware. But those usually prevent any power saving modes. This is
> > very
> > ill suited for the huge majority of IoT scenarios.
> >
> > Simply changing xtimer to use an RTT instead would solve the power saving
> > issue. But RTTs usually operate at frequencies in the range of 1kHz -
> > 32.678kHz. A base unit of 1µs makes very little sense in that case. And I'm
> > aware of places in RIOT that depend on xtimer having a resolution in the
> > order
> > of microseconds; those would just break.
> >
> > All those issues are direct consequences of the use of a fixed 1 µs
> > resolution.
> > Allowing callers to specify the timer resolution would fix these. But that
> > requires an API change.
> >
> > (All that reasoning is part of the wiki page already.)
> >
> > Kind regards,
> > Marian
> >
> > On Mon, 9 Dec 2019 18:48:39 +0100
> > "Thomas C. Schmidt" wrote:
> >
> >> Hi,
> >>
> >> if this is a "problem statement and design document", then concise and
> >> measurable requirements on power management should go into the
> >> corresponding section.
> >>
> >> Also, a clear and falsifiable problem statement should be given. This
> >> should IMO address the question, why timer problems cannot be fixed by
> >> simply repairing the xtimer (+ underlying HW abstractions).
> >>
> >> A long list of ztimer promises appears rather unessential and confusing.
> >>
> >> Thomas
> >>
> >> On 09/12/2019 17:45, Kaspar Schleiser wrote:
> >>> Hi,
> >>>
> >>> On 12/9/19 4:52 PM, Kaspar Schleiser wrote:
> Hi Robert,
>
> On 12/9/19 4:25 PM, Robert Hartung wrote:
> > Do we need to put any thoughts in power management / low_power /
> > integration with pm_layered? Or are the possible issues addreses /
> > already talked about?
>
> Yes and yes. ;)
>
> I'll my thoughts so far.
> >>>
> >>> I've added this to the wiki page:
> >>>
> >>> # Power management considerations
> >>> - currently, ztimer is pm_layered agnostic. If a timer is set on a
> >>> periph_timer, this would probably not prevent sleep (timer would not
> >>> trigger), whereas if a ztimer is set on a rtt, it would behave as
> >>> expected (timer hardware keeps running in sleep, timer isr wakes up MCU).
> >>>
> >>> - (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`),
> >>> the backend device blocks sleeping if necessary. IMO this is the minimum
> >>> requirement, but still needs to be implemented.
> >>>
> >>> - Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC)
> >>> *keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU
> >>> enters sleep (unless a timeout is scheduled). This is current behaviour
> >>> *if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is
> >>> using RTT/RTC.
> >>>
> >>> This would mean that `before = ztimer_now(clock); do something; diff =
> >>> ztimer_now(clock) - before;` only works if either
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Marian,
On 09/12/2019 20:06, Marian Buschsieweke wrote:
Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
"falsifiable" is a standard principle in science: It is sometimes
difficult to verify a statement, if application contexts cannot be
exhaustively enumerated ("It never rains in California"). Falsification
is often simpler, since only a counter-example is needed. A statement
that is neither verifiable nor falsifiable is useless for rigorous
argumentation.
"RIOT needs an easy to use, efficient and flexible timer system" is such
a poster child of a non-arguable statement and may move to the introduction.
Regarding xtimer:
If the current 1 us resolution in the API is the key problem, then this
should be stated clearly in the problem statement so that it can be
questioned and discussed.
Best,
Thomas
Do you want to be able to check that a given problem cannot be solved by
existing features?
This should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
The mayor issue is that the API uses a fixed 1 µs resolution. As an uint32_t in
1 µs resolution would overflow after ~72 minutes, an uint64_t is needed as a
direct consequence. This in turn results in the use of 64 bit arithmetic, which
is very ill suited on IoT devices, especially on 8 bit and 16 bit platforms.
Additionally, an API using 1µs resolution can be best implemented with fast
timer hardware. But those usually prevent any power saving modes. This is very
ill suited for the huge majority of IoT scenarios.
Simply changing xtimer to use an RTT instead would solve the power saving
issue. But RTTs usually operate at frequencies in the range of 1kHz -
32.678kHz. A base unit of 1µs makes very little sense in that case. And I'm
aware of places in RIOT that depend on xtimer having a resolution in the order
of microseconds; those would just break.
All those issues are direct consequences of the use of a fixed 1 µs resolution.
Allowing callers to specify the timer resolution would fix these. But that
requires an API change.
(All that reasoning is part of the wiki page already.)
Kind regards,
Marian
On Mon, 9 Dec 2019 18:48:39 +0100
"Thomas C. Schmidt" wrote:
Hi,
if this is a "problem statement and design document", then concise and
measurable requirements on power management should go into the
corresponding section.
Also, a clear and falsifiable problem statement should be given. This
should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
A long list of ztimer promises appears rather unessential and confusing.
Thomas
On 09/12/2019 17:45, Kaspar Schleiser wrote:
Hi,
On 12/9/19 4:52 PM, Kaspar Schleiser wrote:
Hi Robert,
On 12/9/19 4:25 PM, Robert Hartung wrote:
Do we need to put any thoughts in power management / low_power /
integration with pm_layered? Or are the possible issues addreses /
already talked about?
Yes and yes. ;)
I'll my thoughts so far.
I've added this to the wiki page:
# Power management considerations
- currently, ztimer is pm_layered agnostic. If a timer is set on a
periph_timer, this would probably not prevent sleep (timer would not
trigger), whereas if a ztimer is set on a rtt, it would behave as
expected (timer hardware keeps running in sleep, timer isr wakes up MCU).
- (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`),
the backend device blocks sleeping if necessary. IMO this is the minimum
requirement, but still needs to be implemented.
- Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC)
*keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU
enters sleep (unless a timeout is scheduled). This is current behaviour
*if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is
using RTT/RTC.
This would mean that `before = ztimer_now(clock); do something; diff =
ztimer_now(clock) - before;` only works if either `do_something` does
not schedule away the thread causing sleep *or* a clock is used that
runs in sleep mode.
- the behaviour could be accessible either through defines
(ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part
of the ztimer API
- in addition, we could add functions to explicitly tell the clocks to
stay available until released, e.g., `ztimer_acquire(clock); before =
ztimer_now(clock); do something; diff = ztimer_now(clock) - before;
ztimer_release(clock);`.
Once the "if timer is scheduled, don't sleep" is implemented, this
could also be worked around by:
`ztimer_set(clock, dummy, 0x); ...; ztimer_cancel(clock,
dummy);`
Feedback appreciated!
Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
--
Prof. Dr. Thomas C. Schmidt
°
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Thomas, > Also, a clear and falsifiable problem statement should be given. could you elaborate on what you mean by a problem statement being falsifiable? Do you want to be able to check that a given problem cannot be solved by existing features? > This should IMO address the question, why timer problems cannot be fixed by > simply repairing the xtimer (+ underlying HW abstractions). The mayor issue is that the API uses a fixed 1 µs resolution. As an uint32_t in 1 µs resolution would overflow after ~72 minutes, an uint64_t is needed as a direct consequence. This in turn results in the use of 64 bit arithmetic, which is very ill suited on IoT devices, especially on 8 bit and 16 bit platforms. Additionally, an API using 1µs resolution can be best implemented with fast timer hardware. But those usually prevent any power saving modes. This is very ill suited for the huge majority of IoT scenarios. Simply changing xtimer to use an RTT instead would solve the power saving issue. But RTTs usually operate at frequencies in the range of 1kHz - 32.678kHz. A base unit of 1µs makes very little sense in that case. And I'm aware of places in RIOT that depend on xtimer having a resolution in the order of microseconds; those would just break. All those issues are direct consequences of the use of a fixed 1 µs resolution. Allowing callers to specify the timer resolution would fix these. But that requires an API change. (All that reasoning is part of the wiki page already.) Kind regards, Marian On Mon, 9 Dec 2019 18:48:39 +0100 "Thomas C. Schmidt" wrote: > Hi, > > if this is a "problem statement and design document", then concise and > measurable requirements on power management should go into the > corresponding section. > > Also, a clear and falsifiable problem statement should be given. This > should IMO address the question, why timer problems cannot be fixed by > simply repairing the xtimer (+ underlying HW abstractions). > > A long list of ztimer promises appears rather unessential and confusing. > > Thomas > > On 09/12/2019 17:45, Kaspar Schleiser wrote: > > Hi, > > > > On 12/9/19 4:52 PM, Kaspar Schleiser wrote: > >> Hi Robert, > >> > >> On 12/9/19 4:25 PM, Robert Hartung wrote: > >>> Do we need to put any thoughts in power management / low_power / > >>> integration with pm_layered? Or are the possible issues addreses / > >>> already talked about? > >> > >> Yes and yes. ;) > >> > >> I'll my thoughts so far. > > > > I've added this to the wiki page: > > > > # Power management considerations > > - currently, ztimer is pm_layered agnostic. If a timer is set on a > > periph_timer, this would probably not prevent sleep (timer would not > > trigger), whereas if a ztimer is set on a rtt, it would behave as > > expected (timer hardware keeps running in sleep, timer isr wakes up MCU). > > > > - (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`), > > the backend device blocks sleeping if necessary. IMO this is the minimum > > requirement, but still needs to be implemented. > > > > - Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC) > > *keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU > > enters sleep (unless a timeout is scheduled). This is current behaviour > > *if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is > > using RTT/RTC. > > > >This would mean that `before = ztimer_now(clock); do something; diff = > > ztimer_now(clock) - before;` only works if either `do_something` does > > not schedule away the thread causing sleep *or* a clock is used that > > runs in sleep mode. > > > > - the behaviour could be accessible either through defines > > (ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part > > of the ztimer API > > > > - in addition, we could add functions to explicitly tell the clocks to > > stay available until released, e.g., `ztimer_acquire(clock); before = > > ztimer_now(clock); do something; diff = ztimer_now(clock) - before; > > ztimer_release(clock);`. > >Once the "if timer is scheduled, don't sleep" is implemented, this > > could also be worked around by: > > `ztimer_set(clock, dummy, 0x); ...; ztimer_cancel(clock, > > dummy);` > > > > > > Feedback appreciated! > > > > Kaspar > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > > pgp9YsMqnufSk.pgp Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi, if this is a "problem statement and design document", then concise and measurable requirements on power management should go into the corresponding section. Also, a clear and falsifiable problem statement should be given. This should IMO address the question, why timer problems cannot be fixed by simply repairing the xtimer (+ underlying HW abstractions). A long list of ztimer promises appears rather unessential and confusing. Thomas On 09/12/2019 17:45, Kaspar Schleiser wrote: Hi, On 12/9/19 4:52 PM, Kaspar Schleiser wrote: Hi Robert, On 12/9/19 4:25 PM, Robert Hartung wrote: Do we need to put any thoughts in power management / low_power / integration with pm_layered? Or are the possible issues addreses / already talked about? Yes and yes. ;) I'll my thoughts so far. I've added this to the wiki page: # Power management considerations - currently, ztimer is pm_layered agnostic. If a timer is set on a periph_timer, this would probably not prevent sleep (timer would not trigger), whereas if a ztimer is set on a rtt, it would behave as expected (timer hardware keeps running in sleep, timer isr wakes up MCU). - (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`), the backend device blocks sleeping if necessary. IMO this is the minimum requirement, but still needs to be implemented. - Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC) *keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU enters sleep (unless a timeout is scheduled). This is current behaviour *if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is using RTT/RTC. This would mean that `before = ztimer_now(clock); do something; diff = ztimer_now(clock) - before;` only works if either `do_something` does not schedule away the thread causing sleep *or* a clock is used that runs in sleep mode. - the behaviour could be accessible either through defines (ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part of the ztimer API - in addition, we could add functions to explicitly tell the clocks to stay available until released, e.g., `ztimer_acquire(clock); before = ztimer_now(clock); do something; diff = ztimer_now(clock) - before; ztimer_release(clock);`. Once the "if timer is scheduled, don't sleep" is implemented, this could also be worked around by: `ztimer_set(clock, dummy, 0x); ...; ztimer_cancel(clock, dummy);` Feedback appreciated! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi, On 12/9/19 4:52 PM, Kaspar Schleiser wrote: > Hi Robert, > > On 12/9/19 4:25 PM, Robert Hartung wrote: >> Do we need to put any thoughts in power management / low_power / >> integration with pm_layered? Or are the possible issues addreses / >> already talked about? > > Yes and yes. ;) > > I'll my thoughts so far. I've added this to the wiki page: # Power management considerations - currently, ztimer is pm_layered agnostic. If a timer is set on a periph_timer, this would probably not prevent sleep (timer would not trigger), whereas if a ztimer is set on a rtt, it would behave as expected (timer hardware keeps running in sleep, timer isr wakes up MCU). - (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`), the backend device blocks sleeping if necessary. IMO this is the minimum requirement, but still needs to be implemented. - Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC) *keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU enters sleep (unless a timeout is scheduled). This is current behaviour *if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is using RTT/RTC. This would mean that `before = ztimer_now(clock); do something; diff = ztimer_now(clock) - before;` only works if either `do_something` does not schedule away the thread causing sleep *or* a clock is used that runs in sleep mode. - the behaviour could be accessible either through defines (ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part of the ztimer API - in addition, we could add functions to explicitly tell the clocks to stay available until released, e.g., `ztimer_acquire(clock); before = ztimer_now(clock); do something; diff = ztimer_now(clock) - before; ztimer_release(clock);`. Once the "if timer is scheduled, don't sleep" is implemented, this could also be worked around by: `ztimer_set(clock, dummy, 0x); ...; ztimer_cancel(clock, dummy);` Feedback appreciated! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] How to deal with lost interrupts?
Hi, On 12/9/19 5:02 PM, José Ignacio Alamos wrote: > No, I wouldn't consider those lost interrupts (because messages are > lost, not IRQs). Ok, thanks for clarifying! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Robert, On 12/9/19 4:25 PM, Robert Hartung wrote: > Do we need to put any thoughts in power management / low_power / > integration with pm_layered? Or are the possible issues addreses / > already talked about? Yes and yes. ;) I'll my thoughts so far. Thanks! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Robert, On 12/9/19 4:19 PM, Robert Hartung wrote: > why are 8-bit timers not listed? Intentional or unintentional? Unintentional! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] How to deal with lost interrupts?
Hey Jose, On 12/9/19 3:46 PM, José Ignacio Alamos wrote: > The main question here is, how should we handle lost interrupts in > general? Let's say: What do you mean by "lost interrupt"? GNRC uses messages to pass an ISR from the interrupt handler to "userspace". Those can be lost. Are you referring to that? Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hey again ;) Do we need to put any thoughts in power management / low_power / integration with pm_layered? Or are the possible issues addreses / already talked about? Regards Robert On 09.12.19 14:49, Kaspar Schleiser wrote: > Hey everyone, > > since the RIOT Summit in Helsinki, I've put quite some work into ztimer, > a possible successor to xtimer. > > If you're interested, please see an updated design document here: [1] > > Cheers, > Kaspar > > [1] > https://github.com/RIOT-OS/RIOT/wiki/ztimer-problem-statement-and-design-document > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Robert Hartung, M.Sc. Technische Universität Braunschweig Institut für Betriebssysteme und Rechnerverbund Mühlenpfordtstr. 23, Raum 115 38106 Braunschweig Fon: +49 (531) 391 - 3246 Fax: +49 (531) 391 - 5936 E-Mail: hart...@ibr.cs.tu-bs.de WWW: https://www.ibr.cs.tu-bs.de/users/hartung/ ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Kaspar, why are 8-bit timers not listed? Intentional or unintentional? Regards, Robert On 09.12.19 14:49, Kaspar Schleiser wrote: > Hey everyone, > > since the RIOT Summit in Helsinki, I've put quite some work into ztimer, > a possible successor to xtimer. > > If you're interested, please see an updated design document here: [1] > > Cheers, > Kaspar > > [1] > https://github.com/RIOT-OS/RIOT/wiki/ztimer-problem-statement-and-design-document > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Robert Hartung, M.Sc. Technische Universität Braunschweig Institut für Betriebssysteme und Rechnerverbund Mühlenpfordtstr. 23, Raum 115 38106 Braunschweig Fon: +49 (531) 391 - 3246 Fax: +49 (531) 391 - 5936 E-Mail: hart...@ibr.cs.tu-bs.de WWW: https://www.ibr.cs.tu-bs.de/users/hartung/ ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] ztimer - a new high-level timer for RIOT
Hey everyone, since the RIOT Summit in Helsinki, I've put quite some work into ztimer, a possible successor to xtimer. If you're interested, please see an updated design document here: [1] Cheers, Kaspar [1] https://github.com/RIOT-OS/RIOT/wiki/ztimer-problem-statement-and-design-document ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
