Correct, the use of RT has its purpose, most of which: (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. Shaffin. On Mon, Jan 24, 2011 at 9:33 AM, Roger Oberholtzer <roger@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.
The next step of getting this interrupt into our running application is perhaps less deterministic. Which is why we time tag things where it makes sense to do so. But it is usually quite consistent and fast. I have been wanting to try systems with the '200 line kernel patch' to see what that does for things. It is on my list. But as I do not really have any issues without that change, I am not sure what difference I would see.
Yours sincerely,
Roger Oberholtzer
OPQ Systems / Ramböll RST
Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________
Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org