P
I don't necessarily think that this is bad news. As a minimum, if the kernel was patched with UTIME, we could schedule processes with usec
resolution. UTIME is a patch to Linux that increases the temporal granularity of the software clock from its normal 10ms.
The normal linux kernel only checks its list of pending events at each timer interrupt, and therefore, the length of time between interrupts ( a jiffy = 10ms ) is the smallest unit of time with which events can be scheduled. Even if you set your process to be scheduled to SCHED_FIFO (where it gets scheduled in preference to other processes) your process will only get scheduled every 20 ms or so and this will degrade with system loading.
RTLinux is hard real time but you don't have the benefit of the Linux kernel's services. You can communicate to Linux user processes through
FIFOs or shared memory (4MB max that exists outside of the memory that Linux can use for processes). If you want to use Linux's network services, then your driver can't be a RTLinux module. RTLinux is great for driving stepper
motors from the parallel port, as an example. This is what I use it for now.
KU Real Time Linux (KURT) uses UTIME along with providing additional scheduling modes such as SCHED_KURT where KURT real time processes are only
allow to run and SCHED_ALL_PROCS where all processes are allowed to run. All of the Linux kernel's services are available to KURT processes including networking.
If you want to twiddle your I/O down in the usec range and can live without the Linux kernel's services then RTLinux is the only way to go. If you can live with 1 - 10 ms range and need the services of the Linux kernel then KURT is a good choice. If 10 - 30ms is OK then UTIME patch is all you need. The normal Linux kernel will probably be good for 30+ ms range with performance degrading with system load and disk access.
If the LinuxPLC is going to support RTLinux then there are some serious considerations that need to be addressed right now.
Phil Covington
vHMI
----- Original Message -----
From: "Stan Brown" <[email protected]>
> On Mon Jan 17 19:16:29 2000 Phil Covington wrote...
> >
> >From: "Stan Brown" <[email protected]>
> >
> >> On Mon Jan 17 13:08:00 2000 wrote...
> >> >
> >> >In a message dated 1/17/00 9:06:14 AM Pacific Standard Time,
> >[email protected]
> >> >writes:
> >> >> >
> >> >> >My guess is that this approach would be acceptable for the vast majority of
> >> >> >applications. For the few that it is not, we need some way to write the data
> >> >> >table into a faster storage medium (like battery backed RAM) on the fly.
> >> >> >This should not be too difficult to implement.
> >> >>
> >> >> I don't think we can do this, and achieve the speed of scan required for
> >> >> this project to be viable in many applications.
> >> >>
> >> >A couple observations/questions.
> >> >
> >> >1. How fast does the scan need to be to be viable in most applications?
> >100 msec? I'd guess the overwhelming majority of PLC applications do not require
> >> >much more then this.
> >>
> >> Very few of my PLC projects would work with a scan time this slow. Most
> >> I work on require at least a 35MS (faster is better) scan time.
> >>
> >And hence the need for a real time extension to Linux! Linux jiffie resolution is 10ms...
> >If you want scan times under 20-30 ms then you'd better get used to the idea of RTL
> >or KURT or at least a UTIME patch to normal Linux.
>
> Bummer. This is bad news.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
resolution. UTIME is a patch to Linux that increases the temporal granularity of the software clock from its normal 10ms.
The normal linux kernel only checks its list of pending events at each timer interrupt, and therefore, the length of time between interrupts ( a jiffy = 10ms ) is the smallest unit of time with which events can be scheduled. Even if you set your process to be scheduled to SCHED_FIFO (where it gets scheduled in preference to other processes) your process will only get scheduled every 20 ms or so and this will degrade with system loading.
RTLinux is hard real time but you don't have the benefit of the Linux kernel's services. You can communicate to Linux user processes through
FIFOs or shared memory (4MB max that exists outside of the memory that Linux can use for processes). If you want to use Linux's network services, then your driver can't be a RTLinux module. RTLinux is great for driving stepper
motors from the parallel port, as an example. This is what I use it for now.
KU Real Time Linux (KURT) uses UTIME along with providing additional scheduling modes such as SCHED_KURT where KURT real time processes are only
allow to run and SCHED_ALL_PROCS where all processes are allowed to run. All of the Linux kernel's services are available to KURT processes including networking.
If you want to twiddle your I/O down in the usec range and can live without the Linux kernel's services then RTLinux is the only way to go. If you can live with 1 - 10 ms range and need the services of the Linux kernel then KURT is a good choice. If 10 - 30ms is OK then UTIME patch is all you need. The normal Linux kernel will probably be good for 30+ ms range with performance degrading with system load and disk access.
If the LinuxPLC is going to support RTLinux then there are some serious considerations that need to be addressed right now.
Phil Covington
vHMI
----- Original Message -----
From: "Stan Brown" <[email protected]>
> On Mon Jan 17 19:16:29 2000 Phil Covington wrote...
> >
> >From: "Stan Brown" <[email protected]>
> >
> >> On Mon Jan 17 13:08:00 2000 wrote...
> >> >
> >> >In a message dated 1/17/00 9:06:14 AM Pacific Standard Time,
> >[email protected]
> >> >writes:
> >> >> >
> >> >> >My guess is that this approach would be acceptable for the vast majority of
> >> >> >applications. For the few that it is not, we need some way to write the data
> >> >> >table into a faster storage medium (like battery backed RAM) on the fly.
> >> >> >This should not be too difficult to implement.
> >> >>
> >> >> I don't think we can do this, and achieve the speed of scan required for
> >> >> this project to be viable in many applications.
> >> >>
> >> >A couple observations/questions.
> >> >
> >> >1. How fast does the scan need to be to be viable in most applications?
> >100 msec? I'd guess the overwhelming majority of PLC applications do not require
> >> >much more then this.
> >>
> >> Very few of my PLC projects would work with a scan time this slow. Most
> >> I work on require at least a 35MS (faster is better) scan time.
> >>
> >And hence the need for a real time extension to Linux! Linux jiffie resolution is 10ms...
> >If you want scan times under 20-30 ms then you'd better get used to the idea of RTL
> >or KURT or at least a UTIME patch to normal Linux.
>
> Bummer. This is bad news.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc