Raspberry Pi: different methods of getting time

Test conditions and platform

The gettime functions - default approach

Intro to API

#include <sys/time.h>
int gettimeofday(struct timeval *tv, struct timezone *tz);

#include <time.h>
int clock_gettime(clockid_t clk_id, struct timespec *tp);

Timing

Test of 1000000 calls to clock_gettime(CLOCK_REALTIME) done in 0.806555[s].
Test of 1000000 calls to clock_gettime(CLOCK_MONOTONIC) done in 0.793926[s].
Test of 1000000 calls to clock_gettime(CLOCK_PROCESS_CPUTIME_ID) done in 1.821785[s].
Test of 1000000 calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID) done in 1.604903[s].
Test of 1000000 calls to gettimeofday() done in 0.782640[s].

unsigned int cnt = 1000000;
for (unsigned int i = 0; i < cnt; ++i)
{
    clock_gettime(clock_type, &time_test_clock_gettime);
}

Accuracy

nextCallTime = getSomeTime() + x;
while (1)
{
    now = getSomeTime();
    if (now > nextCallTime)
    {
        doSomething();
        nextCallTime = now + x;
    }
}

• PROBLEM A: The structured filled by a function call gives nanoseconds. However, during initial tests, there was always "jump" between calls divisible by 1000. This suggested the clock step below the ground is 1 microsecond (to be verified later !)
  
• PROBLEM B: The response of the above loop on GPIO was with accuracy of +-900 ns - mostly late by random time (0 - 1000 ns). The sampler was reporting +-50 cycles accuracy (at 50 Mhz), to much error for my needs
  
• PROBLEM C: From time to time (each few microseconds) I could see longer delays (a lot more than 10 us).
  Simply, there was a high chance of my process loosing CPU context - I think because both the clock_gettime() and gettimeofday() are system-calls.
  

Timers accuracy explained

The error of measurement itself (problem B)

The clock_gettime() implementation

• The Raspberry Pi kernel source code tree can be cloned from this GIT repo: https://github.com/raspberrypi/linux.git
  
• clock_gettime() is a syscall defined in posix timers implementation (kernel/posix-timers.c) - just few lines of code calling clock_get() from k_clock struct
  
• ktime_get() is a part of kernel timekeeping code (kernel/time/timekeeping.c) - simple while{} loop reading sequence from timekeeper struct and some math playing with sec/nsecs
  
• timekeeper getting the time from clocksource (kernel/time/clocksource.c)
  
• bcm2708 (arch/arm/mach-bcm2708/bcm2708.c) driver registers to clocksource through clocksource_register_hz() calling __clocksource_register_scale()
  
• clocksource calls reclksrc_read() in BCM driver to get the time value
  
• the value is copied from (ST_BASE + 0x04) register, which is CLO (System Timer Counter Lower 32 bits in System Timer Registers),
  
• the System Timer Counter is declared to be 1 Mhz
  

• The clock/timer itself is 1 Mhz, so the timing is 1 microsecond based anyway. Less-than-1-us accuracy is not possible using that timer.
  
• It may be beneficial to skip all the system-call stuff, the math around it, and getting through all the layers to get pure tick count.
  

Getting direct ticks

#define BCM2708_ST_BASE 0x20003000 /* BCM 2835 System Timer */

volatile unsigned *TIMER_registers;

unsigned int TIMER_GetSysTick()
{
    return TIMER_registers[1];
}

void TIMER_Init()
{
    /* open /dev/mem */
    int TIMER_memFd;
    if ((TIMER_memFd = open("/dev/mem", O_RDWR/*|O_SYNC*/) ) < 0)
    {
        printf("can't open /dev/mem - need root ?\n");
        exit(-1);
    }

    /* mmap BCM System Timer */
    void *TIMER_map = mmap(
        NULL,
        4096, /* BLOCK_SIZE */
        PROT_READ /*|PROT_WRITE*/,
        MAP_SHARED,
        TIMER_memFd,
        BCM2708_ST_BASE
    );

    close(TIMER_memFd);

    if (TIMER_map == MAP_FAILED)
    {
        printf("mmap error %d\n", (int)TIMER_map);
        exit(-1);
    }
    TIMER_registers = (volatile unsigned *)TIMER_map;
}

Test of 1000000 calls to getSysTick() done in 0.109953[s].

• we've got around 110 ns call instead of 800 ns to measure time
  
• we're no longer getting values through system-call, so less chance for the thread getting preempted
  
• the implementation is simple, however we need root privileges
  

Further reading

FAQ - stuff from your emails