On Friday 07 December 2007, Roger Oberholtzer wrote:

On Thu, 2007-12-06 at 23:15 +0200, Andrei Verovski (aka MacGuru) wrote:

...

Hi !

SuSE people have supplied real-time kernel with distro. I have 2 questions:

Is this supplied with 10.3? Or from SUSE's web site? I would like to have a look as well. Where are you looking?

-- Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden

Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696

Hi, In website, it appears in update site as kernel-rt. Thadeu -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Roger Oberholtzer writes:

I looked at the contents and it seemed it is installed parallel to the standard kernel. But maybe I missed something. Can this be installed along with the standard kernel and simply be selected at boot?

Yes, install it with rpm -ihv to choose at boottime.

There are docs that describe what is usually in the rt_preempt kernels, as well as comparisons. But I agree that it would be nice to know which ones were applied to the kernel-rt in the SUSE distro.

Check the kernel-source SRC rpm, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Friday 07 December 2007 06:23, Andreas Jaeger wrote:

"Andrei Verovski (aka MacGuru)" writes:

...

Hi !

SuSE people have supplied real-time kernel with distro. I have 2 questions:

1) What specific patches/modules (i.e. CFS scheduler) has this kernel compared to default one "kernel-default-2.6.22-xx"?

Look at the kernel-source src package for all of them. The kernel-rt contains the CFS scheduler.

...

2) If I am need kernel for router/firewall (which also handles VoIP), is this real-time kernel a favorite choice?

I don't think so.

...

3) Does this real-time kernel has any advantage if used in heavy-loaded desktop workstation?

Editing and Playing of sound might be one reason - but the normal kernel has been improved already for the usual desktop cases,

Andreas

Out of curiosity, is 1 - the config file included with the source, or 2 - what _makes_ an "rt" kernel in comparison to the "normal" kernel? Thanks Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 11 December 2007 19:57, Carlos E. R. wrote:

The Tuesday 2007-12-11 at 18:56 -0500, Carl Luescher wrote:

...

Out of curiosity, is 1 - the config file included with the source, or

Yes.

/usr/src/linux/arch/i386/defconfig.rt /usr/src/linux/arch/i386/defconfig.rt_debug

...

2 - what _makes_ an "rt" kernel in comparison to the "normal" kernel?

diff -y --suppress-common-lines /usr/src/linux/arch/i386/defconfig.rt /usr/src/linux/arch/i386/defconfig.default | less -S

What it does exactly, I dunno.

-- Cheers, Carlos E. R.

Well, with the given information it will be up to me to figure out, or maybe not. I _do_ appreciate your information. I refuse to be too old to learn. Thanks Carlos! Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, Dec 12, 2007 at 01:57:09AM +0100, Carlos E. R. wrote:

The Tuesday 2007-12-11 at 18:56 -0500, Carl Luescher wrote:

...

Out of curiosity, is 1 - the config file included with the source, or

Yes.

/usr/src/linux/arch/i386/defconfig.rt /usr/src/linux/arch/i386/defconfig.rt_debug

...

2 - what _makes_ an "rt" kernel in comparison to the "normal" kernel?

diff -y --suppress-common-lines /usr/src/linux/arch/i386/defconfig.rt /usr/src/linux/arch/i386/defconfig.default | less -S

What it does exactly, I dunno.

There are also a number of patches additionaly applied, see series.conf. It does not do anything special for the regular user, we strongly recommend to use just our "default" kernels. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carl Luescher wrote:

Carlos, explanation is close enough, makes sense, as I've been reading up on this too.

Marcus, yes, I now have to agree that for the regular, the default kernels are just fine. The rt stuff I can see as being more application specific as perhaps in the medical or aeronautics fields.

Thank you both for your enlightening inputs!

Carl

