[Balug-talk] Micro/Nano/Millisecond timing tutorial (continued)

[Brian Sroufek]

I add below some other nooks and crannies that more
completely satisfy 'defeating' the standard system
time slicing and other issues for achieving RT.

Brian Sroufek wrote:

> Rick Moen wrote:
>
> > begin Brian Sroufek quotation:
> > > I have a link here with some sample timing code
> > > for ya (this is my/our product, so please don't
> > > share it with others):
> > >
> > > ftp://ftp.msdesigninc.com/pub/msem.c.out
> >
> > Thank you!  I'll certainly have a look at it.
> >
> > Since I'm absolutely a duffer at the sort of topic I just got through
> > addressing on balug-talk, and you obviously are an expert:  I hope I
> > didn't do too badly?
> >
>
> Rick, you are correct on this issue at face value.
>
> However, I will offer here a tutorial for those interested on
> how a patch like the one you mentioned can work, and how applications
> can actually work at a real-time level on a Win32/Linux PC.
>
> The single greatest issue is the time slicing, which defaults to about
> 30 msec per slice I believe.
>
> In multi-thread blocking, semaphores, mutexes and other multi-tasking
> operations, this time slice would seem to preclude any operations at
> increments lower that the above.
>
> In actuality, I'm very glad that this time slicing situation exists,
> as in general it is advantageous, but it can be 'defeated' on a per
> application basis for the purpose of real-time activity.
>
> With RTOS-like needs on a non-RTOS, one can actually achieve sufficient
> timing by the means I describe here.
>
> Suppose you have multiple tasks running, one or more with nano/micro
> level polling of device ports (bi-directional), and others doing
> application (perhaps GUI) related activities.
>
> Now, suppose these tasks are each spun on a thread basis, all of them
> (or at least related ones) being contained within the same process.
>
> Then, on a thread competition model, one can achieve real-time usage
> of the CPU/clock/system by the following logic (pseudo code):
>
> START TUTORIAL
> --------------------------------------------------------------
>
> TASK A:
>
>     Sets port P values and waits for port readability and values.
>
> TASK B:
>
>     Waits to read port values and then hands off to application.
>
> TASK C:
>
>     Reports on GUI device status dependent information.
>
> When a particular task gets blocked on mutex/semaphore, it should
> 'sleep' itself, that is its own thread, thus telling the system to
> preempt and switch to one of the other non-blocked threads.
>
> In Unix/Linux land, a nanosleep() call will do just this.
>
> As a result, the system doesn't sit within a competing thread waiting
> for the time slice to expire while the thread is simply looping,
> waiting for the gate (mutex/semaphore) to open.
>
> As the system uses a round robin type of approach to time slicing,
> one aids the system and its use of resources/responsiveness by
> giving up unnecessary system time.
>
> -------------------------------------------------
> END TUTORIAL
>
> I hope this isn't too abstract or poorly written, obtuse or otherwise
> ineffective for the reader.
>

PAGE LOCKING
------------------

I add to this Page Locking.  While time slicing is a significant
inhibitor to RT response/performance, getting paged out onto disk
is far worse.  To prevent this, you can review on Linux:

    > man mlock
    or
    > man mlockall

for locking portions and entire processes into memory and thus
preventing the awful and (for RT critical apps) disastrous effects
of being swapped out.


RECOMPILING KERNEL
-------------------
There are parameters within the kernel which can be modified for
specifically tuning a system for RT performance, starting with:

    > man sched_setscheduler
    and searching under /usr/include/linux for the headers/files
    defining these paramters.


DEFINING YOUR OWN MEMORY ALLOCATION SCHEME
--------------------------------------------

Wherein you initially allocate a buffer and locally chunk it
so you can avoid the malloc() heap cost stuff.

Also, options on this memory can be laid initially to prevent
paging, affect location, etc.


APPLICATION DESIGN ISSUES
------------------------------------------

Placing higher (real time?) priority on low-level producing and
consuming threads (not application level ones) helps much.

Also, events should queued by these low level readers/writers so
as not to detain them from their primary activity of reading
and writing.

If you do not queue those events, then consider using global
memory and having other threads so this.


POLLING/ASYNC
---------------------------------------------

Finally, an important issue is that nearly all very low level readers/
writers are polling their sources, while next level threads are
able to effect status and messages into an event model.

This is a standard approach for isolating an application from its
real-time components on the bottom.

.... [Can't think of anything else off top of my bald head]

>
> Cheers,
>
> Brian Sroufek
>
> _______________________________________________
> Balug-talk mailing list
> Balug-talk at balug.org
> http://www.balug.org/mailman/listinfo/balug-talk