Real Time Linux Overview

P

Thread Starter

Phil Covington

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.

*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.

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.

6. Linux disables interrupts in critical sections. Tasks running in kernel mode cannot be scheduled out. The disk subsystem can delay user tasks by unpredictable amounts of time by disabling interrupts.

7. Processes can be set to SCHED_FIFO to give them soft real-time characteristics. This
may be enough for 20 - 30 ms periodic tasks (scan times).

8. Linux has low granularity timers (10 ms).


*Real Time Linux (NMT's RTLinux)*

1. RT Linux is a small, simple, real time OS that runs Linux as a low priority task. Changes
to the Linux kernel are minimal.

2. Real Time tasks can be scheduled precisely. On a P120 system a task can be scheduled with
under 20 uS precision.

3. RT Linux uses kernel modules and Linux can dynamically load and unload them just like normal
kernel modules.

4. RT Linux tasks CANNOT use Linux system calls or directly call routines and access linux data
structures in the linux kernel.

5. Users can write their own schedulers as loadable kernel modules.

6. RT Linux can communicate to linux user processes through FIFOs or shared memory.

7. RT Linux is considered to be hard real time.


*KU Real Time Linux (KURT)*

1. KURT is a modification to the linux kernel which adds microsecond timing and three modes to
the kernel.

2. (A)Normal Mode behaves like the normal linux kernel (with microsecond resolution). (B)Focused
Real Time Mode where only designated real time processes are allowed to run.
(C)Mixed Real Time
Mode where all processes are allowed to run with real time processes being explicitly scheduled and
normal processes running in the constraints of the real time processes.

3. In either Focused or Mixed Real Time Modes the real time processes can still access any of the
system services of the linux kernel.

4. Real Time tasks are kernel modules and execute in kernel mode. There is a rtmod_cmd system call
to allow user processes to directly communicate with a real time module. This system call is
similar to the *NIX ioctl.

5. There is a built in real time module called Process RTMod that switches context to a specific user mode process when invoked. This allows real time user processes! There is some overhead with a context switch, but the advantage is that you can make your user process real time.

6. A process can be scheduled periodically without an explicit schedule. This would be applicable to a scanned system.


*Other Real Time Linux Projects*

1. ART Linux - documentation is in Japanese so I'm not sure how it fits in.

2. RED Linux - heavy modification to the Linux Kernel and very early in the development stages.

3. RTAI - based on RT Linux, but adds POSIX type calls, etc.. see the link at realtimelinux.org


Phil Covington
vHMI


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Thu Jan 20 09:40:31 2000 Mark Hutton wrote...
>
>One thing to bear in mind about a lot of Windows NT based softPLCs
>(SteepleChase, TwinCAT(?)) is that they provide their own kernel to run at a
>lower level than Windows.
>
>These may not use official RT extensions but they are extensions none the
>less.
>

Yes, my friend did say the some soft PLC vendors were doing this. However he also said that some were not, and still were achieving good
scan times. His phrasing was actually "better than a hardware PLC". I consider him a pretty good source. He is involved in the day to day
choices of technology to deploy for a large system integrator. To the best of my knowledge, they have not done a soft PLC system yet, because
of other concerns about them, But he sounded happy with the scan time issue.

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

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

Johan Bengtsson

To me it seems like KURT is the road to go... With the possibility for the user to say KURT or plain Linux if that is (easily enough) possible.

In that way should the I/O-processes and the "brains" run using KURT and/or plain Linux as the user sees fits the current application. (All I/O:s and "brains" in the same computer may not need to be that hard sheduled).

To me it sounds like RTLinux unfortunately is some bit away.

Could it tecnically be done in a way that would allow all? Ie, make the shared memory accessible from RTLinux, in most cases you can use KURT. In some cases you have to use RTLinux but are then restricted to a subset of I/O-hardware and
"brains" (There should of course be a logic solver (for example ladder) in RTLinux, but perhaps not much more initially) I/O hardware using network is (as I have understood it) out
of the question with RTLinux (at least in a realtime process). If the really fast I/O:s can be accessed from a RT process but some not so fast networked I/O:s may still be accesed by
a user mode (non RT) process.


Conclusion: My vote is: make it possible but not necesary to use RTLinux and KURT.

If this makes it necesary to have different binaries for each process depending on how it is running - ok they will be written. Most of the code would be the same anyway. It would probably be quite easy to isolate the code doing the
specific work from the code hadling the periodic calling and interfacing and thus mostly making it a recompile to get the other versions.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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

Curt Wuollet

Thanks Phil, This should help those on the list who aren't Linux types (and several who are) start thinking about things that go fast and happen on time. I looked briefly at KURT some time ago and will commit to setting up a box with it for testing if I can borrow one from my day job. I didn't get how you use the framework in my previous skim, but it seems to offer more versatility in a mixed (hardware and networked) IO environment. We would need some expertise to help apply it. We could use at least one other volunteer as I will have severe time constraints for the next few weeks.

Curt W.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Thu Jan 20 09:30:06 2000 Phil Covington wrote...
>
>NT's software timer tick is 10ms also. There are a few soft PLC vendors
>that offer software that run on unmodified NT - Think & Do is one of them.
>I saw a demo of Think & Do a while back and when I tried to pin them down on
>scan times they just said that most customers run with a scan time of 35 -
>50 ms. They didn't seem to want to commit to consistant scan times under 20
>ms when I asked. I would imagine that 15 - 20 ms scan times is their "best
>case" with no system load though...

So we should be able to achieve this same range then? If so I would suggest that the base system be built without the real time extensions,
but that the real time extensions (whichever gets chosen) be a standard option.

Does that sound like it makes sense?

>You can use linux shmem and shared memory as in memory that the Linux kernel
>doesn't use for processes.

Wonderful, so our original design would still be valid. KURT is sounding better and better to me.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, 20 Jan 2000, Stan Brown wrote:

> On Thu Jan 20 09:40:31 2000 Mark Hutton wrote...
> >
> >One thing to bear in mind about a lot of Windows NT based softPLCs
> >(SteepleChase, TwinCAT(?)) is that they provide their own kernel to run at a
> >lower level than Windows.
> >
> >These may not use official RT extensions but they are extensions none the
> >less.
>
> Yes, my friend did say the some soft PLC vendors were doing this.
> However he also said that some were not, and still were achieving good
> scan times. His phrasing was actually "better than a hardware PLC". I
> consider him a pretty good source. He is involved in the day to day
> choices of technology to deploy for a large system integrator. To the
> best of my knowledge, they have not done a soft PLC system yet, because
> of other concerns about them, But he sounded happy with the scan time issue.

I've just run a simple looping test programme to try and confirm this scheduling problem. it's based around someones description of how a PLC
rep may prove his scan times. Here is the code.

###########

#include <signal.h>



int done = 0 ;

void alarmer(void);

void main(void)
{
long count = 0;


signal(SIGALRM, alarmer);
alarm(10);
for(;done == 0;)
{
count++;
printf("a");
}
printf("\n\n result is %f msec/scan\n", 1 /((float)count / 10.0) * 1000);
}

void alarmer(void)
{
done = 1 ;
}

#############

I ran 21 copies of this concurrently from a shell by doing

for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
do
./test > result.$i &
done

and then a "grep result result.*" gave this

#########

result.0: result is 0.027504 msec/scan
result.1: result is 0.026248 msec/scan
result.10: result is 0.041251 msec/scan
result.11: result is 0.026623 msec/scan
result.12: result is 0.026300 msec/scan
result.13: result is 0.026027 msec/scan
result.14: result is 0.026310 msec/scan
result.15: result is 0.030746 msec/scan
result.16: result is 0.032259 msec/scan
result.17: result is 0.033634 msec/scan
result.18: result is 0.037048 msec/scan
result.19: result is 0.010695 msec/scan
result.2: result is 0.028808 msec/scan
result.20: result is 0.011419 msec/scan
result.3: result is 0.031301 msec/scan
result.4: result is 0.030035 msec/scan
result.5: result is 0.032124 msec/scan
result.6: result is 0.026276 msec/scan
result.7: result is 0.026347 msec/scan
result.8: result is 0.029992 msec/scan
result.9: result is 0.032282 msec/scan

###########

Now I know this is a very simple test but I think it shows some interesting things.

1. An average scan time of sub 1 msec is easilly achievable.
2. Overall run times vary dramatically.

Now correct me if I'm wrong here but:

Our PLC code can and will run in sub 1 msec (based on used processor time).
Because our PLC code will make use of kernel syscalls the kernel will reschedule away from us long before the 10 msec timer interrupt occurs.
If we are scheduled out we will not be scheduled in untill either every other process in the system that can has run and made a syscall or every other process in the system that can has run for 10 msec or a mixture of both.

Is this correct or have I completely stuffed this up?

Assuming I am correct then the questions are:

1. Does any one need every scan to be sub 20 msec?
2. Is it a problem if the scan time varies between scans for a fixed logic programme.
3. Is an average scan time what everybody is talking about.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Wed Jan 19 22:03:08 2000 Phil Covington wrote...
>
>Hi Stan,
>
>----- Original Message -----
>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.

So we could do, say 50 ms scans with decent jitter, without going to 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?
>
>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).

