Date: Fri, 16 Aug 2002 05:21:13 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jonathon McKitrick <jcm@FreeBSD-uk.eu.org> Cc: freebsd-hackers@freebsd.org Subject: Re: When to consider the new scehduler? Message-ID: <3D5CEE39.51E55574@mindspring.com> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathon McKitrick wrote: > | thrashing, but the result was that the X server had sufficiently > | good interactive response to fullfill the "move mouse -> wiggle > | cursor" requirement amd avoid cognitive dissonance on the part > | of the user attached to the mouse. 8-). > > Why don't they just add an extra CPU to handle the GUI?? ;-) They did. 4.0.2 was the ES/MP (Enhanced Security/Multi Processing) release, and 4.2 was the SMP enhanced version of UnixWare (released as UnixWare 2.0). I guess you could use it for other things, too... 8-). > | Here is an introduction from a moderately good paper on the subject. > > Interesting how these 'fundamental' concepts of CS are still being > researched/refined over the years. Unix already applies so much > research and development that was found to have real-world > practicality, and yet still there is room for improvement in at least > some circumstances. Not really. A lot of them are rehashing things we've known for a long time, and UNIX just hasn't implemented, for whatever reason (usually, failure to incorporate patches). For example, Luigi did FACK/SACK patches against FreeBSD around 1996, and Rice University did LRP against FreeBSD around 1998, and neither were commiited. Rutgers has implemented a stateful failover API with minor stack modifications against FreeBSD-STABLE, which they are very interested in seeing incorporated in FreeBSD, and they are basically being ignored. I'd say it was more "people who refuse to learn from history are doomed to repeat it". > | For my money, the algorithm to use in networking equipment, in > | which you want to optimize packet throughput, is Weighted Fair > | Share Queueing (as in the IBM/UMass work on QLinux, which also > > It would be nice if the 'instant workstation' port tweaked the system > settings to meet a balance between needs of the network and needs of > the user. Things like scheduler, sysctl settings, and so on. > > Of course, that's a bit of overkill, wouldn't ya say? ;-) Not really. It's possible to implement optimal networking algorithms, and have them be useful. A workstation experiencing a load based denial of service attack would function nearly normally, if its networking stack had Lazy Receiver Processing integrated (as one example). So I wouldn't categorize things as "workstation technology" vs. "server technology" simply because the person I'm talking two only has two buckets, and insists I pick one. 8-). I don't know where this whole idea of having a bunch of knobs that you have to turn away from the defaults to get non-mediocre performace came from, but the mythology that has grown up around the believe is, well, really annoying. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D5CEE39.51E55574>