sched_ule performance on single CPU

[Unga]

--- Oliver Fromme <olli at lurza.secnetix.de> wrote:

> Unga <unga888 at yahoo.com> wrote:
>  > Idle-prio process which generates lot of I/O is
>  > understandable.
>  > 
>  > But when you either record or playback audio as
>  > realtime-prio and you opened up a pdf document as
>  > normal-prio, can the pdf rendering in normal-prio
>  > breaks down the realtime audio process? I don't
> think
>  > pdf rendering is I/O intensive.
> 
> I think it can.
> 
> Opening a PDF causes quite a lot of I/O.  The viewer
> application has to be paged in from disk, all the
> libraries and configuration files it uses, possibly
> even parts of the X server have to be paged in,
> depending on what features of the X protocol and
> which extensions the viewer application uses.
> And of course the PDF itself has to be loaded (which
> might be not small), and finally all fonts used by
> the PDF have to be loaded by the viewer application.
> 
> On the other hand, the default buffer space of the
> audio driver is quite small (the reason for that is
> to reduce latency for sound effects in games).  So
> even a very short I/O congestion can cause an
> audible
> hiccup in audio playback or recording.
> 
>  > Using a faster processor or multi-core may solve
> this
>  > problem,
> 
> No, faster I/O hardware will solve it, or hardware
> that better supports concurrent access.  It's also
> quite possible that improvements in FreeBSD's disk
> system might solve the problem, i.e. by reordering
> disk access in a more efficient manner, but this is
> very non-trivial.  But all of that is not a matter
> of the process scheduler.
> 
> Anotehr solution is to use more aggressive buffering
> by either the audio application or the audio driver.
> The latter can be set via sysctl. The former is a
> matter of your audio application.
> 
> I use mpg123 for mp3 playback on a 3-year old UP
> machine.  It has a buffer option which I use.
> E.g. "mpg123 -b5000" will use 5 MB buffer; that's
> enough for half a minute of audio.  I do not use
> renice, idprio, rtprio or anything, but still
> audio playback works perfectly fine, even during
> a buildworld.  Or when opening a PDF.  No hiccups.
> 

Noted your points.

When open an pdf has two types of scenarios in
FreeBSD:
1. When X run as a realtime-prio process, X go mad and
swallow up almost all of CPU cycles, making audio
hiccups. 

2. When X run as a normal-prio process, X behaves well
and rarely gets an audible hiccup.

Why X behave different under different priority
categories? Isn't this scheduler related?

I wonder the issue I mentioned, open a pdf while
playback audio, is it a issue on Apple Mac OSX? Could
somebody give some light here who uses an Apple Mac
OSX on this list?

If it is not an issue in Mac OSX, how they have
overcome it then?

Kind regards
Unga