*** 7.0-RELEASE/src/sys/conf/NOTES	Mon May 19 14:35:14 2008
--- new-generic/src/sys/conf/NOTES	Mon May 26 18:51:02 2008
***************
*** 185,190 ****
--- 185,252 ----
  # and scheduler locks.  It also has a stronger notion of interactivity 
  # which leads to better responsiveness even on uniprocessor machines.  This
  # will eventually become the default scheduler.
+ ## 
+ ## From: Chuck Swiger <cswiger@@mac.com>
+ ## Date: Sat, 24 May 2008 12:58:15 -0700 (21:58 CEST)
+ ## {
+ ## 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.
+ ## 
+ ## 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/
+ ## }
+ 
  #
  options 	SCHED_4BSD
  #options 	SCHED_ULE