>> On Wed, Aug 01, 2012 at 03:39:26PM -0700, Johnathan Van Why wrote:
>> > I have heard that system calls are never realtime safe in Linux, even
>> > under a RT-PREEMPT kernel. Unless everyone I've asked is mistaken
>> > (I've asked on StackOverflow and at LinuxQuestions.org, neither of
>> > which focus on realtime software), not even system calls like
>> > clock_gettime() are realtime-safe.
>>
>> No, both correctly configured and validated RT_PREEMPT or Xenomai
>> kernels can run applications satisfying hard real-time constraints.

That's good news -- I was wondering how RT_PREEMPT could promise hard
realtime performance if you had no realtime IO options.

>> System calls may or may not be permitted in rt-paths,
>> i.e. clock_gettime(2) is, but malloc(2) is not.

How can I tell? Is there some sort of list, or is it something people
Just Know (i.e. do I need to look through the kernel's source to check
for determinism)?

Thank You,
Johnathan Van Why

On Thu, Aug 02, 2012 at 09:38:41AM +0200, Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> On Thu, Aug 2, 2012 at 8:54 AM, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> Hi Jonathan,
>
> On Wed, Aug 01, 2012 at 03:39:26PM -0700, Johnathan Van Why wrote:
> > I have heard that system calls are never realtime safe in Linux, even
> > under a RT-PREEMPT kernel. Unless everyone I've asked is mistaken
> > (I've asked on StackOverflow and at LinuxQuestions.org, neither of
> > which focus on realtime software), not even system calls like
> > clock_gettime() are realtime-safe.
>
> No, both correctly configured and validated RT_PREEMPT or Xenomai
> kernels can run applications satisfying hard real-time constraints.
>
> In a nutshell, the advantage of using RT_PREEMPT is that run're
> running a single, less intrusively patched kernel. On the other hand
> the real-time'ness of a Xenomai system (as a dual-kernel approach)
> depends on a much smaller codebase, and (opposed to RT_PREEMPT) can
> not be (so) easily screwed up due to buggy kernel drivers etc. Most
> people start with RT_PREEMPT and then switch to Xenomai if necessary.
>
> > How does Orocos accomplish hard-realtime on Linux without using system
> > calls? Knowing might help keep me from unintentionally breaking
> > realtime within our Orocos-based components.
>
> OROCOS RTT is implemented using different techniques to avoid
> non-deterministic behavior, including avoiding memory allocations in
> critical paths, lock free buffers, real-time allocators, etc.
>
> System calls may or may not be permitted in rt-paths,
> i.e. clock_gettime(2) is, but malloc(2) is not.
>
>
> I don't know about RT_PREEMPT, but as far as I understand, calling
> clock_gettime is _not_ realtime-safe in Xenomai, even when selecting the
> CLOCK_REALTIME clock. See this previous thread for more details [1]. Of worth

CLOCK_REALTIME always causes confusion because it does not refer to
real-time in the sense of this thread, it refers to "real" wall clock
time. Since in most real-time systems you don't care about that, but
rather want a stable clock source that doesn't change when the system
clock changes, most applications will want to use CLOCK_MONOTONIC.

> noting, prior to Xenomai 2.6, there was no clean way to query a timestamp in
> the same timebase as clock_gettime(CLOCK_REALTIME, &tv) from a realtime
> context.

You're right, but for the measurements that Jonathan is doing you
don't care about absolut time, hence the synchronization between
Xenomai and Linux should not be a problem.

> [1] http://www.orocos.org/forum/orocos/orocos-users/
> comparing-timestamps-generated-rt-and-non-rt-contexts

So, gettimeofday is not realtime safe, but clock_gettime is!

Markus

2012/8/2 Johnathan Van Why <jrvanwhy [..] ...>:
>> Maybe you should have a look to xenomai :
>> http://www.xenomai.org/
>
> Is Xenomai required for hard real-time with Orocos?
> I was under the
> impression that RT-PREEMPT was sufficient to ensure hard realtime
> execution.

I don't know about RT-Preempt. The only thing I can say is that
xenomai may provide you for sure hard real time capabilities if used
correctly.

>
> Thank You,
> Johnathan Van Why
> Dynamic Robotics Laboratory
> Oregon State University