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: