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
