Writing code that takes time to run

[Richi Dubey]

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>