Hi, Petri
On 04.09.15 13:55, Savolainen, Petri (Nokia - FI/Espoo) wrote:
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
Seems we decided to not think about 32-bit timer here. Right?
It's impossible to work with times more than time wrap, not only for ranges.
Any of time API functions is not working correctly in this case, not only cmpr.
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?
Don't remove the main problem from this thread.
We need to put dot here. So please, answer. Don't forget to mention about
cmp() and that first wrap can happen any 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,
Yes, implementation can, but only for ns. Then you can compare, diff and sum
only in ns.
Correct first wrap (and only 1, and we don't need more) can be guaranteed only
in diff function,
not in odp_time() and odp_time_cmp(). You cannot compare in odp_time_t as wall
time, only ns.
But you probably want not only ns.
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).
Sorry, if implementation can maintain nsec time which starts from 0,
why does application need to worry about nsec wrap? I mean only 64-bit counter
and above.
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)
32-bit, again, but lets assume.
=> nsec time wraps every 4 sec
=> nsec time wrap is possible between any t1 and t2
=> cannot use cmp() for absolute time stamps
and not only for 32-bit, also 64-bit that doesn't guarantee zero at some init.
=> 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)
I tend to not limit freq on currently possible frequencies. Don't forget that
you can have counter inited to any value.
The first wrap can happen any time. We should count on such cases also.
Also it can be configurable, and it's not safe from stupid conf.
Also it can be h/w init at 0, but on some emulator, not.....then - glitches.
Run before some h/w timer test, that can leave it in non zero state - then
possible glitches.
But in this case lets assume.
Also spec can guarantee, but real life can add surprises, like in most cases
it's by default 0, but at some
circumstances can happen that not, you will be catching very rarely glitches
and don't know what's happening.
=> nsec time (that start from zero by the spec) will not wrap in the life
time of this application
yes. we can do this. but only for ns. in some .... odp_time_wall() in ns...
When you converting odp_time_to_ns() in most cases you need to know some time
distance in ns.
If we convert odp_time_from_ns(), probably we are going to use it to get some
range.
Like odp_time_from_ns(9), and use it in some wait loop.
And here shouldn't be any start time or else.
What about to add separate functions to support wall time?
Like:
odp_time_wall(); // here we always returns diff (that take into account
wrap).
// Can be compared, diff/sum directly w/o functions.
odp_time_wall_ns(); // Also, obvious, can be compared, diff/sum directly w/o
functions.
Only these functions are global. And can be used to trace some packet times on
threads.
Mostly diff and sum for them are not needed, but they are simple C operations.
Also odp_time_wall_rate() can be added to evaluate rate and thus resolution.
=> nsec time wrap is not possible
=> can use cmp(). Done.
Only for case, counter = 0 at init, another case - glitches.
And how are you going to explain this to an application? Use in one case,
changed hardware - don't use.
Check timer inited correctly? Check it's 32 bit or 64 in application? Check
time wrap period? It's not
very friendly on my opinion. Always use only for ranges is more correct variant.
-Petri
--
Regards,
Ivan Khoronzhuk
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
