[opensuse] OpenSuse RT Kernel?
Hello, I am looking for a RT kernel and was wondering whether OpenSuse proves a RT kernel stack? Shaffin. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
search with "kernel-rt" in opensuse search Or go to http://www.osadl.org/ and patch the vanilla kernel. On Sun, Jan 23, 2011 at 8:21 PM, Shaffin Bhanji <shaffin.bhanji@gmail.com> wrote:
Hello,
I am looking for a RT kernel and was wondering whether OpenSuse proves a RT kernel stack?
Shaffin.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- Bogdan Cristea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 01/23/2011 02:21 PM, Shaffin Bhanji pecked at the keyboard and wrote:
Hello,
I am looking for a RT kernel and was wondering whether OpenSuse proves a RT kernel stack?
Shaffin.
Yes it does. zypper se kernel-rt Loading repository data... Reading installed packages... S | Name | Summary | Type --+-----------------------+---------------------------------------------------------+-------- | kernel-rt | The Real-Time Linux Kernel | package | kernel-rt-devel | Development files necessary for building kernel modules | package | kernel-rt_debug | The Linux Kernel | package | kernel-rt_debug-devel | Development files necessary for building kernel modules | package | kernel-rt_trace | The Linux Kernel | package | kernel-rt_trace-devel | Development files necessary for building kernel modules | package -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2011-01-23 at 15:35 -0500, Ken Schneider - openSUSE wrote:
On 01/23/2011 02:21 PM, Shaffin Bhanji pecked at the keyboard and wrote:
Hello,
I am looking for a RT kernel and was wondering whether OpenSuse proves a RT kernel stack?
I am curious what the advantage of the -rt kernel is. I seem to recall when it was first available, the general reaction was that it might help in some usage scenarios - but in most uses it would not really improve over the standard kernel. Is this still the consensus? Or has the -rt kernel progresses in recent times? 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
On Mon, 24 Jan 2011 13:25:13 +0530, Roger Oberholtzer <roger@opq.se> wrote:
On Sun, 2011-01-23 at 15:35 -0500, Ken Schneider - openSUSE wrote:
On 01/23/2011 02:21 PM, Shaffin Bhanji pecked at the keyboard and wrote:
Hello,
I am looking for a RT kernel and was wondering whether OpenSuse proves a RT kernel stack?
I am curious what the advantage of the -rt kernel is. I seem to recall when it was first available, the general reaction was that it might help in some usage scenarios - but in most uses it would not really improve over the standard kernel. Is this still the consensus? Or has the -rt kernel progresses in recent times?
my understanding is that it's needed for certain applications, like real-time audio recording / editing, that don't function well if they get only a slice of the kernel's attention, but that for general purpose it's not as good as desktop or default (server) flavors. can't remember where i picked up this info and would be interested to get my understanding corrected or confirmed... -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday, January 24, 2011 02:00:46 pm phanisvara das wrote:
I am curious what the advantage of the -rt kernel is. I seem to recall when it was first available, the general reaction was that it might help in some usage scenarios - but in most uses it would not really improve over the standard kernel. Is this still the consensus? Or has the -rt kernel progresses in recent times?
my understanding is that it's needed for certain applications, like real-time audio recording / editing, that don't function well if they get only a slice of the kernel's attention, but that for general purpose it's not as good as desktop or default (server) flavors. can't remember where i picked up this info and would be interested to get my understanding corrected or confirmed...
Another reason might be that one needs to develop real-time apps using a full desktop computer, especially in research laboratories (e.g. data acquisition) -- Bogdan Cristea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-01-24 at 14:03 +0100, Bogdan Cristea wrote:
On Monday, January 24, 2011 02:00:46 pm phanisvara das wrote:
I am curious what the advantage of the -rt kernel is. I seem to recall when it was first available, the general reaction was that it might help in some usage scenarios - but in most uses it would not really improve over the standard kernel. Is this still the consensus? Or has the -rt kernel progresses in recent times?
my understanding is that it's needed for certain applications, like real-time audio recording / editing, that don't function well if they get only a slice of the kernel's attention, but that for general purpose it's not as good as desktop or default (server) flavors. can't remember where i picked up this info and would be interested to get my understanding corrected or confirmed...
Another reason might be that one needs to develop real-time apps using a full desktop computer, especially in research laboratories (e.g. data acquisition)
I do exactly this. Lots of devices. I think that the linux-rt kernel is in no way a true real time kernel. Meaning with absolute and consistent delays between events and when they can be handled by interested agents. I recall that this RT kernel was targeted to stock trading companies that felt a fraction of a second delay meant potential loss because actions (buy sell whatever) did not happen as close to the calculation time as possible. I never did see why a rt kernel solved that and not perhaps better calculation methods and generally faster computers. I am sure there was some good reason. So, the question remains: what does the openSUSE -rt kernel bring to the table? 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
On Monday, January 24, 2011 02:40:25 pm Roger Oberholtzer wrote:
I do exactly this. Lots of devices. I think that the linux-rt kernel is in no way a true real time kernel. Meaning with absolute and consistent delays between events and when they can be handled by interested agents. I recall that this RT kernel was targeted to stock trading companies that felt a fraction of a second delay meant potential loss because actions (buy sell whatever) did not happen as close to the calculation time as possible. I never did see why a rt kernel solved that and not perhaps better calculation methods and generally faster computers. I am sure there was some good reason.
So, the question remains: what does the openSUSE -rt kernel bring to the table?
Well, you should see how it is in Windows :) By real-time I meant soft-real time. -- Bogdan Cristea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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
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
On Mon, Jan 24, 2011 at 1:42 PM, Shaffin Bhanji <shaffin.bhanji@gmail.com> wrote:
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.
Roger, 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. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Could you please honour common netiquette and post with a line length of less than 75 characters? Tahnk you. On Mon, 24 Jan 2011 18:30:46 +0530, "phanisvara das" <listmail@phanisvara.com> wrote:
my understanding is that it's needed for certain applications, like real-time audio recording / editing, that don't function well if they get only a slice of the kernel's attention, but that for general purpose it's not as good as desktop or default (server) flavors.
Audio recording needs low latencies but *not* real-time. The most prominent applications for real-time are computer controlled manufacturing and automatic trading systems for investment banking, i.e. where you need guaranteed response times. But as that limits I/O and thus throughput it's not what you want on either server or desktop. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 25 Jan 2011 05:16:12 +0530, Philipp Thomas <Philipp.Thomas2@gmx.net> wrote:
Audio recording needs low latencies but *not* real-time. The most prominent applications for real-time are computer controlled manufacturing and automatic trading systems for investment banking, i.e. where you need guaranteed response times. But as that limits I/O and thus throughput it's not what you want on either server or desktop.
thank you; one misunderstanding more cleared up. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011. 01. 25., Tuesday 00:46:12 Philipp Thomas wrote:
Could you please honour common netiquette and post with a line length of less than 75 characters? Tahnk you.
On Mon, 24 Jan 2011 18:30:46 +0530, "phanisvara das"
<listmail@phanisvara.com> wrote:
my understanding is that it's needed for certain applications, like real-time audio recording / editing, that don't function well if they get only a slice of the kernel's attention, but that for general purpose it's not as good as desktop or default (server) flavors.
Audio recording needs low latencies but *not* real-time. The most
I would challenge this statement. If you have only basic needs then you will probably be fine with the desktop kernel. But if you are serious about recording and editing audio then you definitely need the real time kernel. Btw, according to http://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit : "The scheduling requirements of JACK to achieve sufficiently low latencies have been one of the driving forces behind the real-time optimization effort for the current Linux 2.6 kernel series,[5][6] whose initial latency performance had been disappointing compared to the older 2.4 series."
prominent applications for real-time are computer controlled manufacturing and automatic trading systems for investment banking, i.e. where you need guaranteed response times. But as that limits I/O and thus throughput it's not what you want on either server or desktop.
Philipp
Tom -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 25 Jan 2011 10:15:28 +0100, benefici@fastmail.fm wrote:
On 2011. 01. 25., Tuesday 00:46:12 Philipp Thomas wrote:
Audio recording needs low latencies but *not* real-time. The most
I would challenge this statement.
This you say,
"The scheduling requirements of JACK to achieve sufficiently low latencies
And in the first sentence of your quote you state exactly what I wrote :) Low latency is not the same as realtime, specially hard realtime. And in the future please honour common nettiquette by only quoting the part which you reply to. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011. 01. 25., Tuesday 11:36:21 Philipp Thomas wrote:
On Tue, 25 Jan 2011 10:15:28 +0100, benefici@fastmail.fm wrote:
On 2011. 01. 25., Tuesday 00:46:12 Philipp Thomas wrote:
Audio recording needs low latencies but *not* real-time. The most
I would challenge this statement.
This you say,
"The scheduling requirements of JACK to achieve sufficiently low latencies
And in the first sentence of your quote you state exactly what I wrote
:) Low latency is not the same as realtime, specially hard realtime. And in the future please honour common nettiquette by only quoting the part which you reply to.
But still, keep all relevant parts when you reply :). In this case, the original sentence was not that JACK only needs low latencies (in general) but that JACK was a major reason why the rt kernel was needed and developed. In audio editing, you need _guaranteed_ low latencies because you might want to process the recorded sounds (use effects), mix them with the original and also play them back to the musicians while recording. Without this guarantee you may have a fast system (with low average latencies) but not a real time system. Therefore, you either go for low latency, set small buffers and risk buffer overflows, or you choose high latency and you don't have professional audio anymore. Tom -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (8)
-
benefici＠fastmail.fm -
Bogdan Cristea -
Greg Freemyer -
Ken Schneider - openSUSE -
phanisvara das -
Philipp Thomas -
Roger Oberholtzer -
Shaffin Bhanji