mccabe@hatteras.cs.unc.edu (Daniel McCabe) (03/20/91)
A while back there was a post of nice for Minix. I missed it. Is there an archive which has a copy? I looked at plains.nodak.edu and a few of the smaller ones but couldn't find it. Thanx in advance, danm
vickde@vicstoy.UUCP (Vick De Giorgio) (03/21/91)
In article <2416@borg.cs.unc.edu> mccabe@hatteras.cs.unc.edu (Daniel McCabe) writes: >A while back there was a post of nice for Minix. I missed it. Is there >an archive which has a copy? I looked at plains.nodak.edu and a few of the >smaller ones but couldn't find it. > Right after that post, I mentioned (along with another person) that it would be real nice if someone who has installed just the nice portion of that post would post their method, so that those of us who only want that much of it wouldn't have to wade through all the ST stuff. Right about that time, 1200 or more ancient articles clogged this newsgroup for several days, and I don't know if I missed the reply. If I did, could I get an email? Thanks! =V= -- Vick De Giorgio - vickde@vicstoy.UUCP UUCP - uunet!tarpit!bilver!vicstoy!vickde - The Philosopher's Stone Unix BBS, Orlando FL - (407) 299-3661 1200/2400 24 hours 8N1
hp@vmars.tuwien.ac.at (Peter Holzer) (03/22/91)
mccabe@hatteras.cs.unc.edu (Daniel McCabe) writes: >A while back there was a post of nice for Minix. I missed it. Is there >an archive which has a copy? I looked at plains.nodak.edu and a few of the >smaller ones but couldn't find it. Yes, we have it: Host: ftp.vmars.tuwien.ac.at (128.130.39.19) Directory: pub/minix/net File: sysupd2.tar.Z (The name is not very descriptive, I know) PS: If you have any problems with ftp at this site, please send mail to me, not to root, postmaster, or who-ever. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
grundy@rtf.bt.co.uk (Martin Grundy) (03/25/91)
In article <1991Mar20.221512.21591@vicstoy.UUCP> vickde@vicstoy.UUCP (Vick De Giorgio) writes: [stuff deleted...] > >Right about that time, 1200 or more ancient articles clogged this >newsgroup for several days, and I don't know if I missed the reply. >If I did, could I get an email? Thanks! =V= > >-- >Vick De Giorgio - vickde@vicstoy.UUCP > UUCP - uunet!tarpit!bilver!vicstoy!vickde > - The Philosopher's Stone Unix BBS, Orlando FL > - (407) 299-3661 1200/2400 24 hours 8N1 I am also interested in nice(); have got the diffs from the original article, but at present haven't got time to mod them to run on PH1.5 (BTW I haven't actually tried them :-). We here, haven't had the ancient article problem. I have been watching for any follow-ups, but haven't seen any yet. ----------------------------------------------------------------------- Martin Grundy | email: grundy@rtf.bt.co.uk British Telecom Customer Systems | Hyperion House | phone: +44 273 762102 96-99 Queens Road | fax: +44 273 722038 or Brighton BN1 3XF. | +44 273 762071 (netfax)
go@jacobs.CS.ORST.EDU (Gary Oliver) (03/28/91)
Just thought I'd put in a good word for the nice "nice" package submitted by Kai-Uwe Bloem recently. It works "nice"ly. But seriously... I pulled the cdifs out and removed the "profiler" code (wasn't sure if it would all run on a PC - it was from a 68K system.) After pruning the profiler defs I just patched it against my "almost" standard 1.5.10 system (1.5.10 with virt-terminals and my shared-text) and it patched almost perfectly. A couple of problems with the .h files involving _PROTOTYPEs that I lobotomized for the purpose of quickly installing... The performance (on my 10Mhz AT with 4meg) is SO MUCH better I am able (right as I type in this note) to run 6 compute-bound jobs without ANY noticable degradation in performance as I type this in to kermit. Terminal output is steady too (at 2400 BPS.) (And these "hogs" aren't even niced!!) I even tried running two "du /" simulatenously and you can still vi, ls, etc without anything other than expected happening - no more 15 second pauses for ls to list a 5 line directory. I'm not certain, but if people would try this, the cry about having a "threaded" fs may die down. The package is a much simpler way to get most of the performance asked for and it is in keeping with the spirit of Minix : simple and effective. It's a pretty classical implementation of process priorities with queue pre-emption and should, at least, be representative of topics discussed in any OS class worth taking. Try it - you'll like it. Gary Oliver go@jacobs.cs.orst.edu
dgraham@bmerh451.bnr.ca (Douglas Graham) (03/28/91)
In article <go.670130351@jacobs.CS.ORST.EDU> go@jacobs.CS.ORST.EDU (Gary Oliver) writes: > >Just thought I'd put in a good word for the nice "nice" package submitted >by Kai-Uwe Bloem recently. It works "nice"ly. ... >I'm not certain, but if people would try this, the cry about having a >"threaded" fs may die down. The cry seems to pretty muted these days. Partly because the FAQ goes out of it's way nip such talk in the bud. This is unfortunate, because even if it never got implemented, it would (and did) lead to some interesting discussions on alternate O/S designs. It's too bad that this group doesn't see more of those types of discussions; the type that us lifelong students of O/S design could learn something from. A better scheduler helps, but it's no panacea. It will always seem silly to me that I have to wait to send a character to the console, while the floppy driver waits for a bunch of interrupts. It's not likely to get any better when I finally get around to writing the tape driver that I so badly need. >The package is a much simpler way to >get most of the performance asked for and it is in keeping with the >spirit of Minix : simple and effective. Is Minix really all that simple? Maybe it's just me, but I find that some of the task interactions are really quite complicated and convoluted. A non preemptable passive kernel, with many equivalent user processes vying for resources seems to me to be a more understandable model. But like the FAQ sez, if you want it, do it yourself... > It's a pretty classical >implementation of process priorities with queue pre-emption and >should, at least, be representative of topics discussed in any >OS class worth taking. Yup, along with virtual memory, disk scheduling algorithms, discussions on maximizing throughput... --- Doug Graham dgraham@bnr.ca Bell-Northern Research, Ottawa Ontario Canada
des@basie.wpd.sgi.com (Des Young) (03/30/91)
Hi, This is actually about multi-threaded FS. I agree with the previous lines, it is a pity the FAQ sheet nips this stuff in the bud. I am working on a SCSI driver that supports streaming tape. The current FS will never support it. You must have overlap in disk and tape I/O to maintain streaming. This is such a standard requirement, no O/S can hold its head up without tape support. The assumption I have made in my driver is at least that FS is capable of supporting an outstanding I/O per task. This allows me to overlap wini, floppy, tape and terminal I/O. It does complicate the driver a little (since wini, floppy and tape all want to use the single SCSI bus). But this change to FS seems much more reasonable than fully-fledged multi-threading. It also limits the number of state-table entries in the driver (required for disconnect/ reconnect support). Now, I have not actually modified FS yet... :-), is anyone inspired ? Cheers, Des. -- trademarks abound, usual disclaimers apply, opinions are mine des@pei.com Des Young (415) 335-1888 Protocol Engines Inc., Mountain View, CA
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) (04/01/91)
go@jacobs.CS.ORST.EDU (Gary Oliver) wrote: > > Just thought I'd put in a good word for the nice "nice" package submitted > by Kai-Uwe Bloem recently. It works "nice"ly. Yes, I completely agree with you. I added the "kub-scheduler" to Advanced MINIX, and it worked GREAT! Thanks, Kai-Uwe! > But seriously... I pulled the cdifs out and removed the "profiler" code > (wasn't sure if it would all run on a PC - it was from a 68K system.) > After pruning the profiler defs I just patched it against my "almost" > standard 1.5.10 system (1.5.10 with virt-terminals and my shared-text) > and it patched almost perfectly. A couple of problems with the .h > files involving _PROTOTYPEs that I lobotomized for the purpose of > quickly installing... Same here. When were those _PROTOTYPEs added to the proto.h files? > I'm not certain, but if people would try this, the cry about having a > "threaded" fs may die down. The package is a much simpler way to > get most of the performance asked for and it is in keeping with the > spirit of Minix : simple and effective. It's a pretty classical > implementation of process priorities with queue pre-emption and > should, at least, be representative of topics discussed in any > OS class worth taking. Nope. The new scheduler only works well for CPU-bound processes. Since most I/O processes are "FS" bound, the new scheduler won't solve anything. I am afraid that we will still need major surgery to FS, be it Multi-Threading or Message Queueing. I will hunt my archives for the original message posted by Larry Hubble, a long time ago. He posted message queueing code for the 1.2 FS then, and, on my _slow_ XT, it worked like a miracle. I will post it here as soon as I find it... Fred.
go@jacobs.CS.ORST.EDU (Gary Oliver) (04/05/91)
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) writes: >go@jacobs.CS.ORST.EDU (Gary Oliver) wrote: >> >> Just thought I'd put in a good word for the nice "nice" package submitted >> by Kai-Uwe Bloem recently. It works "nice"ly. >Yes, I completely agree with you. I added the "kub-scheduler" to Advanced >MINIX, and it worked GREAT! Thanks, Kai-Uwe! >> But seriously... I pulled the cdifs out and removed the "profiler" code [ stuff deleted ...] >> I'm not certain, but if people would try this, the cry about having a >> "threaded" fs may die down. The package is a much simpler way to >> get most of the performance asked for and it is in keeping with the >> spirit of Minix : simple and effective. It's a pretty classical >> implementation of process priorities with queue pre-emption and >> should, at least, be representative of topics discussed in any >> OS class worth taking. >Nope. The new scheduler only works well for CPU-bound processes. Since >most I/O processes are "FS" bound, the new scheduler won't solve anything. Well maybe on your machine, but mine is somewhat of a slug. :-) >I am afraid that we will still need major surgery to FS, be it Multi-Threading >or Message Queueing. I will hunt my archives for the original message posted >by Larry Hubble, a long time ago. He posted message queueing code for the >1.2 FS then, and, on my _slow_ XT, it worked like a miracle. I will post >it here as soon as I find it... >Fred. I agree with the above COMPLETELY. My concern is, though, that since the threaded FS stuffs seems to be stonewalled (at least I don't expect to see it in "standard" Minix soon) we need SOMETHING to get a little added boost out of the old box. Personally I don't find the idea of a more complex FS all that intimidating, but you must remember (as it has been said SO MANY times before) that Minix was supposed to be simple enough for beginning OS students to understand quickly. I didn't intend to restart this discussion, but maybe it IS time... Gary Oliver go@jacobs.cs.orst.edu
nhc@cbnewsj.att.com (n.h.chandler) (04/06/91)
In article <go.670829316@jacobs.CS.ORST.EDU>, go@jacobs.CS.ORST.EDU (Gary Oliver) writes: > waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) writes: > > >Yes, I completely agree with you. I added the "kub-scheduler" to Advanced > >MINIX, and it worked GREAT! Thanks, Kai-Uwe! > > Gary Oliver > go@jacobs.cs.orst.edu Am I missing something here? What is "Advanced MINIX"??? Neville Chandler nhc@cbnewsj.att.com
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (04/16/91)
nhc@cbnewsj.att.com (n.h.chandler) wrote: > In article <go.670829316@jacobs.CS.ORST.EDU>, go@jacobs.CS.ORST.EDU (Gary Oliver) writes: >> waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) writes: >> >> >Yes, I completely agree with you. I added the "kub-scheduler" to Advanced >> >MINIX, and it worked GREAT! Thanks, Kai-Uwe! >> >> Gary Oliver >> go@jacobs.cs.orst.edu > > Am I missing something here? What is "Advanced MINIX"??? > > Neville Chandler > nhc@cbnewsj.att.com Aiii... here we go again... :-( Because MINIX was intended as a "simple OS that even a second-year student could understand", MINIX lacks some of the things (read: features) that are nice (actually: needed) when people start _using_ MINIX. After a long and hard battle (:-) with Andy, we at NLMUG decided it was time for a version of MINIX that was not necessarily supported by Andy (i.e.: we had to apply all future patches ourselves, and do our own research on top of that), but which was more _usable_ on the real world. A beautiful example of such a system are the machines I have here (the "minixug" one, which serves a complete network, and the *.uwalt.nl.mugnet machines, which server me and the "minixug" system in development, research and such..). They all run this special MINIX. Well now. The current Advanced MINIX is based on 1.5.10, with lots of "net" patches applied (like VC, KeyStailey's SymLinks, Extended Cache, my serial driver, my boot loader, my MM extensions, our patches to the SymLink kit which makes it really standard) and some of the stuff available from archives (we use BCC as the standard compiler, we have Estdio as the standard lib, Advanced MINIX is now fully merged with Bruce's MINIX/386, etc...). All in all: a large system, with lots of features to make it really usable. The current version (1.5.10E12-PC/286) even includes my DynaLink feature (dynamic linkage of servers at boot time) and the rewrite of INIT. Also, it contains the latest versions of my UUCP, U-MAIL, W-MAIL and W-NEWS packages installed. The current distribution on PC diskettes counts, uhh,lets see... 43 diskettes. Quite large... :-) In the near future we will be supporting the MGR package as well. Hope this helps a bit, Fred N. van Kempen