wayne@csri.toronto.edu (Wayne Hayes) (09/25/90)
Why does the Minix documentation still say "Limit of 3 users"? Is there some code hidden somewhere that only allocates only 3 logons or something? What about Gordan's Virtual Consoles? I have logged on as root, wayne, and 2 friends accounts at the same time *and* had someone over the modem *and* the second serial port hooked into my amiga accross the desk (I run Minix on the PC, not the Amiga -- yet.) That's a grand total of 6 simultaneous users with vanilla 1.5 + virtual console. If you have enough serial ports, where's the limit? -- "The number of programs that can be done with the Hubble Space Telescope has always greatly exceeded the time available for their execution, and this remains true even with the telescope in its current state." -- HST Science Working Group and User's Commitee Report, 1990 June 29. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
ast@cs.vu.nl (Andy Tanenbaum) (09/26/90)
In article <1990Sep24.213213.26431@jarvis.csri.toronto.edu> wayne@csri.toronto.edu (Wayne Hayes) writes: >Why does the Minix documentation still say "Limit of 3 users"? Simply because PCs normally have only two serial ports plus the console. There are no technical reasons you can't have more users. You just have to change a couple of constants in the tty driver and recompile. Also, you may have to change a couple of things down there to support more physical RS232 lines. Andy Tanenbaum (ast@cs.vu.nl)
waltje%minixug.uucp@plains.nodak.edu (Fred van Kempen) (10/05/90)
In article <1990Sep24.213213.26431@jarvis.csri.toronto.edu>, wayne@csri.toronto.edu (Wayne Hayes) wrote: > Why does the Minix documentation still say "Limit of 3 users"? Is there > some code hidden somewhere that only allocates only 3 logons or something? > What about Gordan's Virtual Consoles? I have logged on as root, wayne, > and 2 friends accounts at the same time *and* had someone over the modem > *and* the second serial port hooked into my amiga accross the desk (I run > Minix on the PC, not the Amiga -- yet.) That's a grand total of 6 > simultaneous users with vanilla 1.5 + virtual console. Plus the MUX driver I will soon post for the AST FourPort/XN and EightPort ! (so, I have cons[1..4], [tty[5..8] and mux[0..7] ! > If you have enough serial ports, where's the limit? CPU performance and/or memory size ! I run with a FREECOM 286/16 with 16Mbyte ("minixug") and a NEAT 286/20 with 8Mbyte ("uwalt"). Both machines are _very_ fast, and run fine as long as all users keep away from any compiler... You may remember the _real_ problem in MINIX on high-speed machines, which is the single-tasking FS server. MINIX version 1.2 had an extension from Larry Hubble which allowed for message queueing. This really boosted up the overall performance! So, for many users, you must: 1. Have a fast CPU (>= 16MHz 286 or 386) 2. Have plenty of memory (>= 4Mb) 3. Have a (some) fast and large disk(s) (>= 40Mb, <= 28ms) 4. A lot of serial port boards (COM1: - COM4) and a MUX (AST FourPort) 5. Have the Virtual Console stuff from Gordon Irlam installed 6. Add Message Queueing and/or Multi-Threading to the operating system Well, items 1-5 are fully supported by NLMUG Advanced MINIX; item 6 is "yet to be done". I think we should have another look at the message queueing stuff from Larry, and implement it in 1.5 FS. After that, we could start thinking about adding multiple threads per process to the kernel (Andy? How did you do it in Amoeba?) ... Comments, anyone? Fred. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | MINIX User Group Holland UUCP: waltje@minixug.UUCP | | c/o Fred van Kempen, or: waltje%minixug@plains.nodak.edu | | Hoefbladhof 27 | | 2215 DV VOORHOUT "Love is - what you want it to be. | | The Netherlands Alannah Myles" | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (10/09/90)
In article <32572@nigel.ee.udel.edu> waltje%minixug.uucp@plains.nodak.edu (Fred van Kempen) writes: >So, for many users, you must: > >1. Have a fast CPU (>= 16MHz 286 or 386) >2. Have plenty of memory (>= 4Mb) >3. Have a (some) fast and large disk(s) (>= 40Mb, <= 28ms) >4. A lot of serial port boards (COM1: - COM4) and a MUX (AST FourPort) >5. Have the Virtual Console stuff from Gordon Irlam installed >6. Add Message Queueing and/or Multi-Threading to the operating system > >Well, items 1-5 are fully supported by NLMUG Advanced MINIX; item 6 is >"yet to be done". I think we should have another look at the message >queueing stuff from Larry, and implement it in 1.5 FS. >After that, we could start thinking about adding multiple threads per >process to the kernel (Andy? How did you do it in Amoeba?) ... Actually, Amoeba does the filesystem in an entirely different manner from normal Unix or Minix -- it takes "small is beautiful" to mean "RAM is cheap but the code should still be small." The FS is not multithreaded, but it's fast because it burns RAM to make sure it rarely waits. When a file is opened, for example, the entire file is loaded into the cache and remains there. If you consider why the Minix FS waits, this makes sense. When Minix is bringing in a directory block from the disk for one process, another process can't get at blocks which are cached and readily available. Given that most files are typically read from beginning to end, it makes sense to read them all at once, as long as you have plenty of RAM. So, one could design a really high-performance but RAM-hungry Minix FS, you can follow Amoeba's lead and do it like this: 1) Add a file-system-switch, so that all FS does is call tasks which do the real work. This keeps FS small and beautiful while allowing the student/experimenter to play with new filesystems. 2) Write a FS that keeps ALL the directory information in RAM, and stores files as contiguous segments on disk. Store changes to the file structure in a log on the disk. When files are opened, read them into RAM and leave them there until they are closed, whereupon you write them back to disk all at once if they're dirty. This FS rarely waits. Any inode information is available without reading the disk. Reading from an already-open file or writing to a file always uses memory buffers. When an uncached file is opened or a cached file is flushed, it goes into a queue of things to be done. Changes to the directory structure written into the log are combined -- the more things to be done, the more changes we can write to the log at once. And so on. Of course, the details of who calls whom are nasty, but at least this FS can be a single-threaded finite-state machine, and hence easy to understand. [ While we're at it, I should note that you can compress the inode information in memory somewhat, and we get /tmp for free by creating cached states like "closed dirty file, write to disk should you be forced to remove this file from RAM to load other files", etc. ] 3) Write other kinds of FS types, such as a networked FS using the Amoeba networking protocol. If you're willing to accept a stated protocol, it should be relatively simple. The code for #2 could easily turn out to be smaller than the code for the current FS, and it will certainly be faster. The question is how much RAM it will munch. -- "Restraint, hell. I'm just too fucking busy." -- Bill Wisner