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
>
>
>
_______________________________________________
music mailing list
music@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/music
