| Message ID | 1438096987-17783-1-git-send-email-ivan.khoronzhuk@linaro.org |
|---|---|
| State | New |
| Headers | show |
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 */
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
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 >
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 >
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..........
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 >
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 >
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 > > __ > >
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 >
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 > > __ > >
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 > > __ > >
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 >> >> __ >> >> >
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 */
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(-)