Writing code that takes time to run

Richi Dubey richidubey at gmail.com
Fri May 21 04:20:42 UTC 2021


Hi,

Thanks for your quick responses!

The suggestion certainly is helpful, we are going to try it out. I'll post
the result here.

On Thu, May 20, 2021 at 8:57 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Thu, May 20, 2021 at 10:05 AM <Jan.Sommer at dlr.de> wrote:
>
>> Hi Richi,
>>
>>
>>
>> You can checkout the T_busy functions here:
>> https://git.rtems.org/rtems/tree/cpukit/include/rtems/test.h#n2390
>>
>> uint_fast32_t T_get_one_clock_tick_busy(void) gives you the busy count
>> for one tick.
>>
>>
>>
>> You can then calculate the number of cycles you need to wait for you
>> desired certain time and pass it to: void T_busy(uint_fast32_t)
>>
>> This should give you comparably accurate results over different platforms.
>>
>
> That's certainly a better method than what I suggested.
>
> --joel
>
>>
>>
>> Best regards,
>>
>>
>>
>>     Jan
>>
>>
>>
>>
>>
>>
>>
>> *From:* devel <devel-bounces at rtems.org> *On Behalf Of *Richi Dubey
>> *Sent:* Thursday, May 20, 2021 4:53 PM
>> *To:* rtems-devel at rtems.org <devel at rtems.org>
>> *Subject:* Writing code that takes time to run
>>
>>
>>
>> Hi,
>>
>>
>>
>> We are thinking of writing a piece of code that takes some time to run
>> (it would be amazing if it takes around 2 secs to run on hardware, but we
>> would be happy with something that takes a few milliseconds as well).
>>
>>
>>
>> We tried writing this:
>>
>>
>>
>>   for(int i = 0; i<10000000; ++i){
>>       fib2 = fib0 + fib1;
>>       fib0 = fib1;
>>       fib1 = fib2;
>>   }
>>
>>
>>
>> which takes few milliseconds when tested on qemu, but only takes few
>> microseconds on a real board. Do you have any suggestions of what else we
>> can do?
>>
>>
>>
>> We want to write a code that is context switch safe (so, we can't simply
>> check the time before a loop, run an infinite loop that keeps checking
>> current time and stops after a few seconds - because this logic would fail
>> if there happens a context switch inside the loop and the task gets the
>> control back after a few seconds). We also don't want to do a wake_after()
>> since we want the task to be running on the cpu during the entire time (it
>> is okay if the task gets preempted due to a higher priority process), and
>> not voluntarily giving the control to some other task.
>>
>>
>>
>> Any suggestions? The aim is to see the affect of a task getting removed
>> from the cpu due to task shifting by the newly arrived task (in strong apa
>> vs non task shifting scheduler).
>>
>>
>>
>> Thank you.
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210521/cdbe88ac/attachment.html>


More information about the devel mailing list