validation: time: increase TOLERANCE range

Message ID 1438096987-17783-1-git-send-email-ivan.khoronzhuk@linaro.org
State New
Headers show

Commit Message

Ivan Khoronzhuk July 28, 2015, 3:23 p.m.
Current test supposes that timer counter resolution is very close
to 1ns. But that's not always true. The resoulution can be 8ns for
instance, it's not always close to CPU frequency.

Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
 test/validation/time/time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Maxim Uvarov July 29, 2015, 11:34 a.m. | #1
Should we have
#define CONFIG_TIMER_RESOLUTION
in config.h?

And relay on it's value.

Maxim.

On 07/28/15 18:23, Ivan Khoronzhuk wrote:
> Current test supposes that timer counter resolution is very close
> to 1ns. But that's not always true. The resoulution can be 8ns for
> instance, it's not always close to CPU frequency.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
>   test/validation/time/time.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test/validation/time/time.c b/test/validation/time/time.c
> index 0aac599..d23bc2e 100644
> --- a/test/validation/time/time.c
> +++ b/test/validation/time/time.c
> @@ -8,7 +8,7 @@
>   #include "odp_cunit_common.h"
>   #include "time.h"
>   
> -#define TOLERANCE 1
> +#define TOLERANCE 10
>   #define BUSY_LOOP_CNT 100
>   
>   /* check that a cycles difference gives a reasonable result */
Ivan Khoronzhuk July 29, 2015, 11:42 a.m. | #2
On 29.07.15 14:34, Maxim Uvarov wrote:
> Should we have
> #define CONFIG_TIMER_RESOLUTION
> in config.h?
>
> And relay on it's value.
>
> Maxim.

Maybe.
In case of CPU freq this is inversely proportional to odp_sys_cpu_hz(),
and can be determined. But in case of using "real" timer there is no
API to get it's freq, so it make sense.

>
> On 07/28/15 18:23, Ivan Khoronzhuk wrote:
>> Current test supposes that timer counter resolution is very close
>> to 1ns. But that's not always true. The resoulution can be 8ns for
>> instance, it's not always close to CPU frequency.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>>   test/validation/time/time.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/test/validation/time/time.c b/test/validation/time/time.c
>> index 0aac599..d23bc2e 100644
>> --- a/test/validation/time/time.c
>> +++ b/test/validation/time/time.c
>> @@ -8,7 +8,7 @@
>>   #include "odp_cunit_common.h"
>>   #include "time.h"
>> -#define TOLERANCE 1
>> +#define TOLERANCE 10
>>   #define BUSY_LOOP_CNT 100
>>   /* check that a cycles difference gives a reasonable result */
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
Ivan Khoronzhuk July 29, 2015, 11:46 a.m. | #3
On 29.07.15 14:42, Ivan Khoronzhuk wrote:
>
>
> On 29.07.15 14:34, Maxim Uvarov wrote:
>> Should we have
>> #define CONFIG_TIMER_RESOLUTION
>> in config.h?
>>
>> And relay on it's value.
>>
>> Maxim.
>
> Maybe.
> In case of CPU freq this is inversely proportional to odp_sys_cpu_hz(),
> and can be determined. But in case of using "real" timer there is no
> API to get it's freq, so it make sense.
>

But it be better a function then macro, I have for instance the same
boards but with different frequency sourcing arch timer, and this
freq is read from CP15 preprocessor in runtime.

>>
>> On 07/28/15 18:23, Ivan Khoronzhuk wrote:
>>> Current test supposes that timer counter resolution is very close
>>> to 1ns. But that's not always true. The resoulution can be 8ns for
>>> instance, it's not always close to CPU frequency.
>>>
>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>> ---
>>>   test/validation/time/time.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/test/validation/time/time.c b/test/validation/time/time.c
>>> index 0aac599..d23bc2e 100644
>>> --- a/test/validation/time/time.c
>>> +++ b/test/validation/time/time.c
>>> @@ -8,7 +8,7 @@
>>>   #include "odp_cunit_common.h"
>>>   #include "time.h"
>>> -#define TOLERANCE 1
>>> +#define TOLERANCE 10
>>>   #define BUSY_LOOP_CNT 100
>>>   /* check that a cycles difference gives a reasonable result */
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>
Bill Fischofer July 29, 2015, 11:47 a.m. | #4
Agreed.  An ODP implementation should be for a platform, not for a specific
model within a platform family.  Another reason why config.h needs to be
converted from #defines to APIs.