I looked into the topic for a bit, what I was "needing" the RT kernel for was audio recording/processing. Normal users can't run threads in "realtime" priority, the super user can, but then running general applications as the superuser is not really the best idea. At any rate, I guess the RT kernel has facilities for setting up a group or users that can run realtime threads. How much this affects the performance of these applications, I don't know and haven't found out. I decided that it was too much trouble right now to try out a RT kernel, especially after I finally got lm_sensors working the recent kernels for 10.3, and I prefer to hold off until/unless I see poor performance in my audio apps. --Jason -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, Dec 14, 2007 at 07:12:40PM -0000, David wrote:

On Fri, 14 Dec 2007 18:28:19 -0000, Jason Craig wrote:

...

I looked into the topic for a bit, what I was "needing" the RT kernel for was audio recording/processing. Normal users can't run threads in "realtime" priority, the super user can, but then running general applications as the superuser is not really the best idea.

Just an idea... would it be possible to re-nice the program you are using?

It seems to work fine for most audio systems right now. Realtime is only useful for people who understand what it is. ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, Dec 14, 2007 at 01:29:41PM -0600, K.R. Foley wrote:

Marcus Meissner wrote:

...

On Fri, Dec 14, 2007 at 07:12:40PM -0000, David wrote:

...

On Fri, 14 Dec 2007 18:28:19 -0000, Jason Craig wrote:

...

I looked into the topic for a bit, what I was "needing" the RT kernel for was audio recording/processing. Normal users can't run threads in "realtime" priority, the super user can, but then running general applications as the superuser is not really the best idea. Just an idea... would it be possible to re-nice the program you are using?

It seems to work fine for most audio systems right now.

Realtime is only useful for people who understand what it is. ;)

Ciao, Marcus

btw, is the opensuse RT kernel still carrying LSM? I am pretty sure it's being dropped from the RT patchset.

Yes. At least apparmor is built in ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-14 at 19:12 -0000, David wrote:

On Fri, 14 Dec 2007 18:28:19 -0000, Jason Craig wrote:

...

I looked into the topic for a bit, what I was "needing" the RT kernel for was audio recording/processing. Normal users can't run threads in "realtime" priority, the super user can, but then running general applications as the superuser is not really the best idea.

Just an idea... would it be possible to re-nice the program you are using?

There is a problem. First, it is not renice what you are looking at, but ionice - from the manual: This program sets the io scheduling class and pri‐ ority for a program. As of this writing, Linux supports 3 scheduling classes: Idle. A program running with idle io priority will only get disk time when no other program has asked for disk io for a defined grace period. The impact of idle io processes on normal system activity should be zero. This scheduling class does not take a priority argument. Best effort. This is the default scheduling class for any process that hasn't asked for a specific io priority. Programs inherit the CPU nice setting for io priorities. This class takes a priority argument from 0-7, with lower number being higher priority. Programs running at the same best effort priority are served in a round-robin fashion. Real time. The RT scheduling class is given first access to the disk, regardless of what else is going on in the system. Thus the RT class needs to be used with some care, as it can starve other processes. As with the best effort class, 8 prior‐ ity levels are defined denoting how big a time slice a given process will receive on each scheduling window. Now, you can call a program like this: ionice -c1 program args to give it realtime priority. However... ionice has to be run as root. If you call it being user, through sudo, the effective user of the child program is still root - and this is not what we want and need. The alternative method is to use "ionice -c1 -p PROGRAM_PID" instead, which can be set to be used through sudo, but you need to know the PID of the process you want to modify the priority. And if it has children, them too. But! Some programs try to detect at start if they have realtime priorities... if they are given them later by the method described, it is already to late for them, they will not use the alternative algorithms designed for that case. I believe Xine does this. So, yes, a method to give a group of programs realtime priority from the start would be interesting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHYtintTMYHG2NR9URArzoAJ9NFZwJoIK7O0dUUHLEsapvpaKo3ACfQ3qT 3EAoDpIRVnJ5KulOb1iavZ0= =YrIk -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-14 at 13:55 -0600, K.R. Foley wrote:

...

