Writing code that takes time to run

[Jan.Sommer at dlr.de]

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210520/eea748ba/attachment-0001.html>