S
Stan Brown
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
>
>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