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
