On 04/25 22:47:11, Maxim Uvarov wrote: > On 04/25/17 21:51, Brian Brooks wrote: > > On 04/25 12:25:03, Brian Brooks wrote: > >> On 04/24 08:07:58, Savolainen, Petri (Nokia - FI/Espoo) wrote: > >>>>> diff --git a/platform/linux-generic/arch/x86/odp_cpu_arch.c > >>>> b/platform/linux-generic/arch/x86/odp_cpu_arch.c > >>>>> index c8cf27b6..9ba601a3 100644 > >>>>> --- a/platform/linux-generic/arch/x86/odp_cpu_arch.c > >>>>> +++ b/platform/linux-generic/arch/x86/odp_cpu_arch.c > >>>>> @@ -3,7 +3,14 @@ > >>>>> * > >>>>> * SPDX-License-Identifier: BSD-3-Clause > >>>>> */ > >>>>> + > >>>>> +#include <odp_posix_extensions.h> > >>>>> + > >>>>> #include <odp/api/cpu.h> > >>>>> +#include <odp_time_internal.h> > >>>>> +#include <odp_debug_internal.h> > >>>>> + > >>>>> +#include <time.h> > >>>>> > >>>>> uint64_t odp_cpu_cycles(void) > >>>>> { > >>>>> @@ -31,3 +38,55 @@ uint64_t odp_cpu_cycles_resolution(void) > >>>>> { > >>>>> return 1; > >>>>> } > >>>>> + > >>>>> +uint64_t cpu_global_time(void) > >>>>> +{ > >>>>> + return odp_cpu_cycles(); > >>>> > >>>> A cycle counter cannot always be used to measure time. Even on x86, > >>>> odp_cpu_cycles() will return the value of RDTSC which is not actually > >>>> representative of the cycle count. Even if the x86 processor is set > >>>> to a fixed frequency, the Invariant TSC may run at a different fixed > >>>> frequency. Please take a look at the odp_tick_t proposal here: > >>>> > >>>> https://docs.google.com/document/d/1sY7rOxqCNu-bMqjBiT5_keAIohrX1ZW- > >>>> eL0oGLAQ4OM/edit?usp=sharing > >>>> > >>> > >>> From coverletter: > >>> "This patch set modifies time implementation to use TSC when running on a > >>> x86 > >>> CPU that has invarint TSC CPU flag set. Otherwise, the same Linux system > >>> time > >>> is used as before. TSC is much more efficient both in performance and > >>> latency/jitter wise than Linux system call. This can be seen also with > >>> scheduler latency test which time stamps events with this API. All > >>> latency > >>> measurements (min, ave, max) improved significantly." > >>> > >>> This function (cpu_global_time()) is called only when we have first > >>> checked that TSC is invariant. Also we measure the TSC frequency in that > >>> case. This function is defined in the same file as cpu_cycles(), and the > >>> file is x86 specific. So, we know what we are doing, and just re-using > >>> the code to read TSC. > > > > What sort of timing accuracy is expected from the app? > > > > From benchmarking the maximum single-threaded rate of these reads: > > > > x86_64: > > > > read 7 ns/op > > read_sync 22 ns/op > > > > A57: > > > > read 4 ns/op > > read_sync 26 ns/op > > > > read_sync issues a synchronizing instruction for greater timing accuracy > > but clearly takes more time to return the time value read from the core. > > > > > it has to be depend on cpu frequency. > > Maxim.
We are showing the difference between 'read' and 'read_sync' on the same machine here.