On Wed, Jul 29, 2015 at 6:46 AM, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org
> wrote:

>
>
> On 29.07.15 14:42, Ivan Khoronzhuk wrote:
>
>>
>>
>> On 29.07.15 14:34, Maxim Uvarov wrote:
>>
>>> Should we have
>>> #define CONFIG_TIMER_RESOLUTION
>>> in config.h?
>>>
>>> And relay on it's value.
>>>
>>> Maxim.
>>>
>>
>> Maybe.
>> In case of CPU freq this is inversely proportional to odp_sys_cpu_hz(),
>> and can be determined. But in case of using "real" timer there is no
>> API to get it's freq, so it make sense.
>>
>>
> But it be better a function then macro, I have for instance the same
> boards but with different frequency sourcing arch timer, and this
> freq is read from CP15 preprocessor in runtime.
>
>
>
>>> On 07/28/15 18:23, Ivan Khoronzhuk wrote:
>>>
>>>> Current test supposes that timer counter resolution is very close
>>>> to 1ns. But that's not always true. The resoulution can be 8ns for
>>>> instance, it's not always close to CPU frequency.
>>>>
>>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>>> ---
>>>>   test/validation/time/time.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/test/validation/time/time.c b/test/validation/time/time.c
>>>> index 0aac599..d23bc2e 100644
>>>> --- a/test/validation/time/time.c
>>>> +++ b/test/validation/time/time.c
>>>> @@ -8,7 +8,7 @@
>>>>   #include "odp_cunit_common.h"
>>>>   #include "time.h"
>>>> -#define TOLERANCE 1
>>>> +#define TOLERANCE 10
>>>>   #define BUSY_LOOP_CNT 100
>>>>   /* check that a cycles difference gives a reasonable result */
>>>>
>>>
>>> _______________________________________________
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>
>>
> --
> Regards,
> Ivan Khoronzhuk
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
Ivan Khoronzhuk July 29, 2015, 12:17 p.m. | #5
On 29.07.15 14:47, Bill Fischofer wrote:
> Agreed.  An ODP implementation should be for a platform, not for a
> specific model within a platform family.  Another reason why config.h
> needs to be converted from #defines to APIs.

There is  a little more sense under it. Each CPU, theoretically, (no
see sense in it, but anyway) can have different arch timer combined
with it, this timer can be switched off with CPU or can be accessible
only for CPU that combined with it.
It can have different resolution..........
Mike Holmes July 29, 2015, 12:26 p.m. | #6
On 29 July 2015 at 08:17, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
wrote:

>
> On 29.07.15 14:47, Bill Fischofer wrote:
>
>> Agreed.  An ODP implementation should be for a platform, not for a
>> specific model within a platform family.  Another reason why config.h
>> needs to be converted from #defines to APIs.
>>
>
> There is  a little more sense under it. Each CPU, theoretically, (no
> see sense in it, but anyway) can have different arch timer combined
> with it, this timer can be switched off with CPU or can be accessible
> only for CPU that combined with it.
> It can have different resolution..........



>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
Mike Holmes July 29, 2015, 12:27 p.m. | #7
On 29 July 2015 at 08:17, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
wrote:

>
> On 29.07.15 14:47, Bill Fischofer wrote:
>
>> Agreed.  An ODP implementation should be for a platform, not for a
>> specific model within a platform family.  Another reason why config.h
>> needs to be converted from #defines to APIs.
>>
>
> There is  a little more sense under it. Each CPU, theoretically, (no
> see sense in it, but anyway) can have different arch timer combined
> with it, this timer can be switched off with CPU or can be accessible
> only for CPU that combined with it.
> It can have different resolution..........


Hongbo has been trying to solve this,
https://lists.linaro.org/pipermail/lng-odp/2015-July/013141.html


>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
Ivan Khoronzhuk July 29, 2015, 12:39 p.m. | #8
Mike,

