Hi,
I think we need to restart the time API discussion and specify it only wall
time in mind. CPU cycle count APIs can be tuned as a next step. CPU cycle
counters are affected by frequency scaling, which makes those difficult to use
for counting linear, real time. The time API should specify a
Hi, Petri
We have to look at it proceeding from performance, platform portability and
simplicity
If you want to split on hi-res time and low-res they must have separate
functions and
be not under one common opaque time in order to not break hi-res measurements.
But in fact you split the same
One correction, that also makes me worry a little.
On 03.09.15 01:29, Ivan Khoronzhuk wrote:
Hi, Petri
We have to look at it proceeding from performance, platform portability and
simplicity
If you want to split on hi-res time and low-res they must have separate
functions and
be not under one
> -Original Message-
> From: ext Ivan Khoronzhuk [mailto:ivan.khoronz...@linaro.org]
> Sent: Thursday, September 03, 2015 1:29 AM
> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] RFC: New time API
>
> Hi, Petri
>
On 03.09.15 14:32, Savolainen, Petri (Nokia - FI/Espoo) wrote:
-Original Message-
From: ext Ivan Khoronzhuk [mailto:ivan.khoronz...@linaro.org]
Sent: Thursday, September 03, 2015 1:29 AM
To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
Subject: Re: [lng-odp] RFC
> > 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 ba
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 thi
