time resolution 10ms only?

[Karri Kaksonen]

A command

#include <time.h>
printf("%f\n", (float)clock()/CLOCKS_PER_SEC);

produces values like
0.000000
0.120000
0.130000
0.140000
0.150000
0.160000
0.160000
0.170000
0.180000
0.190000
0.200000

The internal ticks seem to be at 10ms increments. Is the usec clock available by some other function?

BR,
Karri

[pavel-demin]

There is a discussion of a very similar problem at

http://forums.xilinx.com/t5/Embedded-Li ... d-p/399017

According to this forum thread, 3ns time resolution can be achieved with the following modifications:

- CONFIG_ARM_GLOBAL_TIMER=y should be added to the kernel configuration
- ps7_globaltimer_0 should be activated in the device tree

I'll try this solution later today and post the results.

[pavel-demin]

Looks like the ARM_GLOBAL_TIMER option is disabled in the latest Linux kernels because of the following patch:

https://patches.linaro.org/26058/

When booting with the default kernel configuration, I get the following message:

Code: Select all

Zynq clock init
sched_clock: 16 bits at 54kHz, resolution 18432ns, wraps every 1207951633ns

When running a simple test program:

Code: Select all

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <time.h>

int main()
{
  unsigned long long time1, time2, time3;

  struct timespec t1, t2, t3;

  clock_gettime(0, &t1);
  usleep(370);
  clock_gettime(0, &t2);
  usleep(740);
  clock_gettime(0, &t3);

  time1 = (t1.tv_sec * 1000000000) + t1.tv_nsec;
  time2 = (t2.tv_sec * 1000000000) + t2.tv_nsec;
  time3 = (t3.tv_sec * 1000000000) + t3.tv_nsec;

  printf("usleep(370) = %lldns\n", (time2 - time1));
  printf("usleep(740) = %lldns\n", (time3 - time2));
  printf("usleep(370) + usleep(740) = %lldns\n", (time3 - time1));
}

I obtain the following results:

usleep(370) = 497676ns
usleep(740) = 811028ns
usleep(370) + usleep(740) = 1308704ns

So, with the clock_gettime function, it's possible to obtain time resolution better than 10ms. With the default kernel configuration, the time resolution is not better than 18us.

[Karri Kaksonen]

Thank you.

We need the time to compensate for uneven movement of the sensors due to waves and wind. The 18us is much better than 10ms so we will switch to use this code. 18 us is certainly good enough for us.

--
Karri

[Karri Kaksonen]

The clock_gettime is a bit unpredictable. A few examples of our runs:

run1:
Start of Radar acquisition
0.386415
0.387908
0.388977
0.389936

run2:
Start of Radar acquisition
1.271066
1.272043
1.273076
1.274126

run3:
Start of Radar acquisition
^C
(The system hangs)

run4:
Start of Radar acquisition
^C
(The system hangs)

run5:
Start of Radar acquisition
0.450878
0.451874
0.452943
0.454012

The code looks like this:

static double getTimeNow()
{
#if 1
unsigned long long time1;
struct timespec t1;
clock_gettime(0, &t1);
time1 = (t1.tv_sec * 1000000000) + t1.tv_nsec;
return (double)time1 / 1000000000.0;
#else
return (double)clock()/CLOCKS_PER_SEC;
#endif
}

When using clock() it never hangs. But with clock_gettime() the system occasionally refuses to start up.

When using the clock() our data aquisitions look like this:
Start of Radar acquisition
0.130000
0.130000
0.130000
0.130000
0.130000
0.130000
0.130000
0.130000
0.130000
0.140000
0.140000
0.140000
0.140000
0.140000
0.140000
0.140000
0.140000
0.140000
0.140000
0.150000

So your method is much better.