On 29.07.15 15:27, Mike Holmes wrote:
>
>
> On 29 July 2015 at 08:17, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org
> <mailto:ivan.khoronzhuk@linaro.org>> wrote:
>
>
>     On 29.07.15 14:47, Bill Fischofer wrote:
>
>         Agreed.  An ODP implementation should be for a platform, not for a
>         specific model within a platform family.  Another reason why
>         config.h
>         needs to be converted from #defines to APIs.
>
>
>     There is  a little more sense under it. Each CPU, theoretically, (no
>     see sense in it, but anyway) can have different arch timer combined
>     with it, this timer can be switched off with CPU or can be accessible
>     only for CPU that combined with it.
>     It can have different resolution..........
>
>
> Hongbo has been trying to solve this,
> https://lists.linaro.org/pipermail/lng-odp/2015-July/013141.html
>
>

I'm not talking about cpufreq, when frequency of each CPU is changing in
runtime, the CPU counter is not always accessible for reading, and this
frequency not alway accurate and stable enough for time measurements.
That's why often another counter is used for such purposes that is
sourced by another freq. It theoretically can be different for diff
CPUs, but it's constant in time and is not changed when CPUfreq
framework can change CPU frequency. It doesn't source the CPU, and is
not changed in time.

>
>     _______________________________________________
>     lng-odp mailing list
>     lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
>     https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM SoCs
>
> __
>
>
Mike Holmes Aug. 4, 2015, 12:19 p.m. | #9
In the platform call just now the discussion came to this patch.

Ivan can you propose an API to get the timer resolution for the platform,
then the test suite can call that and run the test appropriately.

On 29 July 2015 at 08:39, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
wrote:

> Mike,
>
> On 29.07.15 15:27, Mike Holmes wrote:
>
>>
>>
>> On 29 July 2015 at 08:17, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org
>> <mailto:ivan.khoronzhuk@linaro.org>> wrote:
>>
>>
>>     On 29.07.15 14:47, Bill Fischofer wrote:
>>
>>         Agreed.  An ODP implementation should be for a platform, not for a
>>         specific model within a platform family.  Another reason why
>>         config.h
>>         needs to be converted from #defines to APIs.
>>
>>
>>     There is  a little more sense under it. Each CPU, theoretically, (no
>>     see sense in it, but anyway) can have different arch timer combined
>>     with it, this timer can be switched off with CPU or can be accessible
>>     only for CPU that combined with it.
>>     It can have different resolution..........
>>
>>
>> Hongbo has been trying to solve this,
>> https://lists.linaro.org/pipermail/lng-odp/2015-July/013141.html
>>
>>
>>
> I'm not talking about cpufreq, when frequency of each CPU is changing in
> runtime, the CPU counter is not always accessible for reading, and this
> frequency not alway accurate and stable enough for time measurements.
> That's why often another counter is used for such purposes that is
> sourced by another freq. It theoretically can be different for diff
> CPUs, but it's constant in time and is not changed when CPUfreq
> framework can change CPU frequency. It doesn't source the CPU, and is
> not changed in time.
>
>
>>     _______________________________________________
>>     lng-odp mailing list
>>     lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
>>     https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>>
>> --
>> Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM
>> SoCs
>>
>> __
>>
>>
>>
> --
> Regards,
> Ivan Khoronzhuk
>
Ivan Khoronzhuk Aug. 4, 2015, 12:35 p.m. | #10
shure

On 04.08.15 15:19, Mike Holmes wrote:
> In the platform call just now the discussion came to this patch.
>
> Ivan can you propose an API to get the timer resolution for the
> platform, then the test suite can call that and run the test appropriately.
>
> On 29 July 2015 at 08:39, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org
> <mailto:ivan.khoronzhuk@linaro.org>> wrote:
>
>     Mike,
>
>     On 29.07.15 15:27, Mike Holmes wrote:
>
>
>
>         On 29 July 2015 at 08:17, Ivan Khoronzhuk
>         <ivan.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@linaro.org>
>         <mailto:ivan.khoronzhuk@linaro.org
>         <mailto:ivan.khoronzhuk@linaro.org>>> wrote:
>
>
>              On 29.07.15 14:47, Bill Fischofer wrote:
>
>                  Agreed.  An ODP implementation should be for a
>         platform, not for a
>                  specific model within a platform family.  Another
>         reason why
>                  config.h
>                  needs to be converted from #defines to APIs.
>
>
>              There is  a little more sense under it. Each CPU,
>         theoretically, (no
>              see sense in it, but anyway) can have different arch timer
>         combined
>              with it, this timer can be switched off with CPU or can be
>         accessible
>              only for CPU that combined with it.
>              It can have different resolution..........
>
>
>         Hongbo has been trying to solve this,
>         https://lists.linaro.org/pipermail/lng-odp/2015-July/013141.html
>
>
>
>     I'm not talking about cpufreq, when frequency of each CPU is changing in
>     runtime, the CPU counter is not always accessible for reading, and this
>     frequency not alway accurate and stable enough for time measurements.
>     That's why often another counter is used for such purposes that is
>     sourced by another freq. It theoretically can be different for diff
>     CPUs, but it's constant in time and is not changed when CPUfreq
>     framework can change CPU frequency. It doesn't source the CPU, and is
>     not changed in time.
>
>
>              _______________________________________________
>              lng-odp mailing list
>         lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
>         <mailto:lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>>
>         https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
>         --
>         Mike Holmes
>         Technical Manager - Linaro Networking Group
>         Linaro.org <http://www.linaro.org/>***│ *Open source software
>         for ARM SoCs
>
>         __
>
>
>
>     --
>     Regards,
>     Ivan Khoronzhuk
>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM SoCs
>
> __
>
>
Ivan Khoronzhuk Aug. 5, 2015, 12:01 p.m. | #11
On 04.08.15 15:19, Mike Holmes wrote:
> In the platform call just now the discussion came to this patch.
>
> Ivan can you propose an API to get the timer resolution for the
> platform, then the test suite can call that and run the test appropriately.


