Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Scheduler Available for FreeBSD

Posted by Nik on from the doesn't-blink-LEDs-when-switching-processes dept.

flynn_nrg writes "Luigi Rizzo, one of the FreeBSD developers, has just finished the code for a new scheduler. From the announcement: '...as promised, a first version of the Proportional Share scheduler that we developed is available here. These are for a recent -STABLE (i think any version from 4.4 should work; the only 3 files modified are kern_synch.c, kern_switch.c and proc.h, plus a one-line change to kern_exit.c). I have tested it a little bit on a diskless system, and it seems to survive running a full X session with the usual set of xterm, netscape etc. while i do a "renice" of the processes and even switch back and forth between schedulers. But do not trust this yet for a production system!' Read the full post here."

49 of 232 comments (clear)

  1. uniprocessor only. by Anonymous Coward · · Score: 2, Interesting

    what the hell happenned to developing SMP and UP capable schedulers ? or does BSD expect to run well on only UP systems ?

    1. Re:uniprocessor only. by m0rten · · Score: 2, Informative

      The scheduler is far from finished, and would likely need a lot more work. Integrating it into 5.0-CURRENT (and bringing in the SMP support along with it) is already under way, but could probably take some time.

  2. Okay, now please tell me... by RinkSpringer · · Score: 2, Interesting

    Why does this get on the main page, and why does the new Core Team does not?

    Either way, FreeBSD does fit the new trend now... more VM's means more freedom :)

    1. Re:Okay, now please tell me... by Z4rd0Z · · Score: 2

      Except this isn't a new VM.

      --
      You had me at "dicks fuck assholes".
  3. No clue what Proportional Share Scheduling is? by arnoroefs2000 · · Score: 5, Informative

    There's more info here.

    Excerpt:

    "There are compelling reasons to use proportional share scheduling techniques to support multimedia and other soft real-time applications on general-purpose operating systems. First, proportional share (PS) schedulers are a good match for existing infrastructure such as a periodic timer interrupt and mechanisms for assigning priorities to applications -- priorities can be mapped to shares in a proportional-share environment. Second, PS schedulers provide stronger guarantees to applications than do traditional time-sharing schedulers: they allocate a specific fraction of the CPU to each thread, and some schedulers provide error bounds on the allocation rate. Third, PS schedulers have clear semantics during underload: excess CPU time is allocated fairly, in contrast with some reservation-based schedulers that must idle or back off to a secondary scheduling policy once all application budgets are exhausted."

    1. Re:No clue what Proportional Share Scheduling is? by ewhac · · Score: 2

      Sounds vaguely similar to how BeOS's scheduler worked internally.

      Schwab

      --
      Editor, A1-AAA AmeriCaptions
  4. Re:Why? by Anonymous Coward · · Score: 3, Informative

    "There are compelling reasons to use proportional share scheduling techniques to support multimedia and other soft real-time applications on general-purpose operating systems. First, proportional share (PS) schedulers are a good match for existing infrastructure such as a periodic timer interrupt and mechanisms for assigning priorities to applications -- priorities can be mapped to shares in a proportional-share environment. Second, PS schedulers provide stronger guarantees to applications than do traditional time-sharing schedulers: they allocate a specific fraction of the CPU to each thread, and some schedulers provide error bounds on the allocation rate. Third, PS schedulers have clear semantics during underload: excess CPU time is allocated fairly, in contrast with some reservation-based schedulers that must idle or back off to a secondary scheduling policy once all application budgets are exhausted."

  5. Re:Low Latency, Pre-Emptive multitasking? by Subcarrier · · Score: 4, Informative

    Don't forget Linux will soon have a new scheduler, too. The O(1) scheduler by Ingo Molnar kicks some serious ass, especially with SMP.

    --
    "I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
  6. Re:KARMA WHORE !!!! by Buck2 · · Score: 2, Funny

    You're so cute when you do that.

    --

    As my father lik@(munch munch)... ....
  7. 0(1) scheduler by Sivar · · Score: 5, Informative

    Is FreeBSD's new one a 0(1) scheduler?
    0(1) is a "term" from computer science. When applied to schedulers, it basically means that no matter how many processes there are to schedule, a 0(1) scheduler's overhead will not significantly increase.
    Of course, with a small number of threads/processes to schedule, the Linux 0(1) scheduler will have greater initial overhead. It isn't until there are quite a few processes that it starts to show its power, and the more processes there are, the more useful it is.
    On a busy server with 4+ processors and thousands of processes, a standard scheduler's overhead is so great that it often exceeds the overhead of most of the individual server processes.

    --
    Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    1. Re:0(1) scheduler by Osty · · Score: 3, Informative

      Is FreeBSD's new one a 0(1) scheduler?

      Just a nitpick. The term is "O(1)", not "0(1)", as in "Big Oh of 1" and not "Zero of 1".

    2. Re:0(1) scheduler by Sivar · · Score: 2

      Yes, I used the number "zero" (0) and not the letter "O" :)

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    3. Re:0(1) scheduler by Sivar · · Score: 2

      Oh, I see. Nevermind. Hmm, I could have sworn that the "O" in my books was a zero. I guess i'll have to double-check that. Thanks for the correction. Oops.

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    4. Re:0(1) scheduler by dimator · · Score: 4, Funny

      I prefer ")1(O" just to throw people off.

      --
      python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
    5. Re:0(1) scheduler by pgpckt · · Score: 2, Interesting


      a 0(1) scheduler's overhead will not significantly increase.

      The term you are looking for is probably O(n), but definatly not O(1). O(1) will not increase at all, no matter how much data is put in. O(n) will increase linearly.

      --
      Lawrence Lessig is my personal hero.
    6. Re:0(1) scheduler by ink · · Score: 2
      Actually, it won't increase at all. If computation time increases according to data size, no matter how insignificantly, it is not O(1)

      There is a constant in there; big-oh measures the growth rate of an algorithm, not the actual time it takes to run. So, yes, it could take longer as the number of processes go up -- but that function would need to be linear. In other words: a O(1) algroithm isn't guaranteed to ever complete when presented with an infinite set of problems.

      --
      The wheel is turning, but the hamster is dead.
    7. Re:0(1) scheduler by Cryptnotic · · Score: 2

      O(1) means that there is some constant C, such that for any problem size N, the execution time of the algorithm is less than C.

      O(n) means that there is a constant, C, such that for any problem of size N, the execution time of the algorithm is less than C*N.

      --
      My other first post is car post.
    8. Re:0(1) scheduler by srichman · · Score: 2
      The term you are looking for is probably O(n), but definatly not O(1).
      No, he means O(1) scheduler, definitely not O(n). Most simple scheduling algorithms (e.g., basic round robin) are constant-time, and a contant-time scheduler patch was recently released for Linux.

      Just think about it logically. Why would he expectantly ask if the scheduler was O(n)? Name one super-linear scheduling algorithm in use in modern operating systems.

  8. Re:FreeBSD = Security by Peyna · · Score: 2

    Just about every *nix distro I've seen now has SSH up and running by default.

    --
    What?
  9. Darwin? by BlackGriffen · · Score: 3, Interesting

    Anybody have any idea when/if Apple will integrate improvements from this scheduler in to Darwin/OSX?

    1. Re:Darwin? by Sivar · · Score: 5, Informative

      The scheduler is closely tied with the kernel, and MacOSX does not use the FreeBSD kernel at all. It uses the Mach kernel, which is not only a different kernel entirely but a different core kernel philosophy. Mach is a microkernel whereas FreeBSD's is a monolithic kernel. Both types have their advantages and disadvantages, but microkernels are vastly superior for a commercial OS and for driver installations. Monolithic kernels are theoretically faster and easier to implement.

      MacOSX gets its BSD label by using the BSD userland utilities. It is great that Mac's OS is no longer junk. In three months I went from "Macs are toy computers for kiddies and Photoshop pros" to "Wow--I can replace every PC and OS in my house with a single Mac! Great desktop, good server, and all the power of Unix."
      I have never been happier with the state of Apple Inc.

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    2. Re:Darwin? by Drishmung · · Score: 5, Informative
      Not quite. This link gives quite bit more background about Darwin. In particular:
      Part of the history of Mac OS X goes back to Berkeley Software Distributions (BSD) UNIX of the early seventies. Specifically, it is based in part on BSD 4.4 Lite. On a system level, many of the design decisions are made to align with BSD-style UNIX systems. Many of the libraries are derived from NetBSD (http://www.netbsd.org/), while many of the utilities are from FreeBSD (http://www.freebsd.org/). For future development, Mac OS X has adopted FreeBSD as a reference code base for BSD technology. Work is ongoing to more closely synchronize all BSD tools and libraries with the FreeBSD-stable branch.

      Although Mac OS X must credit BSD for most of the underlying levels of the operating system, Mac OS X also owes a major debt to Mach. The kernel is heavily influenced in its design philosophy by Carnegie Mellon's Mach project. The kernel is not a pure microkernel implementation though since the address space is shared with BSD processes.

      The Mac OS X kernel (also known as XNU) is a monolithic kernel (unlike Mach, but like Linux and xBSD) with Mach and BSD sitting side-by-side.

      Some earlier Apple Unix efforts were true micro kernel implementations. This was also driven by the attraction of a pure hardware abstraction layer. With Darwin this seems to have moved to a more pragmatic recognition that performance matters.

      In Darwin, the Mach bits handle memory management, IPC and device drivers. BSD handles users and permissions, the network stack, the virtual file system and POSIX.

      So, this won't directly benefit Darwin, though if it is generally useful then someone/anyone can try and put it into Darwin---long live open source! I confess I don't know how the Mach part of Darwin handles scheduling, though I had heard that the Mach VM and scheduling was pretty good.

      --
      Protoplasm. Quiet Protoplasm. I like quiet protoplasm.
    3. Re:Darwin? by Sivar · · Score: 2

      That is a very informative link, thanks!
      Someone please mod this person up as my comment, currently at +5 (undeservingly), obviously has some flaws that Drishmung has corrected.

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
  10. Re:FreeBSD = Security by quantum+bit · · Score: 4, Informative

    None of the FreeBSD releases, or the -STABLE branch were vulnerable to the openssh bug.

    ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/ FreeBSD-SA-02:31.openssh.asc

    Note the absence of any released version of FreeBSD.

  11. FreeBSD ~= Security by Sivar · · Score: 5, Informative

    I am not going to claim that FreeBSD is perfect, but FreeBSD is more secure than the vast majority of Linux-based OSes. It has supported features like the new "GR Security" patch for years, and because it shares a great deal of code with OpenBSD which is audited frequently, it benefits from their work as well.
    Of note is that FreeBSD's libc is just over half the size of Linux's Glibc (not that has a thing to do with security)

    With FreeBSD, for years, admins have been able to set certain files as "append only" (so even root can only add to, not remove from, log files) and "immutable" (so even root cannot modify or delete the file) and has been able to set firewall rules to the same (immutable) so that creative crackers can't add their personal favorites if they root the system.
    This can of course be bypassed by restarting the machine in single-user mode and redusing the kernel security level, but that isn't going to be very easy for your average remote hacker. :)

    Furthermore, since 4.0 you can multiple run complete but separate entire copies of FreeBSD on the same system, each with their own FreeBSD system files and such. You can have a single server run an instance of FreeBSD for Apache, one for Postfix, one for BIND, etc. and if any one of them does get compromised (say, BIND since that happens entirely too often) the cracker can not only not effect any of the other instances--he/she cannot even see that they exist! Very interesting stuff.
    Of course, IMHO Linux is worlds ahead of FreeBSD on the desktop front, and the new GRsecurity and ACL features will be a real competitor for the *BSD family. It will be most fascinating to see how things turn out. I wish the best to both of them, and I use both of them every day.

    --
    Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    1. Re:FreeBSD ~= Security by FooBarWidget · · Score: 2, Interesting

      "With FreeBSD, for years, admins have been able to set certain files as "append only" (so even root can only add to, not remove from, log files) and "immutable" (so even root cannot modify or delete the file) and has been able to set firewall rules to the same (immutable) so that creative crackers can't add their personal favorites if they root the system."

      Linux can do that too. That is, if you use ext2 or ext3. See chattr(1), options a (append only) and s (secure deletion).

    2. Re:FreeBSD ~= Security by Fweeky · · Score: 2
      if you use ext2 or ext3. See chattr(1), options a (append only) and s (secure deletion).
      How do you unset them? In FreeBSD the kernel can have a secure level set which can only be raised without rebooting; setting the kernel into a securelevel stops the various immutable/undeletable/etc flags being unset, among other things.

      Check security(7) under "SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS".
    3. Re:FreeBSD ~= Security by Fweeky · · Score: 2

      Er, yes, so how do you stop someone compromising root and setting -a? In FreeBSD, with a securelevel, the equivilent of chattr -a would fail with a permission denied even for the superuser.

      Setting the right things immutable would result in even you being unable to replace the base system or drop the securelevel without local access.

  12. Re:Why? by Waffle+Iron · · Score: 2, Funny
    What is the purported advantage of the new scheduler?

    Doesn't anybody read the submitters' article summaries any more? It says right at the top of this page that the new scheduler is Proportional. That's the advantage. We can therefore infer that the old one is inferior for a related reason: it's not Proportional.

    I'm all for good proportions. Kudos to the implementors. Keep up the good work.

  13. Hmmm by FrostedWheat · · Score: 2

    the only 3 files modified are kern_synch.c, kern_switch.c and proc.h, plus a one-line change to kern_exit.c

    I hate to be picky .. but that's 4 files modified. One-line or a thousand, it's still been modified.
    </END-RANT>

  14. Re:Schedulers. (*nix v. win2k) by Sivar · · Score: 3, Informative

    Not needed. Linux and FreeBSD both handle different priority levels quite nicely, and in fact can handle them in a much more fine-grained fashion. NT actually has additional priority levels in-between each that you described above, but Linux and BSD have a total of 41 possible priority values (from -20 to 20, including zero)
    If you set an application to a priority of 20, it isn't going to be bothering any other processes, and if you set an application to -20, it is going to be worshipped like a god by the scheduler.
    As far as I know, neither have a real-time scheduling mode like NT, which is actually a good thing in many cases. If a program running at real-time priority goes into an infinite loop, or for any reason uses 100% of hte CPU (SETI@Home, for example) than the system is locked the hell up. Even the mouse will not get any time for cursor movement, and you have to reset the machine.

    Read "man nice", "man renice", and probably "man top" (which I use to change priorities of running processes as root)

    --
    Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
  15. Re:Schedulers. (*nix v. win2k) by Ded+Bob · · Score: 3, Informative

    Is there any reason why something like this isn't implemented in Linux or FreeBSD?

    FreeBSD does have something like this: idle, normal, and real time. By default it is normal, but you can change it to idle (idprio(1)) or real time (rtprio(1)).

    In the man page for rtprio(1) is one relevant bug:
    "Under FreeBSD system calls are currently never preempted, therefore non-realtime processes can starve realtime processes, or idletime processes can starve normal priority processes."

    Maybe the new scheduler will fix this?

  16. Re:FreeBSD = Security by BrookHarty · · Score: 2

    I think you need to re-read that file. +3 indeed.

    Affects: FreeBSD-CURRENT between 2002-03-18 and 2002-06-25

  17. Re:FreeBSD = Security by bovinewasteproduct · · Score: 2

    None of the FreeBSD releases, or the -STABLE branch were vulnerable to the openssh bug.

    ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisorie s/ FreeBSD-SA-02:31.openssh.asc

    Note the absence of any released version of FreeBSD.

    I think you need to re-read that file. +3 indeed.

    Affects: FreeBSD-CURRENT between 2002-03-18 and 2002-06-25

    No, you try re-reading it again. FreeBSD releases (which are based on FreeBSD-Stable) are NOT anywhere near being FreeBSD-Current!

    FreeBSD-Current is not a release version. As a matter of fact, people are told NOT to use it unless they know what they are doing, and not just becuase they want one of the new features (which are nice, I've got a FreeBSD-Current SMP box here).

    BWP

  18. Re:FreeBSD = Security by BrookHarty · · Score: 2

    None of the FreeBSD releases, or the -STABLE branch were vulnerable to the openssh bug.

    -Current isnt a release? I can download it, Seems like a release to me, maybe a beta release, but it IS a release if its been put out. But whatever you call it some version of FreeBSD DID have the bug.

    Really get a kick out of you BSD guys trying to use the -Current and -Stable shit to try to say you dont have security holes. So you dont have this 1 bug on your -Stable, Lets check cert and see how many have been on -Stable. Same shit goes with OpenBSD, and "Never A Security bug" bullshit. PHP/SSH/Apache have a security hole, its "LINUX HAS A SECURITY HOLE", well FreeBSD uses the same damn software.
    -
    Try your Jedi mind tricks on a mircos~1 padawn... Go Go away...

  19. Re:Schedulers. (*nix v. win2k) by Nevyn · · Score: 3, Informative
    Not needed. Linux and FreeBSD both handle different priority levels quite nicely, and in fact can handle them in a much more fine-grained fashion. NT actually has additional priority levels in-between each that you described above, but Linux and BSD have a total of 41 possible priority values (from -20 to 20, including zero)
    Actually they can have much more than that, but the "user" can only set those 41 values. There isn't even a definition of how they have to map (so for instance you can have the schedular have priorities -20 to 20 including zero but in 0.5 increments. Or just -40 to 40 in 1.0 increments etc.
    As far as I know, neither have a real-time scheduling mode like NT, which is actually a good thing in many cases. If a program running at real-time priority goes into an infinite loop, or for any reason uses 100% of hte CPU (SETI@Home, for example) than the system is locked the hell up. Even the mouse will not get any time for cursor movement, and you have to reset the machine.
    Do "man sched_setparam" and man "setpriority" to learn about "real time" processes. Linux also had patches for SCHED_IDLE at one point, but that can cause pretty bad reasource deadlocks without priority inversion and so was never integrated.

    There can be problems if your "real time" process misbehaves but then don't do that.

    NOTE: The term "real time" is used to mean best effort at real time, for true real time you don't use a general purpose OS (Ie. NT doesn't count either).

    --
    ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
  20. Re:FreeBSD = Security by Arandir · · Score: 2

    Really get a kick out of you BSD guys trying to use the -Current and -Stable shit to try to say you dont have security holes.

    Go find out what -CURRENT actually is before you comment further. You are in serious danger of choking on your own foot...

    Just because -CURRENT is publicly available does not mean that it is released. An analogy is in order. -RELEASE is equivalent to linux-2.4.18. -STABLE is equivalent to linux-2.5.27. -CURRENT is equivalent to whatever is on Linus' harddrive at this very instant.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  21. Re:Low Latency, Pre-Emptive multitasking? by Dwonis · · Score: 2
    Well, my box is running almost that, and I'm not even running very much today:

    dwon@zed:~$ ls -d /proc/[0-9]* | wc -l
    151
    dwon@zed:~$

  22. Re:This is excellent news by Dirtside · · Score: 2

    ...or at least, schedule the funeral ;)

    --
    "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
  23. Except Solaris by moogla · · Score: 2

    ::shrugs::
    Doesn't even come with it.

    --
    Black holes are where the Matrix raised SIGFPE
  24. Here is a great reason to prefer BSD by sawilson · · Score: 3, Funny

    http://uptime.netcraft.com/up/today/top.avg.html

    You'll notice that 45 of those top 50 are BSD
    machines. Of those 45, 19 are FreeBSD boxes.
    You'll notice 1 Linux box. It's nice to see that
    leading industry sites like bongload.com and
    twobigirls.com have benefited so much from the
    stability of BSD.

    --

    The most important thing any republican needs to know.
  25. Re:Schedulers. (*nix v. win2k) by Burning1 · · Score: 2

    I disagree to some extent with comments that Linux has a scheduler that is 'good enough.'

    I ran some real time multimedia streaming applications under linux a while ago (LiveIce; very nice tool) and found that even using nice, I would occationally get glitches in the stream output during broadcasts.

    Switching to FVWM helped somewhat, as did nice... But when it cames right down to it, I don't think this should have been a problem.

  26. Re:Schedulers. (*nix v. win2k) by mosch · · Score: 2
    Is there any reason why something like this isn't implemented in Linux or FreeBSD?
    Mostly because it's already implemented on both systems. For freebsd see rtprio, idprio, and of course good old nice.
  27. I use Linux AND FreeBSD by leereyno · · Score: 3, Interesting

    Right now I've got four systems running Linux (RH-7.3 and 7.2) and one system running FreeBSD 4.6. At times in the past I've run OpenBSD and NetBSD as well.

    I can tell you firsthand that in terms of system stability that Linux and FreeBSD are comparable if not indistinguishable. FreeBSD does seem to be more efficient however. The pentium 200 that I have FreeBSD on loads up KDE 3.0 noticably faster than Redhat 7.2 did, and once loaded it is more responsive. On older hardware FreeBSD definitely seems to have an advantage. I consider FreeBSD to be a very fast and well designed operating system. I keep trying to find places where using it instead of Linux would be an advantage.

    Not everything about it is all that rosey however. The features and abilities that Linux provides but FreeBSD lacks such as SMP, kernel pre-emption, fast journaling filesystems, certain commerical software packages, 3D acclerated X servers, and generally better device support, make actually using FreeBSD as anything but an interesting toy kind of difficult to justify in many situations.

    I worry about FreeBSD. I'd love to see it grow and progress not as a competitor to Linux, but as something of a companion to it. So many people just don't seem to realize that open source isn't about operating systems alone. What Linux and FreeBSD do is provide a foundation, they aren't the whole house. Both provide a powerful and stable platform for running the actual programs that people want to use in the first place. The future of open source development is going to be 90% apps and userland and 10% OS. To have religious and political wars over the OS portion is immature and counterproductive. Linux and FreeBSD aren't genuine competitors from an economic standpoint because it is the applications that both run that make either compelling in the first place.

    I want BOTH Linux and FreeBSD to do well, to grow and expand and be the best operating systems anyone has ever seen. I detest the infantile immaturity of those who seek to create division and conflict between FreeBSD and Linux that simply shouldn't be there. I've gotten flames from FreeBSD "advocates" in particular filled with such hatred and obvious zealousness that you'd think they were Mac freaks, all because I described FreeBSD in terms that weren't favorable enough for their religious views. The Linux crowd is full of just as many jackasses, if not more.

    Computer enthusiasts are known for generally having high IQ's. Unfortunately our reputation for having low EQ's is equally well earned. There are far too many borderline autistics and asperger's sufferers among us with severely retarded social skills. That is really the only explanation I can come up with when grown men with extensive vocabularies use them to throw a fit on par with that of an eight year old.

    Anyway I'm drifting way off from what I wanted to write about. The point that I really want to make is that BOTH Linux and FreeBSD are absolutely fabulous operating systems (save the linux is just a kernel messages for church). The goals and vision behind each are so similar that any ill will between them is manufactured by immature, short sighted assholes. Microsoft is the enemy, not those who prefer another free Unix derivative that runs Mozilla, gnome, kde, etc just as well if not better than what someone else is using.

    Lee

    --
    Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
    1. Re:I use Linux AND FreeBSD by Anonymous Coward · · Score: 2, Informative

      Not everything about it is all that rosey however. The features and abilities that Linux provides but FreeBSD lacks such as SMP, kernel pre-emption, fast journaling filesystems, certain commerical software packages, 3D acclerated X servers, and generally better device support, make actually using FreeBSD as anything but an interesting toy kind of difficult to justify in many situations.

      1. FreeBSD does support SMP, albeit not as good as 2.4; but way better than 2.2.

      2. Kernel pre-emption is a hack, I'd like it but many developers think it's the wrong path.

      3. SoftUpdates are in most ways alot better than journaling, the only time that it isn't is in the event of a crash; as you have to whipe the dangling blocks in the background. But as performance is much better during up-time, it's all worth it.

      4. Can't argue with that, but then, I'd run Windows if it was all that important.

      5. Accelerated X, the X Server, is available for FreeBSD.

      6. BSD was way ahead of Linux when it comes to FireWire, USB and SCSI. In fact, the USB system in linux comes from NetBSD( 2 years later! ); and the SCSI system is way better on FreeBSD than on Linux.

    2. Re:I use Linux AND FreeBSD by leereyno · · Score: 2

      1: My (admittedly limited) understanding of SMP on FreeBSD was that they were having problems finding people to work on it. That they were having to do a rush job on it in order to try and get something marginally workable for 5.0. If SMP is working as well as it did in Linux 2.2 then that would be great.

      2: I LOVE kernel pre-emption. On older systems where the kernel can be more or less stuck chewing on something it makes the computer much more responsive. Kernel pre-emption is one of the hallmarks of microkernel architectures (well pre-emption of the userland threads that handle the system calls at least). The nice thing about it is that you don't HAVE to use it.

      3: the ext2 filesystem has support for ordered updates just like UFS. It isn't generally used except on servers because of the speed penalty. Ext3 on the other hand uses ordered mode by default. The benefit of jornaling is that your filesystem doesn't get left in and undefined state in the case of a crash. Also when you reboot you don't have to spend who knows how long checking the filesystem. Speed is a secondary concern. I can't make any solid claims about the speed of UFS using soft updates vs. ext3. All I can says that my personal experience with UFS has been that its much, much slower when it comes to creating or destroying files compared to either ext2 in asynchronous mode or ext3. In terms of raw throughput on existing files all I can say is that all three are fast enough that I don't notice any difference between them.

      4: It might not be important to you, but I support Unix in the college of engineering at Arizona State and believe me things like Matlab and Maple are a very big deal around here. I know of course that these might very well run on FreeBSD using its ability to emulate Linux (which is a VERY good thing IMHO).

      5: It is also commercial software not not cheap. I'm not one of your free software religious zealots, I have zero problems with commercial software. The problem is that if Accelerated X is the only X server with 3d support for FreeBSD, then that tips the scales decidedly in the favor of Linux where such support part of the base system.

      6: I know that NetBSD had support for USB back in early '99. I wasn't aware that the support for it under Linux was derived from NetBSD. Even if it was, the comparison here is between Linux and FreeBSD, not NetBSD. I've run NetBSD and I've never been particularly impressed with it. The main problem I see is that there are still people trying to support long dead hardware with it, hardware that NO ONE is going to actually run if they can help it in any way. I got a Quadra 700 for free a year or so ago and decided to try and make it into a real computer. That meant of course putting a real operating system on it. I chose NetBSD and sure enough it would load up and run.....VERY, VERY slowly. The fastest 68k mac ever made wasn't much faster than that Quadra 700 was, meaning that trying to continue to maintain a codebase for the platform line is an utter waste of time. I installed NetBSD for intel shortly thereafter and was less than thrilled by the stability of the system. The kernel didn't crash, but userland stuff I'd compiled from the ports sure did. OpenBSD is much better in that regard, most likely because it doesn't get spread too thin chasing dead hardware. I really like OpenBSD because it is designed to be secure by default, something that other Unix derivatives would do well to emulate. Obviously security is in the hands of the administrator and it is very possible to misconfigure OpenBSD to be insecure. Its just that with it I don't have such a nagging worry that there might be some exploit of some service or another waiting to be discovered by the cracker community. As for SCSI under Linux and FreeBSD I can't really comment one way or the other.

      I wasn't really sure how to respond to your post at first. To a large extent I think that for us to debate whether the issues above are real or not is pointless because I'm not out to attack FreeBSD by bringing them up. I WANT FreeBSD to do well, and these are the areas that I think it needs improvement in.

      The code base for FreeBSD is VERY mature and the base BSD system itself was created by some of the most brilliant computer scientists who have ever lived, such as Bill Joy. Ever read The Design and Implementation of the 4.4 BSD Operating System? Linux owes as much to BSD as it does to GNU.

      Projects like the BSD's are valuable because they provide an alternate view of how to do things from what is available under Linux. If something isn't really being done well in Linux and works better under one of the BSD's, then that provides a valuable contrast so that everyone can see that the problem needs to be fixed. This is a two way street however, which is exactly why I've listed things I thing need to be fixed. By listing them I'm not saying that FreeBSD is "bad," only that there are areas where there is room for improvement.

      Lee

      --
      Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
  28. FreeBSD SMP. by Patrick+Cable+II · · Score: 2, Informative

    (root@oracle)(3/ttyp0)(08:19P:07/23/02)-
    (#:/sys/ i386/conf)- grep SMP LINT

    # SMP OPTIONS:
    # SMP enables building of a Symmetric MultiProcessor Kernel.
    # An SMP kernel will ONLY run on an Intel MP spec. qualified motherboard.
    # Be sure to disable 'cpu I386_CPU' && 'cpu I486_CPU' for SMP kernels.
    # Check the 'Rogue SMP hardware' section to see if additional options
    options SMP # Symmetric MultiProcessor Kernel

    1. Re:FreeBSD SMP. by leereyno · · Score: 2

      Yes, but does the SMP actually work well? My understanding having not followed too closely is that SMP is not really working yet. It will detect two CPU's, but only really use one of them. That might have changed recently in which case I'm glad to hear it.

      Actually that reminds me of another area where FreeBSD needs improvement, kernel threads. These aren't a make or break feature, but they are nice.

      Lee

      --
      Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
  29. Re:Schedulers. (*nix v. win2k) by GypC · · Score: 2

    Try it with a low-latency or pre-emptive-scheduling patched kernel. By default the kernel is tuned as a server, not a multimedia workstation. The kernel team seems to be working to correct this by adding compile time options and/or a new scheduler, but for now, on stable kernels, it requires patches.

    I've personally found that the patches make an amazing improvement in UI responsiveness and media playback. I'm looking forward to 2.6.