> > Time is linear - the API needs to support that. Application can check > if local time stays linear long enough for its use case. > > It doesn't sound like simplification. In current variant user don't > need to worry about this. > > > > If it does not, the global time should be the fall back (wrap only > after several years). > > > > Range is a relative term - ranges longer than the wrap around time > (in real time) would again cause problems. > > I thinks no need to compare ranges more then years. It's not for this > use-case.
For example, a bit 32 bit counter at 1 GHz (e.g. CPU local counter, used for CPU local time) wraps in 4 sec > > > > > One option would be to force all time sources to have very long wrap > around times, which may cause low resolution on all of them (not only > global). Maybe it's better to just specify that cmp() must not be used > if (nsec) time can wrap between t1 and t2. > > This also doesn't sounds as simplification. How user can know he is > comparing wrapped time or not? > He cannot - that's the problem. No one cannot. You cannot predict what > points user compare. > You cannot emulate it in implementation also (suppose worst case - > implementation cannot grantee counter is united to 0 at board start), > as first wrap can happen any time, it's second takes years. Relying on > this makes all applications very configuration dependent. > That is the one of the main and bright examples that allow to see why > we don't need to hide wraps. > So this function cannot be used with timestamps at all, only ranges. To > get range, you must use diff function, > diff function can handle wraps inside. That is. If you must use diff > and cmp then why bother with wall time? > > Why user still should think about wraps, if you want to equalize it to > wall time? > Or even, use this function (it was one of your ideas), to check time > order with function that requires order...... > What about to not bother with chicken/egg issue and always assume that > wrap can happen or cannot at all. > Only describe in API file, it must be > 10 years, for instance, before > first wrap. > And if your application can run more than 10 years it can suddenly > fail. > Uh..or add in description. ..never change your dtb file to another init > value or freq > if you don't know what are you doing...in another way you application > can suddenly fail... > It be threshold for orientation and both implementation and application > can lie on it. And hardly control. Implementation can handle single counter wrap and maintain nsec time which starts from 0, by reading and storing the counter value in ODP init. Application needs only worry about nsec time wrap (is xxx_nsec_max large enough for its purposes / lifetime). For example, an application: - needs high resolution - low CPU overhead - don't need to share the time - needs to compare timestamps (e.g. sort a list based on timestamps) SoC 1: - local time counter is 32 bits and runs at core freq (local_hz == 1GHz, local_nsec_max == ~4sec) => nsec time wraps every 4 sec => nsec time wrap is possible between any t1 and t2 => cannot use cmp() for absolute time stamps => must use global time if need to compare ... - global time counter runs at 25 MHz and wraps in 40 years (global_hz == 25 MHz, global_nsec_max == ~40 years) => nsec time (that starts from zero by the spec) will not wrap in the life time of this application => can use cmp(), but must accept the low resolution. Done. SoC 2: - local time counter is 64 bits and runs at core freq (local_hz == 1GHz, local_nsec_max == ~580 years) => nsec time (that start from zero by the spec) will not wrap in the life time of this application => nsec time wrap is not possible => can use cmp(). Done. -Petri _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
