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