Linux PLC: ISA Article and a Charter of sorts(long)

On Wed Jan 19 15:42:33 2000 Phil Covington wrote...
>
>Hello All,
>
>This is an incomplete and simplified overview of options for real time linux
>as it
>would apply to the LinuxPLC. Please see http://www.realtimelinux.org for
>links to
>much more detailed information.

Thanks very much for the summary.
>
>*Problems with Periodic Tasks in the Normal Linux Kernel*
>
>1. Linux has system calls to suspend a process for a given time period,
>but there is no guarantee that the process will be resumed as soon as
>this time interval has passed.
>
>2. Any user process can be pre-empted at an unpredictable moment.
>
>3. Assigning high priority to critical tasks doesn't help much since
>Linux has a "fair" time-sharing scheduling algorithm. See 5 below.
>
>4. Under Linux, virtual memory can be swapped out to disk at any time
>and swapping back into RAM takes an unpredictable amount of time. See 5
>below.

Give all the above, is it impossible, or unlikely that we can achieve _average_ scan times in the 10's of milliseconds without using one of the real time extensions?

>5. Linux now has POSIX style system calls for soft real-time tasks. Virtual
>memory can be locked in RAM, and the scheduler policy can be changed to a
>priority based policy.

If the answer to the above is yes, an we achieve these scan times by using the POSIX style extensions?

Here are my thoughts on this subject.

1. We must achieve scan times for the logic engines in the low tens of milliseconds for an average sized simple bit banging control program.

2. If this requires one of the real time extensions, then we must bite the bullet and put it in the base design.

3. If this is true, we should use one of the (2 ?) that use POSIX real time semantics, to allow for portability.

4. If however we can achieve the speed above, on average, realizing it's not deterministic, then I would suggest that the real time functionality be an add in feature, that we can compile without. I say this in the name of portability


Comments?


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Phil Covington

Hi Stan,

From: "Stan Brown" <[email protected]>

<snip>
> >*Problems with Periodic Tasks in the Normal Linux Kernel*
> >
> >1. Linux has system calls to suspend a process for a given time period,
> >but there is no guarantee that the process will be resumed as soon as
> >this time interval has passed.
> >
> >2. Any user process can be pre-empted at an unpredictable moment.
> >
> >3. Assigning high priority to critical tasks doesn't help much since
> >Linux has a "fair" time-sharing scheduling algorithm. See 5 below.
> >
> >4. Under Linux, virtual memory can be swapped out to disk at any time
> >and swapping back into RAM takes an unpredictable amount of time. See 5
> >below.
>
> Give all the above, is it impossible, or unlikely that we can achieve
> _average_ scan times in the 10's of milliseconds without using one of
> the real time extensions?


With a process running in user space, it is not possible to achieve less than 20 ms scan times. Unfortunately the 20 ms scan time (periodic task)
would degrade seriously with system load - especially disk activity.


> >5. Linux now has POSIX style system calls for soft real-time tasks.
Virtual
> >memory can be locked in RAM, and the scheduler policy can be changed to a
> >priority
> >based policy.
>
> If the answer to the above is yes, an we achieve these scan times by
> using the POSIX style extensions?


The 20 ms scan time (periodic task) that I quoted above is assuming that we are using SCHED_FIFO and locked memory. This is absolutely best case. With increasing system load there will be increasing jitter in the scan time...
meaning the scan time won't be constant even though we are executing the exact same logic path in the Logic Engine (user process).

> Here are my thoughts on this subject.
>
> 1. We must achieve scan times for the logic engines in the low tens of
> milliseconds for an average sized simple bit banging control program.
>
> 2. If this requires one of the real time extensions, then we must bite
> the bullet and put it in the base design.
>
> 3. If this is true, we should use one of the (2 ?) that use POSIX
> real time semantics, to allow for portability.
>
> 4. If however we can achieve the speed above, on average, realizing
> it's not deterministic, then I would suggest that the real time
> functionality be an add in feature, that we can compile without. I say
> this in the name of portability
>
> Comments?

Some people may be able to live with scan times of 20+ ms and in that case the normal linux kernel will be fine.

For sub 20 ms scan times, then a real time extension is necessary. That leaves us right now with only two choices - RTLinux and KURT since they are the most mature and stable linux real time extensions. Either way it will require people to patch and re-compile their kernels or download a pre-patched kernel.

IMHO if we are to support RTLinux then the Logic Engine will have to be a real time module. It makes no sense to have the I/O drivers be real time modules and the Logic Engine a normal linux process. Because RTLinux runs normal Linux as a low priority task the userland Logic Engine will be subjected to even more unpredictable delays as discussed above. Additionally, RTLinux modules do not have access to the normal linux services - How could they? The whole linux kernel is being run as a lowest priority task by the RTLinux kernel! If you need sub millisecond period
tasks, such as a servo loop as in NIST's EMC project, then RTLinux is the only way to go.

The advantage that I see with KURT is that you can run a userland process (the Logic Engine) as a periodic real time process through the Process
RTMod. Whether the real time processes are kernel modules or userland processes they all have access to the linux kernels services. With KURT, scan times in the 1 - 10ms range should be possible with acceptable jitter as the system is loaded.

I wish too that we didn't have to do anything to the kernel to get sub 20 ms scan times. Writing kernel modules are much more dangerous than userland processes too.

At this point I am not advocating one real time extension over the other. This subject, I am sure, will start another round of arguments. I really like RTLinux because it doesn't make any changes to the normal linux kernel which I think is cleaner. I am attracted though to KURT because it allows the use of the linux kernel's services and allows real time userland
processes. This would give us more flexibility in the Logic Engine since it (the userland Logic Engine) could be real timed under KURT or just userland under the normal linux kernel for applications where scan times of 20ms+ are
acceptable. .Unfortunately both RTLinux and KURT can't co-exist... ;-(

Phil Covington
vHMI


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top