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/
Regards,
--
-Chuck
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