First, it is not renice what you are looking at, but ionice - from the manual:

Actually there is a renice program that sets the nice value of a program within the SCHED_OTHER scheduling policy / priority 0. You do have to be root though to decrease (increase priority) the nice value of a process, as it should be.

The program "renice" just does about the same as the program "nice", but using the PID. It just modifies the scheduling priority, but you can not change the scheduling class of a program using renice. They are different.

...

But! Some programs try to detect at start if they have realtime priorities... if they are given them later by the method described, it is already to late for them, they will not use the alternative algorithms designed for that case. I believe Xine does this.

So, yes, a method to give a group of programs realtime priority from the start would be interesting.

There is but it typically requires superuser privileges.

Ie, there is no method. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHYyBqtTMYHG2NR9URApY3AKCQaOQdxW92F+MSClqqQCdFPKIdLgCdFEOd wbpDdiGFsz+4qkHcFT6biA0= =BsbR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-14 at 22:04 +0100, Wolfgang Woehl wrote:

...

So, yes, a method to give a group of programs realtime priority from the start would be interesting.

Audio people these days use the PAM infrastructure for this, look at /etc/security/limits.conf where rtprio and memlock are relevant for audio work with jack and its clients.

Ah! Sounds interesting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHYyEQtTMYHG2NR9URAkT8AJ47oRLaz0Wtws2gOT/66xaBkKC7NACePdCi Lr+JulrrD84yqV9tF59vzaQ= =hv5i -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

I have installed the RT kernel on 10.3. Comes up as expected. I have yet to see how it will effect my data gathering applications. I also have the nvidia driver installed via YaST. When I run the RT kernel, of course the nvidia driver is not present. What is the best way to sort this out? Since I used YaST to install the nvidia driver, it should get updated when there is a new kernel. I do not want to mess that up to get it to work with the RT kernel variant. Should I just re-install the nvidia driver when running the RT kernel? I guess the RT kernel is a parallel kernel, not really a new kernel. I'm happy with any reasonable solution. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, 2007-12-19 at 09:10 -0800, Greg KH wrote:

On Wed, Dec 19, 2007 at 02:44:41PM +0100, Roger Oberholtzer wrote:

...

I have installed the RT kernel on 10.3. Comes up as expected. I have yet to see how it will effect my data gathering applications.

Then don't use it :)

I was unclear. I meant I had not evaluated it yet. In fact, we do things like get kernel signals when a photocell triggers. We want them as soon as possible, at least with a similar delay most times. We also receive network packets from data collection devices. We control measurement systems using real time DGPS locations, expecting good accuracy when the system is moving at >90 km/h. All this should arrive is our application in a decent predictable time. We run a mix of threads and SIGIO handlers. All this is working within our currently stated limits. But, as always, our users always like accuracy improvements. So, I am evaluating the RT kernel to see what it may, or may not, offer in this.

Seriously, only use the -rt kernel if you _really_ know what you are wanting it for. It will cause your machine to run slower overall, which is probably not your intention...

...

I also have the nvidia driver installed via YaST. When I run the RT kernel, of course the nvidia driver is not present. What is the best way to sort this out?

Don't use the -rt kernel, it will not work with the nvidia driver.

OK. OOC, are any of the RT kernel optimizations in macros in include files? Meaning the code must be compiled to take advantage? The normal X server is not recompiled to expect the RT kernel. Should there be similar issues with that as with the nvidia driver? Does this apply to vmware as well?

...

Since I used YaST to install the nvidia driver, it should get updated when there is a new kernel. I do not want to mess that up to get it to work with the RT kernel variant. Should I just re-install the nvidia driver when running the RT kernel? I guess the RT kernel is a parallel kernel, not really a new kernel.

What do you mean "new kernel"? It's just a different variant, one for a specific need.

