This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Computation time measurement

Other Parts Discussed in Thread: OMAP-L137

Hi all.

I want to measure the computation time of an algorithm running on the C6747 (on OMAP-L137 EVM). The algorithm is placed in a loop of 10000 iterations and prior and after algo execution, I call CLK_gethtime() . Finally I'd like to have minimum, maximum and average computation time in miliseconds (with a precision of let's say 0.1 ms). Therefore I divide all the measurements by CLK_countspms(). The whole thing is compiled in release mode with -o3 and -mf5 but with full symbolic debug.

What I get with this method is something like:

t_min = 2.20 ms
t_mean = 2.21 ms
t_max = 2.8 ms

But if I multiply the measurements by the number of iterations I'd get a total measurement time of ~ 22 seconds. But my stop watch only shows something like 2.2 seconds.
So where is the problem? Should I divide my measurements by 10? I first thought it was due to the compiler optimizing the loop, but there I'm wrong. I get similar values if I only "iterate" once. I think the optimization is there indeed, leading to very close t_min and t_mean, but it does not explain the why the measurements are not correct to a factor 10...
Can anybody tell me where I'm wrong? Or some other hints? As a reference, here is the code leading to the above measurements:

 

const Uint16 TEST_ITER = 10000u;
float timeMean = 0.f;
float timeMin  = 1e16f;
float timeMax  = 0.f;
float dtime;
Uint32 timeStart;
Uint16 idxTest;
for (idxTest = 0u; idxTest < TEST_ITER; idxTest++) {
    timeStart = CLK_gethtime();
    validImg = imregions (binFilterImg, procImg, regionImg, regions, &nRegions);
    dtime = (float)(CLK_gethtime()-timeStart)/(float)CLK_countspms();
    if (dtime > 0.f) {
        timeMean += (dtime/(float)TEST_ITER);
        if (dtime < timeMin) timeMin = dtime;
        if (dtime > timeMax) timeMax = dtime;
    }
}
LOG_printf(&trace, "t_min = %f", timeMin);
LOG_printf(&trace, "t_max = %f", timeMax);
LOG_printf(&trace, "t_mean = %f", timeMean);

 

Thank you very much for your help.

Andreas

 

  • Hi Andreas --

    LOG_printf() does not support the %f option.  It only supports the options specified in the LOG_printf() manual page. 

    Can you try standard "printf()" for this experiment?   Or scale these to integer values and use LOG_printf().

    Thanks,
    -Karl-

  • Hi Karl. I've tested scaling the values (by a factor 10000) and then using "%d". I obtain the same results as in my original post. Anyway, is it correct to use

    (CLK_gethtime() - tOld) / CLK_countspms()

    to obtain a delta_t in miliseconds?

    Thanks,

    Andreas

     

  • Yes.  That should work.

    I build the attached sample  0638.clocktest.zip

    for evm6748 and got the following output:

    0   clk example started.
    1   The time in task is: 0 ticks
    2   countspms = 300000
    3   task going to sleep for 10 ticks...
    4   ...awake! Time is: 10 ticks
    5   t1 - t0 = 2998854, t1 - t0 / countspms = 9

     

    which is consistent for a 300MHz 6748 board.


    Can you try this app and see what you get?

     

     

     

  • Hi Karl and thanks for your answer. I get quite the same output as you (i.e. line 5: 9 ms)...
    I'll try to put my computation block in this app at the place of TSK_sleep and see what I'll get.

     

  • I've checked placing my algorithm in the example that you provided. It seems the output of time measurement is coherent. Then I've rechecked with my own code: again strange outputs. But I've found the problem. With

    LOG_printf(&trace, "clkpms = %d", CLK_countspms());

    I got 40000 as the result.:( Then I remember that some time ago I changed bios.GBL.CLKOUT = 40.0000; because I thought it would change the DSP clock speed. I then found the correct way to change the clock speed but I forgot to reset bios.GBL.CLKOUT = 40.0000 to its original value!

    Anyway, thanks a lot for your help.