Thread priorities and rttlua

To achieve deterministic latencies, we have isolated several cores to
exclusive use by orocos in the kernel, and in the deployer use
setActivityOnCPU to explicitly launch our hard real-time threads on those
cores.

Everything seems to be working well with the classic deployer.
With rttlua deployment, I am getting thread contention, such that when I
call:

os.execute("sleep ".. 3)

it may take arbitrarily long for the lua script to wake back up.

Do you think the problem is with the priority/affinity of the "sleep"
process that gets launched, or with the priority/affinity of the lua
deployer?

I'm open to other ways of sleeping; I just need something that is accurate
to within, say, 10% for my experiment-automation use cases.

Cheers,
Andrew

Thread priorities and rttlua

On Do, Jan 23, 2014 at 03:56:22 +0100, Andrew Wagner wrote:
>To achieve deterministic latencies, we have isolated several cores to exclusive
>use by orocos in the kernel, and in the deployer use setActivityOnCPU to
>explicitly launch our hard real-time threads on those cores.
>Everything seems to be working well with the classic deployer.
>With rttlua deployment, I am getting thread contention, such that when I call:
>os.execute("sleep ".. 3)
>it may take arbitrarily long for the lua script to wake back up.
>Do you think the problem is with the priority/affinity of the "sleep" process
>that gets launched, or with the priority/affinity of the lua deployer?

Yes, rttlua does not execute with real-time priorities by default, hence
your other stuff is probably keeping it from running.

>I'm open to other ways of sleeping; I just need something that is accurate to
>within, say, 10% for my experiment-automation use cases.

What exactly are you trying to do?

There is the inofficial Lua rtt.sleep(sec,nsec) call using
rtos_nanosleep underneath, which is more accurate and efficient than
os.execute. But then I suppose you'll need to make more fundamental
changes to get this working than just switching to that.

Markus

Thread priorities and rttlua

On Thu, Jan 23, 2014 at 4:16 PM, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:

> >I'm open to other ways of sleeping; I just need something that is
> accurate to
> >within, say, 10% for my experiment-automation use cases.
>
> What exactly are you trying to do?
>

Non-hard tasks like waiting for motors to warm up while rotating,
generating randomish signals to exercise servos... finding a guaranteed
hard way to sleep for safety critical tasks can wait for another day.

There is the inofficial Lua rtt.sleep(sec,nsec) call using
> rtos_nanosleep underneath, which is more accurate and efficient than
> os.execute. But then I suppose you'll need to make more fundamental
> changes to get this working than just switching to that.
>

I just pulled all of my sleep calls into one function (soooo nice to be
using a real language to avoid code duplication), so experimenting is
cheap. I have at least one test that is exhibiting the (soft) deadlock
every time I run it too. Thanks for the suggestion; I'll try it!

Thread priorities and rttlua

OK, this is resolved now. Both of our sleep techniques were working; the
problem is elsewhere in our code. Thanks!

For future reference, this is what I'm doing: