i.mx28 system timer/clock problem

[bernhardr_]

Hello,

While testing the real-time ability of my imx287 I came across some problems.

First I created a latency histogram with cyclictest. The histogram I got looked like a comb.

Between 100 and 640us there were vertical lines with a distance of 32us to each other.

Then I tried to use ftrace, to get some more latency values.

I got this result:

function_graph: duration 0.000 or 10000.00us

irqsoff:              time 0us or 200000us

sched_event:    timestamp xxx0000

The last interesting thing I found out was the result of a simple c-program.

I took two timestamps and calculated the difference:

    struct timeval start, stop, diff;     gettimeofday(&start,NULL);     gettimeofday(&stop, NULL);     timersub(&stop, &start, &diff);          clock_gettime(CLOCK_MONOTONIC, &start);     clock_gettime(CLOCK_MONOTONIC, &stop);     diff = time_diff(start, stop);

I run this program on different machines with this result:

TX28(i.mx287):   mostly 0ns, sometimes 32250ns

RaspberryPi:     1000-5000ns

I7-870:              200-500ns   

It looks like a 32us resolution to me.

The TX28-Starterkit is simular to the imx28evk.

I use the mainline kernel 3.3 with the tx28 patch.

It seems the patch doesn't change clock/timer code.

Is this phenomenon right for the i.mx28 or is there a bug in the kernel (port)?

Has anybody else recognised this problem using i.mx28?

Maybe someone could try this on the imx28evk.

Where could be the problem?

Original Attachment has been moved to: trace_timer_output.txt.zip

[JackyAtFreescal · Accepted solution]

That is normal because gettimeofday in imx28 has 31.25usec resolution.

The timer is sourced from 32000Hz clock, see mx28_timer_init() in kernel code.

Regards,

Jacky

[bernhardr_]

Hi,

thanks for your answers,

that's exactly what I am locking for.

I changed the clock source and got a better resolution!

And yes, good point, I should protect my code.

[pradipk]

Hi Bernhard R.

We are facing same issue!

Could you plz provide details on how you have changed clock source?

sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns

Thank you in advance,

Pradip.

[AnsonHuang]

Hi, Bernhard

     Is it possible that the big difference you got on i.MX287 is caused by kernel scheduler? I meant when finishing the collection of start time, then this process is scheduled out, then when it scheduled back, the end time will be much larger. If so, can you try to add some protection to make sure there is no task switch between them, you can try to disable interrupt before executing this code piece.