Hi Kaspar, Marian,
thanks for responding.
Let me propose the following: we make merging ztimer *as a distinct and
optional module* independent of changing RIOT's default timer
implementation. The latter can be done within the RDM.
IMO, ztimer is quite usable already, and even if only used as
multiplexer for the RTT, it provides a lot of benefit. I don't see a
reason not to merge it (when it's been reviewed properly), as an
optional module.
We can, in parallel, work on the RDM. If it turns out there's some
better option than ztimer, no harm was done, I'll of course happily
accept that.
I'd favor to not merge it before we worked on the RDM as it may show
that there are things that should be done differently.
But with our current state of xtimer there is not much harm to be done
anyway ;)
Also ztimer is providing solutions to problems we currently have no
alternatives for - so I won't be blocking this ;)
I already have a basic xtimer benchmark application (for timing
set()/remove()/now() in pathetic cases), which can provide at least some
numbers. I'll PR that today.
perfect!
Regarding "fixing" xtimer vs a rewrite from scratch, I'd like to point
out that #9503 alone changes (well, removes) ~450 lines of *logic code*.
That is three quarters of xtimer's total code, including definitions and
prototypes. IMO, we need to acknowledge that changing that amount of
code does not result in the same code base. We should call it "ytimer".
The amount of reviewing, validation and testing should be the same as
for a rewrite. Or maybe just be measured in "amount of lines changed".
Agree. (Just to be sure: I understand "calling it ytimer" in a
metaphorical way)
Regarding whether a "clock" parameter makes sense, this is something we
should explore within the RDM. I think you need to prototype a function
that chooses a suitable frequency from multiple options (without relying
on an explicit parameter for that). (I'd actually suggest you use ztimer
as basis, as there you have multiple, multiplexed backends using the
same API. :) ). You might even be successful. At that point, an RDM can
decide if that functionality should move down the layers.
Sounds reasonable.
To clarify a bit: I don't say we shouldn't have an additional parameter.
I'm just saying that it may be more flexible to decouple the precision
parameter from the instance parameter.
Explicit values instead of conventions might also help the usability.
periph_timer IMO should be the slimmest layer of hardware abstraction
that makes sense, so users that don't want to do direct non-portable
register based applications get the next "closest to the metal".
Agree, but there are some things that we should add to the periph_timer.
E.g. adding support for dedicated overflow interrupts together with an
API to read
the corresponding IRQ status bit.
The high level timer would benefit from that on many platforms.
E.g. Ztimer wouldn't require the code for the time partitioning
mechanism then.
But thats yet another part of the story...
Yes. Also, do all platforms support that overflow interrupt?
I don't think so, in which case this cannot be relied upon to be available.
We are currently working on transforming "I don't think so" into numbers.
It will still take some time to work thru all of those, *cough* lovely
written data sheets.
I'll provide the collected information to the RDM.
Currently it looks like *most* platforms have this option.
It would absolutely make sense to use that feature if available and only
work around
if needed. Especially if this can be decided at compile time like with
the ztimer instances.
Also the term "frequency conversion" is a bit misleading I think.
With a discrete clock you won't be able to just precisely convert a
frequency to any other frequency in software.
Especially if you want to increase the frequency - it will just be a
calculation.
Yup. Frequency conversion makes sense if an application wants to sleep
12345ms, but the timer is clocked at e.g., 1024Hz.
Why?
This won't change the fact that the timer is clocked at 1024 Hz so there
is no frequency conversion.
It's a conversion from period to ticks.
You won't suddenly get accurate discrete ms ticks because of this
calculation.
Again, this is just a simple example to explain what I think we should
also consider as part of the solution.
Forcing the application / developer to select a specific instance also
has it's downsides.
With convention ("ZTIMER_MSEC provides ~1ms accuracy"), the application
developer chooses the intended precision. Without that, and with a fixed
API time base, 1s (1000000us) cannot be distinguished from 1000ms or
1000000us.
Maybe it can, this is where you can maybe come up with a prototype.
I'm not saying we should stay with a fixed time base API.
Regarding 1s cannot be distinguished from 1000000 µs:
That's not required if you specify the required accuracy as percentage.
Coincidentally, that's also how the accuracy of the clocks feeding the
timer peripherals are described.
->wouldn't it make sense to move this (probably repeated) code down,
from the app, to the high level timer
If the range needed exceeds e.g., 32bis of milliseconds, which can
represent more than 49 *days*, such code might make sense.
Yeah agree, the example with a µS timeout that may move to an ms range
is more likely to actually happen.
If no instance is available that can do that, the timer just "does its
best".
That is what a compile-time configured ZTIMER_USEC on 32kHz would do, if
that is desirable.
Understood, though this somehow becomes a problem with convention based
guarantees then.
But as this is done at compile time we could at least print a warning.
Not sure if there are use cases for also accessing this information at
run time (?).
You maybe already got that form the above statements, but that's not
what I meant.
I'm referring to "runtime requirements of one specific timeout" that may
differ based on the actual value.
Example: A protocol backoff that is 200ms probably requires some HF timer.
Then, because of whatever this may increase to 10 seconds and using an
LF timer becomes practical.
milliseconds can usually be set on low-power timers (e.g., a 32kHz RTT).
32bit range at 1kHz means 49 days. No need to switch to a different clock.
If your alarm can be set with that precision yes.
Also consider that using higher resolution for the sub-second counting
on RTC increases power consumption.
Other examples would be a 200 - 2000us timer. That cannot be set on a
millisecond clock, as now=500us + 2000us is 2500us, whereas now=0.5ms
(==0ms) + 2ms is somewhere between 2 and 3 ms. With an "at least"
semantic, the timer would choose 3ms as target time, which is up to 1ms
(1000us) off. This *could* be solved by synchronizing twice, e.g., set a
timer to the next ms tick, sleep 1ms, then sleep the remainder of the
timeout in us precision. Doable, but tricky. Especially while keeping
accuracy guarantees over two clock domains.
Yes that's tricky. Se should add some thoughts on this to the RDM.
If an application schedules <1000us...>2**32us, well yeah, it must be
using 64bit values already. In that case, we might need a 64bit API, or
*really* let the application handle that.
Agree.
Wouldn't it be nice if ztimer then automatically allows to go to power
down because it is practical?
(all that without adding the wrapping code to decide on the instance in
the application)
Sure. But honestly, that is *one* function, which would in any sane
architecture be completely on top of something like ztimer.
Not sure on this, after all it is a high level timer and deciding if
going to low-power can be very different on different hardware.
"let our high level timer do it's high level stuff to automatically map
it to what is at hand" is maybe possible.
Now we are talking!
Please prototoype!
I think that could, if successful, be the heart of a ztimer 64bit extension.
Good, I might play around with this after the more important stuff is
resolved.
If now the same thing happens with ztimer, we didn't learn from the
past.
If what happens? If in 5 years, we have learned where ztimer doesn't cut
it and come up with ztimer+ (for lack of letters) that improves the
situation substantially, again?
No, I mean if "having a non functional timer for many years" happens again.
I think the way how xtimer did is job over these years is not something
we want to repeat.
So an RDM would have prevented this? I doubt it. xtimer's ISR buggyness
was known *for years* even without an RDM. We were just inexperienced
(or ignorant, or incompetent, your pick).
Yes I honestly think it could have helped to on that end to thoroughly
discuss the key problems with a broader audience of interested and
competent people.
That' why I think it is worth doing a bit more of this thinking upfront.
At some point, we need to be pragmatic.
Yes, but at some point we should also take a step away and recap instead
of only implementing.
That is valid. Please acknowledge that while recapping, I can already
write applications that have both HF and LF timers, while the recappers
might be stuck, literally, because xtimer is broken.
Yes I totally acknowledge that and I'm really grateful that you spend
your time on that.
I also never meant to say the full replacement or the overall idea is
flawed.
I'm just saying it would be awesome to not repeat the process of
introducing a new implementation and then trying to fix it for years
till we start over from scratch again^^
On 12/12/19 5:46 PM, Marian Buschsieweke wrote:
# Not Getting Lost in Requirement Analysis and Problem Specifications
A good requirement analysis is a valuable tool for both development and
evaluation of a software component. But once a solid understanding of the
problem to solve is reached, additional effort put into a requirement analysis
doesn't yield enough additional benefit to justify the work. And every
requirement analysis is flawed: Assembling a complete list of all current
requirements in RIOT's code base is hard. Predicting how future developments
influence the requirements we have is impossible. There has to be a point when
we just stop on collecting more requirements and consider the current list as
good enough; a perfect, complete and definite result cannot be reached.
High level timer API are no new concept and the basic goals and requirements
are well understood. On top of these basic requirements, benchmarks could be a
good tool to quantify how well specific timer implementations perform. To me,
writing a set of benchmarks would be more useful than additional requirements
collection. Not only would it allow to see how good ztimer/xtimer are
performing. They will also be useful for development and reviews of future PRs
targeting RIOTs timer framework.
In the end, RIOT will be judged upon the features it provides. Not on the
features on RIOT's to do lists. Not on how tough and rigorous the requirements
are we have formulated on some yet-to-be-implemented feature. And not on how
much documents and emails have been written about an yet-to-be-implemented
feature.
(..) But once a solid understanding of the
problem to solve is reached, additional effort put into a requirement analysis
doesn't yield enough additional benefit to justify the work.
Yes, *once*...
High level timer API are no new concept and the basic goals and requirements
are well understood
Yeah, that' why now we have the 4th (?) high level timer implementation
and the previous three failed!?
This time everything is going to be different *fingers crossed*...
In the end, RIOT will be judged upon the features it provides. Not on the
features on RIOT's to do lists. Not on how tough and rigorous the requirements
are we have formulated on some yet-to-be-implemented feature. And not on how
much documents and emails have been written about an yet-to-be-implemented
feature.
I never said we should do this RDM discussion forever and add things
that are infeasible or we can't implement.
# Complete Rewrites can be the Best Option
I agree. As said above I never meant to question this because of
"ideological" reasons.
I don't think that there is a reason to see a complete rewrite as some kind
of failure that we should try very hard to prevent for the future.
I even agree here. Maybe I didn't express myself well.
I guess anyone who ever wrote code knows rewrites are sometimes the
absolutely best thing to do ;)
The failure is not a rewrite itself. More the process that we didn't
focus on fixing the problems.
We lived with a broken implementation for ages an now we mix required
fixes with introducing a new architecture.
But I bet that 90% of all use cases will (...)
It would be good If - for the RDM - we can work together on converting
such statements into at least some quantifiable data on how (we expect)
timers are commonly used.
Regarding adding an implementation independent API ontop of xtimer:
Spending work on just making xtimer as is functional feels like mostly
wasted, lets not make it worse^^
Wrapping a non functional timer in another layer of abstraction wont
really help us now.
Making it functional would be way more important.
Marian: would you also be interested in attending a timer meeting?
I probably won't really have time to work on any of those things till
the beginning of next year.
So how about scheduling a meeting in January? Feel free to contact me
off-list for that.
cheers
Michel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
