Writing code that takes time to run

[Richi Dubey]

Thanks a lot for the explanation. This is exactly what we were looking for,
and on our tests, on the qemu, it works fine. We will test it on the board
really soon as well.



On Sat, May 22, 2021 at 5:54 PM <Jan.Sommer at dlr.de> wrote:

> Yes, exactly.
>
> For example if you want to block for 1s:
>
> uint32_t cycles_per_tick = T_get_one_clock_tick_busy(void);
>
> uint32_t cycles_per_sec = rtems_clock_get_ticks_per_second() *
> cycles_per_tick;
>
> T_busy(cycles_per_sec);
>
>
>
> It you take a look at the implementation of T_busy (
> https://git.rtems.org/rtems/tree/cpukit/libtest/t-test-busy.c) it is just
> a loop which wastes count cpu cycles.
>
> So the 1s is the time it blocks while being active on a CPU.
>
>
>
> Of course this only holds true if the cpu frequency is constant during
> execution.
>
> In most hardware cases this should be the case for RTEMS. I think by
> default energy saving is not used in BSPs.
>
> I am not sure how qemu will behave. Does someone else have more
> information on this one?
>
>
>
> Best regards
>
>
>
>     Jan
>
>
>
> *From:* Richi Dubey <richidubey at gmail.com>
> *Sent:* Saturday, May 22, 2021 7:21 AM
> *To:* Joel Sherrill <joel at rtems.org>
> *Cc:* Sommer, Jan <Jan.Sommer at dlr.de>; rtems-devel at rtems.org <
> devel at rtems.org>
> *Subject:* Re: Writing code that takes time to run
>
>
>
> Hi,
>
>
>
> About the code:
>
>
>
>  T_busy(T_get_one_clock_tick_busy() * SOME_CONSTANT);
>
>
>
> does this support context switch? If task A executing on CPU 1 gets
> preempted while executing this (by task B) and then comes back on CPU 1
> after some time (when task B finishes its execution), would task A finish
> its execution of this function - as nothing happened?
>
>
>
> So, if we ask Task A to run T_busy for 5000 ticks, and it gets preempted
> after 3000 ticks and maybe moves to another CPU, would it run for the
> remaining 2000 ticks on that CPU?
>
>
>
> On Fri, May 21, 2021 at 9:50 AM Richi Dubey <richidubey at gmail.com> wrote:
>
> 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/20210523/565f190b/attachment-0001.html>