I remember someone proposed to rename cycles to some "counts" in the
API, and unbind it from CPU cycles. Like:

odp_time_cycles -> odp_time_counts();
odp_time_diff_cycles -> odp_time_diff_counts();
odp_time_cycles_to_ns -> odp_time_counts_to_ns();
odp_time_ns_to_cycles -> odp_time_ns_to_counts();

And change description accordingly, removing CPU words from it.
It will allow to use real counts, not virtual.
In this case we don't need "resolution" function, as resolution
can be simply got by:

odp_time_counts_to_ns(1);

What was the final decision? Maybe it's time to change it?
Why this emulation is still needed?, maybe we not always can
access real timer directly and get it's resolution? Then
what resolution API function should return in this case?,
return virtual resolution?

Just this API is based on CPU freq that is not always corresponds
the real timer counter with max resolution. And to imitate the
"CPU counter" API needs redundant conversion to get real ns.

>
> On 29 July 2015 at 08:39, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org
> <mailto:ivan.khoronzhuk@linaro.org>> wrote:
>
>     Mike,
>
>     On 29.07.15 15:27, Mike Holmes wrote:
>
>
>
>         On 29 July 2015 at 08:17, Ivan Khoronzhuk
>         <ivan.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@linaro.org>
>         <mailto:ivan.khoronzhuk@linaro.org
>         <mailto:ivan.khoronzhuk@linaro.org>>> wrote:
>
>
>              On 29.07.15 14:47, Bill Fischofer wrote:
>
>                  Agreed.  An ODP implementation should be for a
>         platform, not for a
>                  specific model within a platform family.  Another
>         reason why
>                  config.h
>                  needs to be converted from #defines to APIs.
>
>
>              There is  a little more sense under it. Each CPU,
>         theoretically, (no
>              see sense in it, but anyway) can have different arch timer
>         combined
>              with it, this timer can be switched off with CPU or can be
>         accessible
>              only for CPU that combined with it.
>              It can have different resolution..........
>
>
>         Hongbo has been trying to solve this,
>         https://lists.linaro.org/pipermail/lng-odp/2015-July/013141.html
>
>
>
>     I'm not talking about cpufreq, when frequency of each CPU is changing in
>     runtime, the CPU counter is not always accessible for reading, and this
>     frequency not alway accurate and stable enough for time measurements.
>     That's why often another counter is used for such purposes that is
>     sourced by another freq. It theoretically can be different for diff
>     CPUs, but it's constant in time and is not changed when CPUfreq
>     framework can change CPU frequency. It doesn't source the CPU, and is
>     not changed in time.
>
>
>              _______________________________________________
>              lng-odp mailing list
>         lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
>         <mailto:lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>>
>         https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
>         --
>         Mike Holmes
>         Technical Manager - Linaro Networking Group
>         Linaro.org <http://www.linaro.org/>***│ *Open source software
>         for ARM SoCs
>
>         __
>
>
>
>     --
>     Regards,
>     Ivan Khoronzhuk
>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM SoCs
>
> __
>
>
Ivan Khoronzhuk Aug. 5, 2015, 1 p.m. | #12
The API names even can be leaved as is.
Only description change (remove CPU cycles)

