gilgalad@caen.engin.umich.edu (Ralph Seguin) (12/04/90)
Howdy. YASOQ (Yet Another Slew Of Questions). I should be getting a NeXT cube within a couple of weeks. I have a few questions on optimal configs. It will have a 40 meg disk for paging. I have a 300 meg Wren 4. Is 40 megs going to be enough for most needs? Should I just scrap the 40 meg and put the paging partition on the Wren? What about if I get 16 megs of RAM? I want to reduce strain on the Wren as much as possible, that is why I'd like restrict paging to the 40 meg. Somebody mentioned that you can have the swap partition spread across multiple devices. Could I use the 40 meg, and make a 40 meg partition on the Wren? If I go with just the Wren drive, what sort of space am I going to have left? What size /tmp should I have? Anybody know of a good location for SIMMs? What type of SIMMs should I get? Parity? Will the 040 board accept the SIMMs I have now? Any help is appreciated. Thanks, Ralph PS- Somebody mentioned /etc/swaptab for swapping space info. Ralph Seguin gilgalad@dip.eecs.umich.edu 536 South Forest Apt. #915 gilgalad@caen.engin.umich.edu Ann Arbor, MI 48104 (313) 662-4805
bennett@mp.cs.niu.edu (Scott Bennett) (12/05/90)
In article <1990Dec4.032737.12258@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >Howdy. YASOQ (Yet Another Slew Of Questions). I should be getting a NeXT >cube within a couple of weeks. I have a few questions on optimal configs. >It will have a 40 meg disk for paging. I have a 300 meg Wren 4. Is >40 megs going to be enough for most needs? Should I just scrap the 40 meg >and put the paging partition on the Wren? What about if I get 16 megs of RAM? >I want to reduce strain on the Wren as much as possible, that is why I'd like >restrict paging to the 40 meg. Somebody mentioned that you can have the >swap partition spread across multiple devices. Could I use the 40 meg, and >make a 40 meg partition on the Wren? If I go with just the Wren drive, The so-called "accelerator" disk on the 68030 cubes is apparently used for paging/swapping *and* for /tmp. The paging/swapping space is initially allocated as 16MB but can grow. Because I haven't yet begun working with mine, I don't know whether the 16MB is determined by the kernel or can be set by us somewhere in a file. /tmp, of course, depends on what you put there. In any virtual memory system the general rule of thumb is to split the paging/swapping space across as many access arms as possible. In the case of a primarily single-user system, that may be a bit less urgent than in multiuser situations. Given that you will have two disks, I'd try splitting it anyway. In virtual memory versions of UNIX another good rule of thumb is to try to separate /tmp from the root file system by placing it onto a different drive. It's also a good idea, when possible, to have /tmp on a separate drive from wherever the users' home directories are, in large part because many editors typically copy the file to be edited into /tmp they start up and then copy the updated version back from /tmp when the user is done editing. If access mechanisms are abundant (unlikely on workstations like a NeXT) and the system has lots of users active, then it is sometimes beneficial to separate /usr from the root file system, too. >what sort of space am I going to have left? What size /tmp should I have? >Anybody know of a good location for SIMMs? What type of SIMMs should I get? >Parity? Will the 040 board accept the SIMMs I have now? Any help is Here we go again. (sigh) If you don't have parity memory, you don't have any way of knowing whether what was written to memory last will be the same thing read back later. In other words, the computer has no way to detect that its memory has made a mistake. If integrity of your computing is not particularly important to you, buy the cheap junk. If integrity is important to you, buy the barely more expensive stuff (i.e. parity memory). If you buy the cheap crap and something goes partly wrong with it (especially if the problem is intermittent), be prepared to have immense difficulty figuring out where the problem is occurring--that is, of course, assuming that you are even aware that a problem exists. Indulge me a moment or two while I fantasize. ;-) Suppose a certain memory location has an intermittent error where a bit may be dropped from a 32-bit word when it is written (stored). Now let's imagine that this particular 32-bit word happens to contain some disk address information that is about to go to your disk controller to tell it where to write a block. The error occurred this time when the word was stored, but was not detected because the memory has no parity checking. When the block is written to the disk, where will it go? Oh, my! Maybe it writes over something in the swap area. Maybe it writes a block of data into another file (say, your MACH kernel image:-). Or maybe the damaged address is an illegal address and you get a message on /dev/console that you have some sort of disk error. After a while you shut the machine off. The NeXT day you start it up again. The machine is still cool because you just turned it on and the ROM diagnostics don't encounter the error during their write and read back check, so you don't get any clues there. :-) Later, when it warms up again... Let's try another. ;-) Suppose you have just spent the last two years doing research, the data collected from which you are now analyzing in preparation for publication. Most of your results seem to be coming out pretty much as you had expected and there's even one result you got that fairly well clinches what you have been proposing to your colleagues in recent months. They maybe weren't too sure, but now you have *proof*. The reviewers think your paper looks reasonable and it gets published. One person reads it, however, who thinks you're all wet and gets you to send a copy of your raw data. That person tries some other analyses and eventually redoes the same one you used. That person is unable to reproduce your results from your data. This is not fatal to a career, certainly, but it *would* likely be an unwelcome experience. If I seem paranoid in all the above, please consider that I've been working with computers for a fairly long time (see what you have to look forward to? :-) and no, to my knowledge nobody had used non- parity memory for a long time before I started (that was in 1967) either. >appreciated. > > Thanks, Ralph > >PS- Somebody mentioned /etc/swaptab for swapping space info. > > >Ralph Seguin gilgalad@dip.eecs.umich.edu >536 South Forest Apt. #915 gilgalad@caen.engin.umich.edu >Ann Arbor, MI 48104 (313) 662-4805 Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * Visit the scenic Illinois Craters! Just 10 minutes * * from New Chicago! * **********************************************************************
gerst@ecs.umass.edu (12/05/90)
Reply-To: lloyd@ucs.umass.edu >Subject: Re: YASOQ >From: bennett@mp.cs.niu.edu (Scott Bennett) >In article <1990Dec4.032737.12258@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >> [questions about swap files and multiple HD's etc.. deleted] > The so-called "accelerator" disk on the 68030 cubes is apparently .. >[some conjecture about the 40 meg HD deleted] so-called? well, try paging on the OD, MISERABLE (loud too!). Anyways, what you want to do it look at '/etc/rc','/etc/rc.swap' and do a man on 'mach_swapon', I just recently reconfigured my system so the 40 meg HD is swapspace and accounts. I'm a single user system, and this is just dandy. /etc/rc - the boot script, it executes /etc/rc.swap and mach_swapon. /etc/rc.swap - a shell script that "figures out" if the 40 meg swap disk is present, mounts it, sets up a swapping file and /tmp. mach_swapon - used for setting up a swapfile, look at the man pages, I'm not going to repeat them here. It allows you to specify hi/low water marks and whether it is a preferred swapfile or not. Look at the above, if you have a weak stomach for modifying boot scripts, I'd get someone else to be responsible for editing anything :-> a lot of information in rc.swap is "hardcoded" in, expect to do a lot of fiddling. As for memory, swapfile and other setup recommendations, I would take a good look at how much resources you typically use. It's kinda hard to make recommendations based on your name. Being a single user non-networked node is quite different from being a server that runs mega lisp progs. Now, I have a question. mach_swapon is documented as supporting multiple swapfiles. In my experience, this is NOT the case. I have configured 1, 2 and 3 swapfiles in various combinations across the OD and HD. when #1 preferred swapfile hits the high water mark, the system comes to a grinding halt. I spent a solid day reconfiguring swapfiles and rebooting (reboots and fsck are fun!). And the system never touched any of the secondary swapfiles. Has, does or will mach_swapon *USE* more than one swapfile? >>PS- Somebody mentioned /etc/swaptab for swapping space info. uh huh. falls under 'mach_swapon'. 'Digital Librarian' is your friend. ('man' too!) Chris Lloyd - lloyd@ucs.umass.edu
scott@mcs-server.gac.edu (Scott Hess) (12/06/90)
In article <11694.275cf7f6@ecs.umass.edu> gerst@ecs.umass.edu writes:
Now, I have a question. mach_swapon is documented as supporting
multiple swapfiles. In my experience, this is NOT the case. I have
configured 1, 2 and 3 swapfiles in various combinations across the OD
and HD. when #1 preferred swapfile hits the high water mark, the system
comes to a grinding halt. I spent a solid day reconfiguring swapfiles
and rebooting (reboots and fsck are fun!). And the system never touched
any of the secondary swapfiles.
Has, does or will mach_swapon *USE* more than one swapfile?
I guess that this "bug" is documented (somewhere). Also, I've heard
that NextStep2.0's version of Mach will support it, though I can't
remember where I heard it, so maybe that's not reliable info. But
I seem to remember being impressed, so maybe it was . . .
--
scott hess
scott@gac.edu
Independent NeXT Developer (Stuart)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
<I still speak for nobody>