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 <kas...@schleiser.de> 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 > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel
pgpFVO5Crcxwe.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
