On Mon, Jan 24, 2011 at 1:42 PM, Shaffin Bhanji
Correct, the use of RT has its purpose, most of
(1) Predictable response time from the cpu
(2) The priority schedule queue
(3) Guaranteed CPU response time within 10ms
The use of this very apparent in applications such as hardware devices
in motion control systems. The ability to receive a hardware response
from a CPU in a predictable manner to control a robotic device - a
requirement for a RT stack.
On Mon, Jan 24, 2011 at 9:33 AM, Roger Oberholtzer <roger(a)opq.se> wrote:
> On Mon, 2011-01-24 at 14:44 +0100, Bogdan Cristea wrote:
>> Well, you should see how it is in Windows :)
>> By real-time I meant soft-real time.
> I shudder to think of doing what I am doing in Windows. The event queues
> there are perhaps the text book definition of non-deterministic! On
> Linux we use a combination of async I/O (and real time signals) and
> blocking threads. The response time is quite good - and predictable. For
> example, we have a test setup where we want to determine the delay from
> when a serial port line triggers and when our application runs. It is
> for testing a photocell that fiddles with a RS-232 status line to
> indicate when it fires. So we have a device driver that records in the
> serial port interrupt handler when it triggered, and that can make that
> time available to the user app as well. We also added a bit of test code
> that allows us to do an ioctl() to the driver that will toggle said line
> via the PC's parallel port, recording relevant times as well.
> Timing the first part of our loop (time when we triggered the event via
> the parallel port and when out serial interrupt handle runs:
> >>> Serial port interrupt generated at 1265631153.933622 secs
> <<< Serial port interrupt received at 1265631153.933629 secs
> It is consistently very close to 0.000007 seconds, no matter what we are
> up to in the desktop. Of course, this is a hardware interrupt. Remember
> that the serial port hardware has it's own response time. But that is
> also consistent.
I'm not too familiar with the -RT kernel, but I believe one of its
primary goals is to ensure interrupts are not disabled for too long at
a time. So if the above consistency is important to your app, I
suggest you at least re-familiarize yourself with the -rt kernel and
see if it would not be more appropriate for your system.
I'm sure there are lots of resources, but asking on the kernelnewbies
mailing list is one place you can go. I don't know if you have to
subscribe to post on that one or not.
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse+help(a)opensuse.org