<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
hello everyone,<br><br>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. <br>That's all I have for now. Until next time, ciao!<br><br> (tertl3)<br><br>> From: music-request@lists.fedoraproject.org<br>> Subject: music Digest, Vol 44, Issue 14<br>> To: music@lists.fedoraproject.org<br>> Date: Fri, 23 Jul 2010 14:57:06 +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 Digest, Vol 44, Issue 13 (William Blackburn)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Fri, 23 Jul 2010 15:57:03 +0100<br>> From: William Blackburn <bill_-@hotmail.com><br>> Subject: Re: [Fedora-music-list] music Digest, Vol 44, Issue 13<br>> To: <music@lists.fedoraproject.org><br>> Message-ID: <SNT133-w47CF783E49056989D7B0EAB6A30@phx.gbl><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> <br>> 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>> _________________________________________________________________<br>> http://clk.atdmt.com/UKM/go/197222280/direct/01/<br>> Do you have a story that started on Hotmail? Tell us now<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: http://lists.fedoraproject.org/pipermail/music/attachments/20100723/497e4f99/attachment.html <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 14<br>> *************************************<br>                                            <br /><hr />Get a new e-mail account with Hotmail - Free. <a href='http://clk.atdmt.com/UKM/go/197222280/direct/01/' target='_new'>Sign-up now.</a></body>
</html>