On 05.08.15 15:01, Ivan Khoronzhuk wrote:
> On 04.08.15 15:19, Mike Holmes wrote:
>> In the platform call just now the discussion came to this patch.
>>
>> Ivan can you propose an API to get the timer resolution for the
>> platform, then the test suite can call that and run the test
>> appropriately.
>
>
> I remember someone proposed to rename cycles to some "counts" in the
> API, and unbind it from CPU cycles. Like:
>
> odp_time_cycles -> odp_time_counts();
> odp_time_diff_cycles -> odp_time_diff_counts();
> odp_time_cycles_to_ns -> odp_time_counts_to_ns();
> odp_time_ns_to_cycles -> odp_time_ns_to_counts();
>
> And change description accordingly, removing CPU words from it.
> It will allow to use real counts, not virtual.
> In this case we don't need "resolution" function, as resolution
> can be simply got by:
>
> odp_time_counts_to_ns(1);
>
> What was the final decision? Maybe it's time to change it?
> Why this emulation is still needed?, maybe we not always can
> access real timer directly and get it's resolution? Then
> what resolution API function should return in this case?,
> return virtual resolution?
>
> Just this API is based on CPU freq that is not always corresponds
> the real timer counter with max resolution. And to imitate the
> "CPU counter" API needs redundant conversion to get real ns.
>
>>
>> On 29 July 2015 at 08:39, Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org
>> <mailto:ivan.khoronzhuk@linaro.org>> wrote:
>>
>>     Mike,
>>
>>     On 29.07.15 15:27, Mike Holmes wrote:
>>
>>
>>
>>         On 29 July 2015 at 08:17, Ivan Khoronzhuk
>>         <ivan.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@linaro.org>
>>         <mailto:ivan.khoronzhuk@linaro.org
>>         <mailto:ivan.khoronzhuk@linaro.org>>> wrote:
>>
>>
>>              On 29.07.15 14:47, Bill Fischofer wrote:
>>
>>                  Agreed.  An ODP implementation should be for a
>>         platform, not for a
>>                  specific model within a platform family.  Another
>>         reason why
>>                  config.h
>>                  needs to be converted from #defines to APIs.
>>
>>
>>              There is  a little more sense under it. Each CPU,
>>         theoretically, (no
>>              see sense in it, but anyway) can have different arch timer
>>         combined
>>              with it, this timer can be switched off with CPU or can be
>>         accessible
>>              only for CPU that combined with it.
>>              It can have different resolution..........
>>
>>
>>         Hongbo has been trying to solve this,
>>         https://lists.linaro.org/pipermail/lng-odp/2015-July/013141.html
>>
>>
>>
>>     I'm not talking about cpufreq, when frequency of each CPU is
>> changing in
>>     runtime, the CPU counter is not always accessible for reading, and
>> this
>>     frequency not alway accurate and stable enough for time measurements.
>>     That's why often another counter is used for such purposes that is
>>     sourced by another freq. It theoretically can be different for diff
>>     CPUs, but it's constant in time and is not changed when CPUfreq
>>     framework can change CPU frequency. It doesn't source the CPU, and is
>>     not changed in time.
>>
>>
>>              _______________________________________________
>>              lng-odp mailing list
>>         lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
>>         <mailto:lng-odp@lists.linaro.org
>> <mailto:lng-odp@lists.linaro.org>>
>>         https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>>
>>         --
>>         Mike Holmes
>>         Technical Manager - Linaro Networking Group
>>         Linaro.org <http://www.linaro.org/>***│ *Open source software
>>         for ARM SoCs
>>
>>         __
>>
>>
>>
>>     --
>>     Regards,
>>     Ivan Khoronzhuk
>>
>>
>>
>>
>> --
>> Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM
>> SoCs
>>
>> __
>>
>>
>

Patch

diff --git a/test/validation/time/time.c b/test/validation/time/time.c
index 0aac599..d23bc2e 100644
--- a/test/validation/time/time.c
+++ b/test/validation/time/time.c
@@ -8,7 +8,7 @@ 
 #include "odp_cunit_common.h"
 #include "time.h"
 
-#define TOLERANCE 1
+#define TOLERANCE 10
 #define BUSY_LOOP_CNT 100
 
 /* check that a cycles difference gives a reasonable result */