--- Chuck Swiger <[EMAIL PROTECTED]> wrote:
> On May 23, 2008, at 6:37 PM, Unga wrote:
> > 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?
>
> Sure. To generalize, the traditional scheduler goal
> for Unix has been
> to maximize overall throughput and avoid starvation
> of even low-
> priority tasks, at the expense of higher and
> unpredictable latency.
> Using realtime priority means that the kernel is
> told to minimize
> latency for that process even if it means starving
> other processes of
> CPU time.
>
> That is well suited for things like CD/DVD burning
> or audio/visual
> capture, but as you've experienced yourself, it does
> poorly for
> heavily client-server oriented stuff like X11's
> architecture.
>
> > I wonder the issue I mentioned, open a pdf while
> playback audio, is
> > it a issue on Apple Mac OSX?
>
> Nope. :-)
>
> > 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?
>
>
> While both FreeBSD and MacOS X are general-purpose
> operating systems,
> doing multimedia creation and playback is among the
> primary
> functionality goals for MacOS X, in much the same
> way that FreeBSD
> regards providing "robust network services" like
> Apache, DNS, email,
> databases and so forth.
>
> Core Audio is probably the biggest user of realtime
> thread scheduling
> under MacOS X, followed by QuickTime or DVD playback
> over Core Video.
> These frameworks were designed to handle multimedia
> without skipping
> by preallocating sensible amounts of buffer space,
> and they take
> advantage of the Mach kernel and IOKit drivers which
> are intended to
> support realtime needs. Unlike the traditional BSD
> kernels, the Mach
> kernel was originally designed with SMP, soft & hard
> realtime
> scheduling in the kernel. The original userland
> threads library which
> came with Mach, called CThreads, was largely
> responsible for the
> design that was abstracted into the portable POSIX
> threads model
> widely used today.
>
> After FreeBSD 4, there has been a tremendous amount
> of work in the
> kernel on fine-grained locking and moving device
> drivers from running
> in the non-preemptable interrupt context to having
> device kernel
> threads which can be preempted, and there has also
> been a lot of work
> on the userland side to improve the C threading
> libraries and to
> improve multithreaded malloc() performance via
> jemalloc, but this is
> still ongoing and higher level applications like X11
> programs haven't
> had years to adapt and take advantage of these
> changes.
>
> Simple things like auto-tuning the size of the audio
> buffers to avoid
> or minimize skipping or dropouts isn't really in
> place yet with
> FreeBSD. Realtime video on FreeBSD is dependent
> upon X11, which was
> originally designed by a bunch of guys at MIT to be
> able to display
> lots of xterms or other things involving simple
> blits of bits,
> possibly over the network, in order to replace the
> Andrew window
> manager system used by CMU, MIT, IBM, and a few
> others. X11 wasn't
> designed to do alpha channel (aka transparency),
> much less stream a
> couple of hundred MB per second of data for realtime
> OpenGL texturing
> or video. (Although, Composite and GLX have since
> been added to X11,
> they are extensions rather than core functionality,
> and hardware
> driver support for GLX is less than perfectly
> available, especially
> once you start looking at the AMD64/EM64T platform,
> rather than 32-bit
> x86....)
>
> There's a 2002 BSDcon paper here, written around the
> time of FreeBSD
> 5.x's release, which has more details:
>
>
http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/
>
Thank you very much for the detailed info.
It seems FreeBSD may need two schedulers, one for
desktop and one for server, among other things.
Kind regards
Unga
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