Well real world PLC scan times are not all that consistent either.

>
>> 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.

I like that.
>
>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.

So if we do that the logic engines ( which will be executing joe random's application code ) will be running as a kernel module? Thats
pretty scary.

>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.

That sounds like the best choice, but it's not very portable is it?

>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.

Agreed,
>
>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... ;-(

Well we wouldn't want to be dependent on 2 of them anyway.

I take it you are convinced that even the base system needs one of the 2?


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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Fri Jan 21 12:28:53 2000 Dave West wrote...
>
Excellent!

Now I believe that we can proceed without having to put real time extensions in the base code. I have no objections to trying to design the base code so that the appropriate real time extensions can be added for those who really need deterministic operation. However I am absolutely confident based upon this test that we can build something that will work for 95% of the applications I will ever apply this for without it.

This is truly great news. Now we can write something that will be portable, and I hope be conceptually simple in dewing, as I have been
advocating fro the beginning.

Can we come to a consensus on this?

>Is this correct or have I completely stuffed this up?
>
>Assuming I am correct then the questions are:
>
>1. Does any one need every scan to be sub 20 msec?

I don't

>2. Is it a problem if the scan time varies between scans for a fixed
>logic programme.

Real PLC's do this, so I am prepared for it.

>3. Is an average scan time what everybody is talking about.

It's what I am talking about.


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

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

Phil Covington

----- Original Message -----
From: "Stan Brown" <[email protected]>

<snip>
> So we could do, say 50 ms scans with decent jitter, without going to
> real time extensions?

I think that would be realistic with SCHED_FIFO and locked memory... NT can do 50 - 100 ms without any real time extension easily - so I think we can do better in Linux.

<snip>

> >
> >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.
>
> So if we do that the logic engines ( which will be executing joe
> random's application code ) will be running as a kernel module? Thats
> pretty scary.
> >

The Logic Engine would have to be carefully written...

<snip>

> >
> >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... ;-(
>
> Well we wouldn't want to be dependent on 2 of them anyway.
>
> I take it you are convinced that even the base system needs one of the 2? <

For my purposes I would want scan times under 15 ms and to be able to easily talk to ethernet I/O - that makes KURT very attractive. Unfortunately, I have much more experience with RTLinux than I have with KURT.

There are a few more problems that I haven't explicitly mentioned yet. One is the problem of persisting data tables to disk at every scan as some have proposed. If there is no real time linux then the disk activity can further
degrade the performance of the system even at a 50 ms scan time... Disk activity under linux is when interrupts are disabled for the longest period. With interrupts disabled, the 10 ms timer tick is delayed in driving the kernel's scheduler and will cause jitter (how much is hard to predict, but it won't be generally acceptable).

Phil Covington
vHMI

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

Phil Covington

On Wed Jan 19 23:22:47 2000 Phil Covington wrote...
>
>----- Original Message -----
>From: "Stan Brown" <[email protected]>
>
><snip>
>> So we could do, say 50 ms scans with decent jitter, without going to
>> real time extensions?
>
>I think that would be realistic with SCHED_FIFO and locked memory... NT can
>do 50 - 100 ms without any real time extension easily - so I think we can do
>better in Linux.

I talked to a friend of mine yesterday who stays on top of the current soft PLC offerings. He claims (and is generally very reliable on technical issues) that there are several vendors offering, what I would call normal to fast, PLC scans on NT, without real time extensions.

As I don't know much about NT, I thought I would throw this out for comments.

Has anyone here used, or seen demos of these products?

Does NT have a higher resolution scheduler than Linux, or some other features that would make this possible?

><snip>
>> >
>> >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.
>>
>> So if we do that the logic engines ( which will be executing joe
>> random's application code ) will be running as a kernel module? Thats
>> pretty scary.
>> >
>
>The Logic Engine would have to be carefully written...
>
><snip>
>
>> >
>> >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... ;-(
>>
>> Well we wouldn't want to be dependent on 2 of them anyway.
>>
>> I take it you are convinced that even the base system needs one of the 2?
>
>For my purposes I would want scan times under 15 ms and to be able to easily
>talk to ethernet I/O - that makes KURT very attractive. Unfortunately, I
>have much more experience with RTLinux than I have with KURT.
>
>There are a few more problems that I haven't explicitly mentioned yet. One
>is the problem of persisting data tables to disk at every scan as some have
>proposed. If there is no real time linux then the disk activity can further
>degrade the performance of the system even at a 50 ms scan time... Disk
>activity under linux is when interrupts are disabled for the longest period.
>With interrupts disabled, the 10 ms timer tick is delayed in driving the
>kernel's scheduler and will cause jitter (how much is hard to predict, but
>it won't be generally acceptable).

Will KURT allow us to use normal Linux shared memory? I think this is important for a good design. Being limited to one 4K page, would be a major shortcoming.

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

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

Phil Covington

----- Original Message -----
From: "Stan Brown" <[email protected]>
>
> I talked to a friend of mine yesterday who stays on top of the current
> soft PLC offerings. He claims (and is generally very reliable on
> technical issues) that there are several vendors offering, what I would
> call normal to fast, PLC scans on NT, without real time extensions.
>
> As I don't know much about NT, I thought I would throw this out for
> comments.
>
> Has anyone here used, or seen demos of these products?
>
> Does NT have a higher resolution scheduler than Linux, or some other
> features that would make this possible?

NT's software timer tick is 10ms also. There are a few soft PLC vendors that offer software that run on unmodified NT - Think & Do is one of them.
I saw a demo of Think & Do a while back and when I tried to pin them down on scan times they just said that most customers run with a scan time of 35 - 50 ms. They didn't seem to want to commit to consistant scan times under 20 ms when I asked. I would imagine that 15 - 20 ms scan times is their "best case" with no system load though...

> Will KURT allow us to use normal Linux shared memory? I think this is
> important for a good design. Being limited to one 4K page, would be a major shortcoming. <

You can use linux shmem and shared memory as in memory that the Linux kernel
doesn't use for processes.


Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Many of the people I know who have use softPLC's, have touted their speed as an argument in favour. In a particular case, a colleague was using
Wonderware's InControl. He gave me the impression that it was noticably faster than a PLC - in this context I find this (RTL) discussion confusing
as most of the PLC applications that this colleague worked on had 10-20mS scan times.

A recent visit by an AutomationX rep. brought forth a comment to the effect that the evaluation app. ran at about 10-15mS on Windows NT but would run fster on Linux.

The Sun JVM has a thread sleep resolution of 1mS (actually it is sub 1mS but currently this cannot be achieved by any existing JVM) I have not found
anything to suggest that this resolution is not achievable on any paltform. Java is known to run faster on Linux than Windows NT.

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

Johan Bengtsson

-----Original Message-----
From: MIME :[email protected] [SMTP:MIME
:[email protected]]
<clip>
The Sun JVM has a thread sleep resolution of 1mS (actually it is sub 1mS but currently this cannot be achieved by any existing JVM) ...<clip>

A try to answer this...
It is a long answer, if you really don't want it stop reading

I have tested the actual time a sleep(1) statement takes on a NT computer with the following result:

The output is formated ms : number of hits (se the code at the end)

These tests are for a double processor computer pentium II 350MHz running NT4.

A test run on Linux will be produced as soon as I have managed to compile it in Linux.


************************************************************
PLEASE NOTE: this is test runs made on a Windows NT computer
NOT Linux.
**************************************************

Normal priority, a relatively idle computer:
Most sleeps actually take 2ms, a some (about 4-5%) takes 1ms
a very few takes a little more than 2ms

I always have two at 15-16ms

Realtime priority, a relatively idle computer:
Same as for normal priority

Normal priority, loaded with normal priority processes: Considerable gitter. Most time it still takes 2ms. A peek is found at 15-16ms (NT:s scheduler is operating with this speed), next peek is around 31-32ms (twice the scheduler), and a small peek at 47ms (tree times the scheduler).

Realtime priority, loaded with normal priority processes:
Same as for the very first test.

Normal priority, loaded with low priority processes: A little bit more gitter than the very first test, but a very few takes more than 2ms and none takes more than 16ms.



Actual test data:

Normal priority, a relatively idle computer:

1: 4314
2: 87722
3: 61
4: 7
16: 2


Realtime priority, a relatively idle computer:

1: 4317
2: 87736
3: 52
4: 6
15: 1
16: 1


Normal priority, loaded with normal priority processes:

1: 3468
2: 70222
3: 299
4: 128
5: 81
6: 73
7: 50
8: 33
9: 33
10: 29
11: 43
12: 11
13: 3
14: 5
15: 301
16: 479
17: 3
18: 6
19: 8
20: 7
21: 1
22: 4
23: 4
24: 3
25: 3
26: 4
27: 6
28: 11
29: 13
30: 5
31: 398
32: 137
33: 2
45: 1
47: 11
56: 1
62: 4
63: 3

Realtime priority, loaded with normal priority processes:
1: 4317
2: 87787
3: 26
15: 1
16: 1



Normal priority, loaded with low priority processes:
1: 4303
2: 87089
3: 247
4: 63
5: 20
6: 30
7: 12
8: 2
9: 7
10: 3
11: 2
16: 2



Code used for the test:
Compiled using VC++ 4.0


#include <windows.h>
#include <stdio.h>
#include <mmsystem.h>
#pragma comment(lib,"winmm.lib")

#define maxTime 2000
unsigned int hits[maxTime+1];


int main(void)
{
unsigned int startTime,lastTime,currentTime,diffTime;
int i;


/*this gives a 10 second pause before starting*/
for (i=10;i;i--)
{
printf("Wait %d \r",i);
Sleep(1000);
}
printf("testing....\n");


timeBeginPeriod(1);
/*tries to get 1ms time readings
WinNT defaults to 5ms or more depending on mashine*/

startTime=currentTime=timeGetTime();

do
{
lastTime=currentTime;
Sleep(1);
currentTime=timeGetTime();

diffTime=currentTime-lastTime;
/*gives "scan" time
this calculation will work when the timer wraps*/

hits[(diffTime>maxTime)?maxTime:diffTime]++;
}
while (currentTime-startTime<180000);
/*run for 3 minutes
this calculation will work when the timer wraps*/

timeEndPeriod(1);


for (i=0;i<=maxTime;i++)
if (hits)
printf("%4d:%8d\n",i,hits);

return 0;

}


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

>1. Does any one need every scan to be sub 20 msec?
No the needs will vary in a really wide range, some barely accepting 1ms and some accepting everything less than 500ms

>2. Is it a problem if the scan time varies between scans for a fixed
>logic programme.
In some applications - yes
I have seen examples where any scantime (less than 1s) would make no difference at all, other examples would have missed sensors a long time ago with that rate. If one particular scan is long, and in just that scan is a sensor missed or any other fast response needed - then that scan was too long and probably totally unacceptable. A low average and little difference all scans will be fast enough. A low average and much
difference some scans will be too long, if chance makes one of the too long ones one who neede to be short it is unacceptable - and by the way - chance will make it happen - eventually.

>3. Is an average scan time what everybody is talking about.
Se above


----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Dave West wrote:
>result.8: result is 0.029992 msec/scan
>result.9: result is 0.032282 msec/scan
>
>###########
>
>Now I know this is a very simple test but I think it shows some
>interesting things.
>
>1. An average scan time of sub 1 msec is easilly achievable.
>2. Overall run times vary dramatically.
>
>Now correct me if I'm wrong here but:
>
>Our PLC code can and will run in sub 1 msec (based on used processor
>time).

First of all, thank you for giving us some real data to mull over. If I read this correctly, this data came from the average loop time though a simple loop for 21 processes running for 10 seconds. I don't think that this would come
very close to modeling the code involved in a PLC logic engine for even the most simple of ladder logic. Was other activity was going on when the data was gathered (disk serial port, network, other apps)? This data differs so far from the info previously posted from some others who are familiar with the real time extensions that we need to put things in context. I would question whether this test alone is enough to justify abandoning the use of real time extensions, although we may come to that conclusion anyway for a mix of reasons.

>1. Does any one need every scan to be sub 20 msec?
>2. Is it a problem if the scan time varies between scans for a fixed
>logic programme.
>3. Is an average scan time what everybody is talking about.

Most applications can deal quite well with a lot of jitter in scan time. But this is relative. If the scan is say 20 msecs +/- 10 msecs it likely will not matter (real PLCs have scan times that vary a lot too). But if it is 20 msecs -10/+200 msecs due to disk activity or something it can be a real problem for many applications. Average scan time is important but so is range. I can't immediately recall any PLCs that I've used that didn't give max scan time as well as the current scan time.

Alan Locke
Controls Engineer, Boeing

"My opinions are my own and not necessarily those of my employer"


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, 21 Jan 2000 [email protected] wrote:

> >1. Does any one need every scan to be sub 20 msec?
> No the needs will vary in a really wide range, some barely accepting
> 1ms and some accepting everything less than 500ms
>
> >2. Is it a problem if the scan time varies between scans for a fixed
> >logic programme.
> In some applications - yes
> I have seen examples where any scantime (less than 1s) would make
> no difference at all, other examples would have missed sensors
> a long time ago with that rate.
> If one particular scan is long, and in just that scan is a sensor
> missed or any other fast response needed - then that scan was too
> long and probably totally unacceptable. A low average and little
> difference all scans will be fast enough. A low average and much
> difference some scans will be too long, if chance makes one of the
> too long ones one who neede to be short it is unacceptable - and
> by the way - chance will make it happen - eventually.
>
> >3. Is an average scan time what everybody is talking about.
> Se above

Good responses.

Ok, guys we need to build in some good profiling functions as well so end users can check all aspects of scan times and optimise code or buy a
faster processor as required.


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, 21 Jan 2000, Alan Locke wrote:

> Dave West wrote:
> >result.8: result is 0.029992 msec/scan
> >result.9: result is 0.032282 msec/scan
> >
> >###########
> >
> >Now I know this is a very simple test but I think it shows some interesting things.
> >
> >1. An average scan time of sub 1 msec is easilly achievable.
> >2. Overall run times vary dramatically.
> >
> >Now correct me if I'm wrong here but:
> >
> >Our PLC code can and will run in sub 1 msec (based on used processor time).
>
> First of all, thank you for giving us some real data to mull over. <clip>

As you can see there was disk and screen activity. As for system load well not vast but reasonable. I used the same box I use for everything. There was also internet traffic in progress. The box is a Pentium 133 with 64
Meg. As far as modelling a PLC logic engine is concerned that was not the entire point. The point was to demonstrate that we can execute a scan loop without rescheduling and definately sub 5 msec. Most people seem to believe that we will reschedule after each scan. That is not neccessarilly the case. If you like you could say it was an attempt to bait the RT experts into explaining the basic workings of the scheduler correctly (I'm still trying :cool: ).

We will only have a decent model of the PLC engine when we have the real thing.

As you said the data differs vastly from that stated by the RT guys which proves they are not telling us the whole story in a way most of us can
understand it (I understand it, just want to make sure others do and I'm not the one to explain it as I'm not an expert and may cause more
confusion).

This test was never meant to justify abandoning RT at all. In fact I firmly believe it is absolutely neccessary to use it. Just not in version 1.0 especially considering it is painfully obvious that few people understand what it means (yet).

>
> >1. Does any one need every scan to be sub 20 msec?
> >2. Is it a problem if the scan time varies between scans for a fixed logic programme.
> >3. Is an average scan time what everybody is talking about.
>
> Most applications can deal quite well with a lot of jitter in scan time. But
> this is relative. If the scan is say 20 msecs +/- 10 msecs it likely will not
> matter (real PLCs have scan times that vary a lot too). But if it is
> 20 msecs -10/+200 msecs due to disk activity or something it can
> be a real problem for many applications. Average scan time is important but so
> is range. I can't immediately recall any PLCs that I've used that didn't give
> max scan time as well as the current scan time.

Agreed massive variations in scan time (+200 msec) will be a problem for almost all applications but can we reduce it without RT? Yes we can. The maximum scan time is calculable (roughly, give or take the odd I/O driver) as:
T = x + (n - 1) * 10 msec

where:
x is the time taken to execute our code once for one scan (sub 20 usec).
n is the number of processes on the system.

Thus if we remove all un-neccessary processes from the system we should be able to get a scan time sub 1 msec.

Next you will say what about disk cahce flushes? Well, all disk activity is down to a minimum by design and if we call sync() at the end of every
scan it becomes very close to a constant that may take us to sub 5 msec scans.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 06:48:23 2000 Dave West wrote...
>
>As you can see there was disk and screen activity. As for system load well
>not vast but reasonable. I used the same box I use for everything. There
>was also internet traffic in progress. The box is a Pentium 133 with 64 Meg.
>As far as modelling a PLC logic engine is concerned that was not the
>entire point. The point was to demonstrate that we can execute a scan loop
>without rescheduling and definately sub 5 msec. Most people seem to
>believe that we will reschedule after each scan. That is not neccessarilly
>the case. If you like you could say it was an attempt to bait the RT
>experts into explaining the basic workings of the scheduler correctly (I'm
>still trying :cool: ).
>
>We will only have a decent model of the PLC engine when we have the real thing.
>
>As you said the data differs vastly from that stated by the RT guys which
>proves they are not telling us the whole story in a way most of us can
>understand it (I understand it, just want to make sure others do and I'm
>not the one to explain it as I'm not an expert and may cause more confusion).
>
>This test was never meant to justify abandoning RT at all. In fact I
>firmly believe it is absolutely neccessary to use it. Just not in version
>1.0 especially considering it is painfully obvious that few people understand what it means (yet).
>

Dave, I have to chime in to support you on this. I feel that you have proven that we can build a beta test version, that will allow us to
prove convincingly to many people that for many applications we do not need the real time extensions.

I have been reading the write ups on KURT, and it appears that we can design the system the way we originally intended without forgoing the ability to use at least that form of real time extension in a latter version, or as a build time option.

I strongly advocate moving forward in this direction.

I think it's time to start putting together a design spec. What do others think?


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

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