If I get a kernel update, the YaST-based nvidia install claims that it will magically keep the nvidia driver working with each update. I do not need to take action. The RT kernel, I am guessing, is not considered an update, which makes sense. But it is unclear if the nvidia driver would be installed in any booted kernel where it does not already exist, or only in certain classes of kernels (updates that replace the current kernel vs. a second kernel installed in a parallel fashion and selectable via the boot menu).

again, don't use the -rt kernel unless you really know why you want to use it, and how to use it.

I am not a newbie. I am only trying to see how SUSE expected all this to work, and what parts are not expected to be used with the RT kernel. Odd that SUSE would go through all the trouble to deliver the RT kernel, and then tell folk not to use it :) I do appreciate your warnings. All this is only a test to see if we can find improvements where we would like them, and of course, that there are no regressions elsewhere. All feedback welcome. Some even acted on :) -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, 2007-12-19 at 23:45 -0800, Greg KH wrote:

...

The normal X server is not recompiled to expect the RT kernel.

That's because it is not a kernel driver, yet :)

Of course. My mistake.

...

Should there be similar issues with that as with the nvidia driver?

Yes there will be.

...

Does this apply to vmware as well?

Yes.

_ANY_ kernel module will have to be recompiled to work properly with the -rt kernel, just like any other kernel version we provide.

Sigh.. I need to make a second class of our own drivers.

...

...

...

Since I used YaST to install the nvidia driver, it should get updated when there is a new kernel. I do not want to mess that up to get it to work with the RT kernel variant. Should I just re-install the nvidia driver when running the RT kernel? I guess the RT kernel is a parallel kernel, not really a new kernel.

What do you mean "new kernel"? It's just a different variant, one for a specific need.

If I get a kernel update, the YaST-based nvidia install claims that it will magically keep the nvidia driver working with each update.

That's a pretty bold claim :)

Indeed. But the SUSE nvidia driver install docs claim this is the case.

Anyway, as the nvidia driver is closed source, I really have no idea how it interacts with the kernel at all. Heck, the fact that it even works for anyone is amazing to me...

...

I do not need to take action. The RT kernel, I am guessing, is not considered an update, which makes sense.

That's right, it is just another kernel "variant" like the -bigsmp kernel is.

So did the nvidia driver not get installed into the RT kernel on purpose (it was not fully recompiled with -rt stuff) or by oversight? The end result may be what you want. But it would be nice if it was for the right reason. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

...

So did the nvidia driver not get installed into the RT kernel on purpose (it was not fully recompiled with -rt stuff) or by oversight? The end result may be what you want. But it would be nice if it was for the right reason.

Probably by oversight, or the fact that nvidia didn't realize we had a -rt kernel? Who really knows, nvidia does this, not SuSE, we have no insight with what they do because of the closed-source-not-able-to-be-maintained-as-they-are-infringing-on-the-kernel-copyright type thing...

The 10.3 -rt kernel is also changing its exported symbols in nearly every update. Good luck. In general no one should use the -rt kernel except if he really knows how to use it. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-20 at 13:44 -0500, Ed McCanless wrote:

...

Good luck.

In general no one should use the -rt kernel except if he really knows how to use it.

How would one know how, without ever trying?

Right. It should thus get more documented ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHasGrtTMYHG2NR9URAtIuAJ95Hv/nvEMYuf5bKwHWmI7zYdAhowCghVA5 xQL5n4d8ScZiXr9OZ/fjUHA= =H2f1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, Dec 21, 2007 at 08:26:31AM +0100, Roger Oberholtzer wrote:

On Thu, 2007-12-20 at 19:13 +0100, Marcus Meissner wrote:

...

The 10.3 -rt kernel is also changing its exported symbols in nearly every update.

Are the symbols different than the ones by the non -RT kernel with the exact same number?

Yes. The patchset is quite massive against the regular 10.3 kernel. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, Dec 21, 2007 at 08:23:47AM +0100, Roger Oberholtzer wrote:

On Thu, 2007-12-20 at 09:34 -0800, Greg KH wrote:

...

