<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I would like to second the notion that a real time kernel would be the best option for this distro. I hate to be a pessimist, but I don't see the point of making a music spin if it is going to have the same kernel as the the standard fedora distro. Anyone can add packages, but a working rt kernel is special. Also, if the real time kernel gets added, I think it may receive more attention and maybe get some nice improvements. If we have to call it a remix and not spin, that is not important to me. What is important is how useful it is to musicians and musicians do not like latency. I understand that the kernel patch can be installed quite easily and this is just my opinion. Please feel free to object to me or to correct me. :) <br><br>> From: music-request@lists.fedoraproject.org<br>> Subject: music Digest, Vol 44, Issue 13<br>> To: music@lists.fedoraproject.org<br>> Date: Thu, 22 Jul 2010 06:20:00 +0000<br>> <br>> Send music mailing list submissions to<br>> music@lists.fedoraproject.org<br>> <br>> To subscribe or unsubscribe via the World Wide Web, visit<br>> https://admin.fedoraproject.org/mailman/listinfo/music<br>> or, via email, send a message with subject or body 'help' to<br>> music-request@lists.fedoraproject.org<br>> <br>> You can reach the person managing the list at<br>> music-owner@lists.fedoraproject.org<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of music digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>> 1. Re: Music spin development - are you ready to get involved ?<br>> (Fernando Lopez-Lezcano)<br>> 2. Re: [PlanetCCRMA] Music Spin (Fernando Lopez-Lezcano)<br>> 3. Re: [PlanetCCRMA] Music Spin (Bernardo Barros)<br>> 4. Re: Music spin development - are you ready to get involved ?<br>> (Bernardo Barros)<br>> 5. Re: Music spin development - are you ready to get involved ?<br>> (Christopher Antila)<br>> 6. Re: [PlanetCCRMA] Music Spin (Fernando Lopez-Lezcano)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Wed, 21 Jul 2010 10:13:14 -0700<br>> From: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU><br>> Subject: Re: [Fedora-music-list] Music spin development - are you<br>> ready to get involved ?<br>> To: David Timms <dtimms@iinet.net.au><br>> Cc: music@lists.fedoraproject.org<br>> Message-ID: <1279732394.22338.2.camel@localhost.localdomain><br>> Content-Type: text/plain; charset="UTF-8"<br>> <br>> On Thu, 2010-07-22 at 01:19 +1000, David Timms wrote:<br>> > Hi all,<br>> > <br>> > I have begun a wiki page to help track our goals for an audio creation<br>> > Fedora spin:<br>> > https://fedoraproject.org/wiki/AudioCreationSpinDevelopment<br>> > , also available from the links at the bottom of the SIG page:<br>> > https://fedoraproject.org/wiki/Audio_Creation<br>> > <br>> > If you want to be involved, please make sure you have a Fedora wiki<br>> > account (fas), and list yourself in the collaborators section.<br>> > <br>> > You'll probably find many areas of the page need flashing out or fixing<br>> > up; please do so, but also consider the limited time frame before the<br>> > next Fedora release.<br>> > <br>> > A name like "Open Music Workstation" ... or "Fedora Jam", but you can<br>> > think of better, I'm sure...<br>> > <br>> > Meanwhile, as we are trying to show off collaboration, is there any<br>> > software that allows distant users to jam / create music over the<br>> > internet ? This would be something really quite unique, compared to<br>> > other spins.<br>> <br>> Jacktrip, already part of Planet CCRMA, see:<br>> https://ccrma.stanford.edu/groups/soundwire/<br>> <br>> and in particular:<br>> http://code.google.com/p/jacktrip/<br>> <br>> -- Fernando<br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 2<br>> Date: Wed, 21 Jul 2010 10:21:55 -0700<br>> From: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU><br>> Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin<br>> To: David Sommerseth <davids@redhat.com><br>> Cc: music@lists.fedoraproject.org<br>> Message-ID: <1279732915.22338.11.camel@localhost.localdomain><br>> Content-Type: text/plain; charset="UTF-8"<br>> <br>> On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote:<br>> > -----BEGIN PGP SIGNED MESSAGE-----<br>> > Hash: SHA1<br>> > <br>> > On 19/07/10 18:57, Fernando Lopez-Lezcano wrote:<br>> > > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote:<br>> > >> > For this low-level task some engineering would be required? I'm not<br>> > >> > this kind of guy who know much about tasks scheduling and priorities<br>> > >> > (kernel level) but some people told me that real-time kernels patches<br>> > >> > could slow down Fedora and I should not use it. <br>> > ><br>> > > Did those people by any chance provide you with _numbers_ that tell you<br>> > > exactly what part of the kernel is impacted and by how much? (and, who<br>> > > are they?) My guess is probably not. <br>> > > <br>> > > Yes, perhaps the rt patches could affect performance. Maybe. In some<br>> > > subsystems (disk i/o, network come to mind). Maybe by a few %, in some<br>> > > specific situations. I don't think the impact will be something you will<br>> > > notice unless you measure it. <br>> > <br>> > To put things a bit straight. Yes, RT kernel will affect performance.<br>> > Point.<br>> <br>> Agreed (for the reasons you explain below). <br>> <br>> I'd like to add that in the context of real-time performance for audio,<br>> the lack of an RT kernel will also affect performance for the worse. So,<br>> it depends on your goals. In the context of this list (music) Bernardo<br>> comments he got the recommendation to not run RT kernels for performance<br>> reasons ("some people told me that real-time kernels patches could slow<br>> down Fedora and I should not use it"). <br>> <br>> If you are running a server, don't (unless, of course, you print money<br>> by running thousands of trades a minute and you need millisecond<br>> scheduling for that - that is why we have the rt patches after all :-).<br>> If you are running a music oriented workstation that should handle<br>> real-time interaction, then I'd say yes, run it. <br>> <br>> There are no black and white rules here. If you try the Fedora kernel<br>> and it works for you in your particular music oriented situation then<br>> run that. <br>> <br>> -- Fernando<br>> <br>> <br>> > Will you notice it effectively on "normal desktop tasks"? Probably not<br>> > much, but it depends on how your system is saturated, tuned and what<br>> > kind of loads you have running. Real Time is not Real Fast and never<br>> > will be. A real time kernel will not give any fair scheduling to your<br>> > system, basically.<br>> <br>> (depends on your definition of "fair", for the purposes of an RT kernel<br>> it schedules processes fairly, giving the rt tasks priority as is<br>> intended by design). <br>> <br>> > All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR<br>> > scheduling, even on the lowest priority will preempt and run it first<br>> > over, ignoring all other SCHED_OTHER (normal) processes. SCHED_FIFO and<br>> > SCHED_RR tasks with the highest priority will be processed before all<br>> > other tasks, whenever they receive signals which requires these<br>> > processes to run. This is the core nature of a real time system.<br>> > <br>> > So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they<br>> > are light - you most probably will not notice anything at all. But in<br>> > the moment you begin with heavy I/O dependent operations or other<br>> > operations which requires processing time and the kernel have given them<br>> > SCHED_FIFO scheduling and a rather high priority (which is not<br>> > uncommon), it will slow down all the other running tasks. But this<br>> > behaviour is possible to tune!<br>> > <br>> > So why would you want to run a real time kernel instead of a so called<br>> > "real fast" kernel (normal kernels)? Latency determination. A real<br>> > time kernel will strive to give you a predictable system latency, no<br>> > matter how loaded your computer is. Which is a key-point for audio and<br>> > video - you don't want the sound or video stream to be delayed because<br>> > cron and updatedb wants to run.<br>> > <br>> > Some relevant information can be found here:<br>> > <br>> > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html><br>> > <br>> > <br>> > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html><br>> > <br>> > <br>> > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html><br>> > <br>> > <br>> > kind regards,<br>> > <br>> > David Sommerseth<br>> > -----BEGIN PGP SIGNATURE-----<br>> > Version: GnuPG v1.4.10 (GNU/Linux)<br>> > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/<br>> > <br>> > iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d<br>> > mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/<br>> > =vj0G<br>> > -----END PGP SIGNATURE-----<br>> > _______________________________________________<br>> > music mailing list<br>> > music@lists.fedoraproject.org<br>> > https://admin.fedoraproject.org/mailman/listinfo/music<br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 3<br>> Date: Wed, 21 Jul 2010 15:18:16 -0300<br>> From: Bernardo Barros <bernardobarros2@gmail.com><br>> Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin<br>> To: Fernando Lopez-Lezcano <nando@ccrma.stanford.edu><br>> Cc: music@lists.fedoraproject.org<br>> Message-ID:<br>> <AANLkTilHaP29jI3NnWHELlcH0rUPxzkbmBADvgq_3EkF@mail.gmail.com><br>> Content-Type: text/plain; charset=UTF-8<br>> <br>> Thank you Fernando and David,<br>> <br>> Yes, the person that gave me advise was not an audio oriented guy.<br>> That?s more clear now.<br>> <br>> Just a newbie question here: do you have to determine what programs<br>> will have privileges? How the system knows how to handle taks of audio<br>> and non-audio programs at the same time?<br>> <br>> 2010/7/21 Fernando Lopez-Lezcano <nando@ccrma.stanford.edu>:<br>> > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote:<br>> >> -----BEGIN PGP SIGNED MESSAGE-----<br>> >> Hash: SHA1<br>> >><br>> >> On 19/07/10 18:57, Fernando Lopez-Lezcano wrote:<br>> >> > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote:<br>> >> >> > For this low-level task some engineering would be required? I'm not<br>> >> >> > this kind of guy who know much about tasks scheduling and priorities<br>> >> >> > (kernel level) but some people told me that real-time kernels patches<br>> >> >> > could slow down Fedora and I should not use it.<br>> >> ><br>> >> > Did those people by any chance provide you with _numbers_ that tell you<br>> >> > exactly what part of the kernel is impacted and by how much? (and, who<br>> >> > are they?) My guess is probably not.<br>> >> ><br>> >> > Yes, perhaps the rt patches could affect performance. Maybe. In some<br>> >> > subsystems (disk i/o, network come to mind). Maybe by a few %, in some<br>> >> > specific situations. I don't think the impact will be something you will<br>> >> > notice unless you measure it.<br>> >><br>> >> To put things a bit straight. ?Yes, RT kernel will affect performance.<br>> >> Point.<br>> ><br>> > Agreed (for the reasons you explain below).<br>> ><br>> > I'd like to add that in the context of real-time performance for audio,<br>> > the lack of an RT kernel will also affect performance for the worse. So,<br>> > it depends on your goals. In the context of this list (music) Bernardo<br>> > comments he got the recommendation to not run RT kernels for performance<br>> > reasons ("some people told me that real-time kernels patches could slow<br>> > down Fedora and I should not use it").<br>> ><br>> > If you are running a server, don't (unless, of course, you print money<br>> > by running thousands of trades a minute and you need millisecond<br>> > scheduling for that - that is why we have the rt patches after all :-).<br>> > If you are running a music oriented workstation that should handle<br>> > real-time interaction, then I'd say yes, run it.<br>> ><br>> > There are no black and white rules here. If you try the Fedora kernel<br>> > and it works for you in your particular music oriented situation then<br>> > run that.<br>> ><br>> > -- Fernando<br>> ><br>> ><br>> >> Will you notice it effectively on "normal desktop tasks"? ?Probably not<br>> >> much, but it depends on how your system is saturated, tuned and what<br>> >> kind of loads you have running. ?Real Time is not Real Fast and never<br>> >> will be. ?A real time kernel will not give any fair scheduling to your<br>> >> system, basically.<br>> ><br>> > (depends on your definition of "fair", for the purposes of an RT kernel<br>> > it schedules processes fairly, giving the rt tasks priority as is<br>> > intended by design).<br>> ><br>> >> All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR<br>> >> scheduling, even on the lowest priority will preempt and run it first<br>> >> over, ignoring all other SCHED_OTHER (normal) processes. ?SCHED_FIFO and<br>> >> SCHED_RR tasks with the highest priority will be processed before all<br>> >> other tasks, whenever they receive signals which requires these<br>> >> processes to run. ?This is the core nature of a real time system.<br>> >><br>> >> So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they<br>> >> are light - you most probably will not notice anything at all. ?But in<br>> >> the moment you begin with heavy I/O dependent operations or other<br>> >> operations which requires processing time and the kernel have given them<br>> >> SCHED_FIFO scheduling and a rather high priority (which is not<br>> >> uncommon), it will slow down all the other running tasks. ?But this<br>> >> behaviour is possible to tune!<br>> >><br>> >> So why would you want to run a real time kernel instead of a so called<br>> >> "real fast" kernel (normal kernels)? ?Latency determination. ?A real<br>> >> time kernel will strive to give you a predictable system latency, no<br>> >> matter how loaded your computer is. ?Which is a key-point for audio and<br>> >> video - you don't want the sound or video stream to be delayed because<br>> >> cron and updatedb wants to run.<br>> >><br>> >> Some relevant information can be found here:<br>> >><br>> >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html><br>> >><br>> >><br>> >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html><br>> >><br>> >><br>> >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html><br>> >><br>> >><br>> >> kind regards,<br>> >><br>> >> David Sommerseth<br>> >> -----BEGIN PGP SIGNATURE-----<br>> >> Version: GnuPG v1.4.10 (GNU/Linux)<br>> >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/<br>> >><br>> >> iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d<br>> >> mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/<br>> >> =vj0G<br>> >> -----END PGP SIGNATURE-----<br>> >> _______________________________________________<br>> >> music mailing list<br>> >> music@lists.fedoraproject.org<br>> >> https://admin.fedoraproject.org/mailman/listinfo/music<br>> ><br>> ><br>> ><br>> <br>> <br>> ------------------------------<br>> <br>> Message: 4<br>> Date: Wed, 21 Jul 2010 15:20:50 -0300<br>> From: Bernardo Barros <bernardobarros2@gmail.com><br>> Subject: Re: [Fedora-music-list] Music spin development - are you<br>> ready to get involved ?<br>> To: David Timms <dtimms@iinet.net.au><br>> Cc: music@lists.fedoraproject.org<br>> Message-ID:<br>> <AANLkTik2UTrKoyXjUv7GPmMkqg1CcCNCZGAFrmFtvt0D@mail.gmail.com><br>> Content-Type: text/plain; charset=UTF-8<br>> <br>> 2010/7/21 David Timms <dtimms@iinet.net.au>:<br>> > A name like "Open Music Workstation" ... or "Fedora Jam", but you can<br>> > think of better, I'm sure...<br>> <br>> My suggestion is "Planet Music" Spin as an hommenage to the work of<br>> Fernando to the Linux Audio community.<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 5<br>> Date: Wed, 21 Jul 2010 20:16:20 -0400<br>> From: Christopher Antila <crantila@gmail.com><br>> Subject: Re: [Fedora-music-list] Music spin development - are you<br>> ready to get involved ?<br>> To: music@lists.fedoraproject.org<br>> Message-ID: <4C478DD4.9010509@fedoraproject.org><br>> Content-Type: text/plain; charset=ISO-8859-1<br>> <br>> Hello:<br>> <br>> Thanks to David for getting this started for us. I was going to post a<br>> (nearly empty) wiki page for this purpose today, but it's better that a<br>> more experienced user does it.<br>> <br>> I'll be adding my comments to the wiki pages as appropriate, and I<br>> everybody else joins in, too.<br>> <br>> Also, I don't want to be beating people over the head with this, but the<br>> Docs SIG is publishing a Guide for music and audio software with Fedora<br>> 14. We'll have to see exactly how these fit together, but remember that<br>> the Guide will be there.<br>> <br>> Finally, since I'm in fairly regular contact with Docs, I'll take<br>> responsibility for maintaining the Audio Creation <-> Docs link, if the<br>> Spin goes ahead. First step is to ask if we can add a "beat" in the<br>> Release Notes ("What's new in Fedora 14 for Musicians?" or something<br>> like that). If you don't know what this is, check out the Fedora 13<br>> release notes... it would probably fall under chapter 7:<br>> <br>> http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.html<br>> <br>> <br>> Let's get this thing rolling!<br>> <br>> Christopher.<br>> <br>> <br>> On 07/21/2010 11:19 AM, David Timms wrote:<br>> > Hi all,<br>> > <br>> > I have begun a wiki page to help track our goals for an audio creation<br>> > Fedora spin:<br>> > https://fedoraproject.org/wiki/AudioCreationSpinDevelopment<br>> > , also available from the links at the bottom of the SIG page:<br>> > https://fedoraproject.org/wiki/Audio_Creation<br>> > <br>> > If you want to be involved, please make sure you have a Fedora wiki<br>> > account (fas), and list yourself in the collaborators section.<br>> > <br>> > You'll probably find many areas of the page need flashing out or fixing<br>> > up; please do so, but also consider the limited time frame before the<br>> > next Fedora release.<br>> > <br>> > A name like "Open Music Workstation" ... or "Fedora Jam", but you can<br>> > think of better, I'm sure...<br>> > <br>> > Meanwhile, as we are trying to show off collaboration, is there any<br>> > software that allows distant users to jam / create music over the<br>> > internet ? This would be something really quite unique, compared to<br>> > other spins.<br>> > <br>> > Cheers, David.<br>> > _______________________________________________<br>> > music mailing list<br>> > music@lists.fedoraproject.org<br>> > https://admin.fedoraproject.org/mailman/listinfo/music<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 6<br>> Date: Wed, 21 Jul 2010 23:19:31 -0700<br>> From: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU><br>> Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin<br>> To: Bernardo Barros <bernardobarros2@gmail.com><br>> Cc: music@lists.fedoraproject.org<br>> Message-ID: <1279779571.25375.245.camel@localhost.localdomain><br>> Content-Type: text/plain; charset="UTF-8"<br>> <br>> On Wed, 2010-07-21 at 15:18 -0300, Bernardo Barros wrote:<br>> > Thank you Fernando and David,<br>> > <br>> > Yes, the person that gave me advise was not an audio oriented guy.<br>> > That?s more clear now.<br>> > <br>> > Just a newbie question here: do you have to determine what programs<br>> > will have privileges? How the system knows how to handle taks of audio<br>> > and non-audio programs at the same time?<br>> <br>> You don't have to worry about determining which programs will have<br>> privileges (at least directly). <br>> <br>> If you run Jack with real-time scheduling (if you use Qjackctl you have<br>> to set the "Realtime" parameter in "Setup" and the user that is running<br>> Jack has to be allowed to use real-time scheduling), then the audio<br>> threads within any Jack client will run with real-time scheduling<br>> automatically. <br>> <br>> All other threads in all your programs will run with "normal" scheduling<br>> and will have less priority (that includes, for example, graphic i/o<br>> threads or file i/o threads in the Jack audio programs - those don't<br>> have elevated priority). <br>> <br>> It is all designed to make sure the chances of an audio glitch happening<br>> are as small as possible. <br>> <br>> -- Fernando<br>> <br>> <br>> > 2010/7/21 Fernando Lopez-Lezcano <nando@ccrma.stanford.edu>:<br>> > > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote:<br>> > >> -----BEGIN PGP SIGNED MESSAGE-----<br>> > >> Hash: SHA1<br>> > >><br>> > >> On 19/07/10 18:57, Fernando Lopez-Lezcano wrote:<br>> > >> > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote:<br>> > >> >> > For this low-level task some engineering would be required? I'm not<br>> > >> >> > this kind of guy who know much about tasks scheduling and priorities<br>> > >> >> > (kernel level) but some people told me that real-time kernels patches<br>> > >> >> > could slow down Fedora and I should not use it.<br>> > >> ><br>> > >> > Did those people by any chance provide you with _numbers_ that tell you<br>> > >> > exactly what part of the kernel is impacted and by how much? (and, who<br>> > >> > are they?) My guess is probably not.<br>> > >> ><br>> > >> > Yes, perhaps the rt patches could affect performance. Maybe. In some<br>> > >> > subsystems (disk i/o, network come to mind). Maybe by a few %, in some<br>> > >> > specific situations. I don't think the impact will be something you will<br>> > >> > notice unless you measure it.<br>> > >><br>> > >> To put things a bit straight. Yes, RT kernel will affect performance.<br>> > >> Point.<br>> > ><br>> > > Agreed (for the reasons you explain below).<br>> > ><br>> > > I'd like to add that in the context of real-time performance for audio,<br>> > > the lack of an RT kernel will also affect performance for the worse. So,<br>> > > it depends on your goals. In the context of this list (music) Bernardo<br>> > > comments he got the recommendation to not run RT kernels for performance<br>> > > reasons ("some people told me that real-time kernels patches could slow<br>> > > down Fedora and I should not use it").<br>> > ><br>> > > If you are running a server, don't (unless, of course, you print money<br>> > > by running thousands of trades a minute and you need millisecond<br>> > > scheduling for that - that is why we have the rt patches after all :-).<br>> > > If you are running a music oriented workstation that should handle<br>> > > real-time interaction, then I'd say yes, run it.<br>> > ><br>> > > There are no black and white rules here. If you try the Fedora kernel<br>> > > and it works for you in your particular music oriented situation then<br>> > > run that.<br>> > ><br>> > > -- Fernando<br>> > ><br>> > ><br>> > >> Will you notice it effectively on "normal desktop tasks"? Probably not<br>> > >> much, but it depends on how your system is saturated, tuned and what<br>> > >> kind of loads you have running. Real Time is not Real Fast and never<br>> > >> will be. A real time kernel will not give any fair scheduling to your<br>> > >> system, basically.<br>> > ><br>> > > (depends on your definition of "fair", for the purposes of an RT kernel<br>> > > it schedules processes fairly, giving the rt tasks priority as is<br>> > > intended by design).<br>> > ><br>> > >> All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR<br>> > >> scheduling, even on the lowest priority will preempt and run it first<br>> > >> over, ignoring all other SCHED_OTHER (normal) processes. SCHED_FIFO and<br>> > >> SCHED_RR tasks with the highest priority will be processed before all<br>> > >> other tasks, whenever they receive signals which requires these<br>> > >> processes to run. This is the core nature of a real time system.<br>> > >><br>> > >> So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they<br>> > >> are light - you most probably will not notice anything at all. But in<br>> > >> the moment you begin with heavy I/O dependent operations or other<br>> > >> operations which requires processing time and the kernel have given them<br>> > >> SCHED_FIFO scheduling and a rather high priority (which is not<br>> > >> uncommon), it will slow down all the other running tasks. But this<br>> > >> behaviour is possible to tune!<br>> > >><br>> > >> So why would you want to run a real time kernel instead of a so called<br>> > >> "real fast" kernel (normal kernels)? Latency determination. A real<br>> > >> time kernel will strive to give you a predictable system latency, no<br>> > >> matter how loaded your computer is. Which is a key-point for audio and<br>> > >> video - you don't want the sound or video stream to be delayed because<br>> > >> cron and updatedb wants to run.<br>> > >><br>> > >> Some relevant information can be found here:<br>> > >><br>> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html><br>> > >><br>> > >><br>> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html><br>> > >><br>> > >><br>> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html><br>> > >><br>> > >><br>> > >> kind regards,<br>> > >><br>> > >> David Sommerseth<br>> > >> -----BEGIN PGP SIGNATURE-----<br>> > >> Version: GnuPG v1.4.10 (GNU/Linux)<br>> > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/<br>> > >><br>> > >> iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d<br>> > >> mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/<br>> > >> =vj0G<br>> > >> -----END PGP SIGNATURE-----<br>> > >> _______________________________________________<br>> > >> music mailing list<br>> > >> music@lists.fedoraproject.org<br>> > >> https://admin.fedoraproject.org/mailman/listinfo/music<br>> > ><br>> > ><br>> > ><br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> _______________________________________________<br>> music mailing list<br>> music@lists.fedoraproject.org<br>> https://admin.fedoraproject.org/mailman/listinfo/music<br>> <br>> End of music Digest, Vol 44, Issue 13<br>> *************************************<br> <br /><hr />Get a free e-mail account with Hotmail. <a href='http://clk.atdmt.com/UKM/go/197222280/direct/01/' target='_new'>Sign-up now.</a></body>
</html>