Hi Ralf, On 12/13/19 6:41 PM, Ralf Schlatterbeck wrote: > As far as I understand, the new timer implementation would not use 64 > bit for the timer and the user is responsible for not overrunning the > timer? Note that I haven't looked a the implementation yet, so forgive > my ignorance.
I think you got it right. In ztimer, the clocks' now() value will overflow after 32bits. E.g., `t1 = now(); t2 = now(); assert(t1 < t2)` might fail. Setting timer values is always relative (target = now() + X), and X can be any 32bit value, the user does not need to handle any overflow there. > Over the years my experience is that it's no good idea to burden the > user with the knowledge of timer overflow. The latest example was a > bunch of HPE SSDs that stop working after 32.768 hours (a little less > than 4 years). Bad when you have several of them in a RAID for > redundancy :-) Failing after 32768h strongly points to using a signed 16bit variable for the hours count. That's an odd choice to begin with. > https://www.techradar.com/news/hpe-ssd-drives-could-fail-at-this-critical-moment > So I'd vote for the (small) additional overhead, even on 8-bit µCs due > to safety reasons. Unless the implementation can produce the correct > timer representation with, say, C-preprocessor magic at compile-time. You mean, you'd vote for all timer values to be always 64bit? I don't think the overhead is small enough to justify that, but that needs to be evaluated. The increased CPU usage needs benchmarks, in RAM we can estimate easily. IMO, users should just not use these timer values as timestamps. That maybe needs to be stated at a prominent place (or multiple) in the documentation. For that, we can (should?) re-introduce a 64bit API in ztimer. It might make sense to add a (very large or possibly randomized) constant offset to all 32bit timers, maybe limited to development builds, that causes the timer value to overflow early(er), so applications would break early in tests. Kaspar _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