Any reason your drivers are not already in the mainline kernel? If you need help getting them there, the linuxdriverproject.org people are more than willing to help you out.

One is a 'stupid' driver that replaces the serial port driver for a specified serial port, implementing a photocell sensor that time tags the port interrupt and does an asynchronous message (seen in the user's app via select/poll/SIGIO). I would not imagine anyone would be interested in it.

{sigh} We (the kernel.org community) are interested in _every_ driver out there, even if it only has 1 user. Heck, we have whole subarchitectures with only 3 users, and that is much more intrusive than a driver. See my 2006 OLS talk for more details about this: http://www.kroah.com/log/linux/ols_2006_keynote.html

One other driver, the bttv driver, already has our changes in the mainline. We hired a bttv developer to make the changes, In that case, it was a v4l2 feature that was defined in the API but was not present in the bttv driver. It is now. Before the changes made it into the kernel, we had to make a local compile and provide it. In 10.3 that is no longer needed.

Good to hear.

The other drivers are from special cards we use. One driver is not ours. We have the source because we use the cards. It is a multi-port realtime jpeg2000 compression/decompression card. Which has primarily Linux support. Perhaps the developer of that card is interested in this.

That sounds interesting to others, it should also go in :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thu, 2007-12-20 at 09:13 +0100, Roger Oberholtzer wrote:

On Wed, 2007-12-19 at 23:45 -0800, Greg KH wrote:

...

...

The normal X server is not recompiled to expect the RT kernel.

That's because it is not a kernel driver, yet :)

Of course. My mistake.

...

...

Should there be similar issues with that as with the nvidia driver?

Yes there will be.

...

Does this apply to vmware as well?

Yes.

_ANY_ kernel module will have to be recompiled to work properly with the -rt kernel, just like any other kernel version we provide.

Sigh.. I need to make a second class of our own drivers.

...

...

...

...

Since I used YaST to install the nvidia driver, it should get updated when there is a new kernel. I do not want to mess that up to get it to work with the RT kernel variant. Should I just re-install the nvidia driver when running the RT kernel? I guess the RT kernel is a parallel kernel, not really a new kernel.

What do you mean "new kernel"? It's just a different variant, one for a specific need.

If I get a kernel update, the YaST-based nvidia install claims that it will magically keep the nvidia driver working with each update.

That's a pretty bold claim :)

Indeed. But the SUSE nvidia driver install docs claim this is the case.

...

Anyway, as the nvidia driver is closed source, I really have no idea how it interacts with the kernel at all. Heck, the fact that it even works for anyone is amazing to me...

...

I do not need to take action. The RT kernel, I am guessing, is not considered an update, which makes sense.

That's right, it is just another kernel "variant" like the -bigsmp kernel is.

So did the nvidia driver not get installed into the RT kernel on purpose (it was not fully recompiled with -rt stuff) or by oversight? The end result may be what you want. But it would be nice if it was for the right reason.

-- Roger Oberholtzer

Hi, Many years ago i used a RT-os, But when seeing you asking for videodrivers and vmware...... For real RT-applications, you should want to avoid unneeded IRQ's at all time: barebone, no graphics (but serial console), no virtualisation, no add-on hardware and as much as possible unneeded io on your mobo disabled. hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-20 at 19:16 -0000, Kevin Donnelly wrote:

Well, as Wolfgang has already pointed out, there is a whole class of audio stuff that is crying out for an RT kernel - the one Jacklab did for 10.2 is quite good, and setting one up for Debian/Ubuntu is reasonably simple too (or you can use dedicated distros like Daniel James' estimable 64Studio). This area has been developing rapidly over the last 18 months, and I tend to agree with Wolfgang that Novell/openSUSE is missing a trick (ie influential market segment) here, especially given the excellent packaging work on audio apps already being done by Tony Graffy and others on Packman. For audio work, you certainly need a graphics system, and there may be a need for some add-on hardware too :-) (and certainly a decent audio card).

Some one said that audio was well handled in the desktop nowdays. I don't agree. An example that happened to me today: I have a cronjob that spells out the current time every half hour, using "festival". Well, I was browsing the net, clicked somewhere, the hour started to say: "December 20..." then it was cut to silence, the web page updated, and finally the voice continued "... 15:30". Surely, sound is, should be, a high priority task and should never be interrupted by another task - although I don't know how festival is programmed. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHasN6tTMYHG2NR9URAqNdAJ9MxCYBEsyxyoaqwhsgdNwKKYAqiACdHO3R L0iVcyIK7JtEZVH9+AqBsSk= =jIpe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-20 at 18:41 +0100, Hans Witvliet wrote:

Many years ago i used a RT-os, But when seeing you asking for videodrivers and vmware......

For real RT-applications, you should want to avoid unneeded IRQ's at all time: barebone, no graphics (but serial console), no virtualisation, no add-on hardware and as much as possible unneeded io on your mobo disabled.

Depends on the application. If the app is a map showing the real position read from a gps on a car traveling at a reasonable speed, you need video. And if a piece of hardware or software needed for this app doesn't work in linux, you need virtualization too. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHasGbtTMYHG2NR9URAoCmAJ99ryTi8Mn9CYo/NJQ5ZEGx2KNPGwCfW7Pw ggQwusV08vZ5PCPmSlTn2F4= =N8co -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thu, 2007-12-20 at 23:54 +0100, Wolfgang Woehl wrote:

Donnerstag, 20. Dezember 2007 Hans Witvliet:

...

Many years ago i used a RT-os, But when seeing you asking for videodrivers and vmware......

For real RT-applications, you should want to avoid unneeded IRQ's at all time: barebone, no graphics (but serial console), no virtualisation, no add-on hardware and as much as possible unneeded io on your mobo disabled.

On linux kernels you can sort and prioritize IRQ's. They're called "Interrupt requests" for a reason.

If the realtime infrastructure is up and healthy then there's really no reason for your realtime applications to not deliver -- no matter what is going on on your desktop.

Well, the rt-application could suck, for that matter. Multiple rt-action might drain ressources. Hell, the metal could run hot :) And I don't know about hardware level virtualization and its effects on irq handling.

Wolfgang

ps: What was the OS/application you were using?

Yes, well, i have to agree with the O.P. Some applications do need a graphical interface, But to use vmware on a rt-machine because the hardware is not supported by linux.... Well, i don't know. Probably it is not possible to seperate these functions into a seperate box.. For what i was using R.T.? The OS was (a cloned) mtos, and was used for frequency analysis (dtmf and dialtone recognition) for telefone exchanges, back in 85. hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Freitag, 21. Dezember 2007 Hans Witvliet:

It's not that rt-applications suck and leave no reources for "the rest", but the other way round.

I meant "suck" like in "fail to do what they're supposed to". Like in "not rt-safe". Plus what you say is wrong at least on linux. If the realtime framework is setup right top priority (realtime) tasks get to deliver. The rest just has to wait. So you might see sluggish "desktop" response. This works on a range of hardware, not only on certified metal.

Multiple rt-actions (often re-entrant) shouldn't cause any problems. However, if you drain the available resources by non-rt-hardware, or used closed-source virtualisation, there might come a point where you can no longer prove that your application will always respond within the given time. This might cause distorted audio/video, or even loose a customer-contract.

The whole point of running an audio plumber like jack realtime is to *not* get distorted audio, even under very tight conditions like low latency. And it works. Like I said: no matter what else you run on your desktop.

btw, it/s not without a reason that the developpers from asterisk seriously discourage the use of a X-environment on a pabx.

So they're not making use of the available realtime mechanisms, I'd suspect. So they "suck". Just kidding :) I'd suspect they use some balancing techniques on their systems to get stuff done more or less in time. If they were using the realtime framework they could be pretty sure. Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org