caroma@rice-chex.ai.mit.edu (Carl R. Manning) (11/29/90)
In article <1990Nov28.191405.25218@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: > Whether they have 8MB, 12MB, or even more, they'll be throwing those >SIMMs away and replacing them as soon as they can afford to when they >discover NeXT has stuck them with nMBx8 SIMMs rather than nMBx9's. Jeesh. >Nonparity memory was obsoleted in the 1950's. Here's a question: What does the NeXT do if it gets a parity error? If my machine gets hit by a cosmic ray or a chip goes bad, I don't want my machine to crash, or worse yet, become unusable (who knows what deadlines I might be under); it should correct the error and warn me about it the background so I can have it fixed in the future. As the amount of memory soars, the chances of a bit getting flipped or a chip going bad somewhere are also on the increase. Memory is cheap; add a few more bits and you can have ECC error correction of single bit errors. Perhaps futures NeXTs can be designed for people or servers who need this much reliability, at least as an option. I would think that this security could be a good selling point -- look at how 4wd cars and anti-lock brakes are selling these days. caroma@ai.mit.edu
kline@cs.arizona.edu (Nick Kline) (11/29/90)
In article <12081@life.ai.mit.edu> caroma@rice-chex.ai.mit.edu (Carl R. Manning) writes: >In article <1990Nov28.191405.25218@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >> Whether they have 8MB, 12MB, or even more, they'll be throwing those >>SIMMs away and replacing them as soon as they can afford to when they >>discover NeXT has stuck them with nMBx8 SIMMs rather than nMBx9's. Jeesh. >>Nonparity memory was obsoleted in the 1950's. > >Here's a question: > > What does the NeXT do if it gets a parity error? > ... >Memory is cheap; add a few more bits and you can have ECC error >correction of single bit errors. Perhaps futures NeXTs can be >designed for people or servers who need this much reliability, at >least as an option. I would think that this security could be a good >selling point -- look at how 4wd cars and anti-lock brakes are selling >these days. > >caroma@ai.mit.edu Well actually there are several nexts available with parity memory. its an option, if you want. Of course, it costs extra All four machines are available with parity. -nick =----= "Diane, it's 11:47 p.m., still October 31st. I've just encountered an enemy of the United States government on the campus grounds. While I am an employee of the aforementioned government, the subject is an extra- national and a leader of a sovereign nation, quite possibly placing him out of my jurisdiction. I do believe, however, that he is likely host body for Bob." --Agent Cooper on encountering Saddam Hussein kline@cs.arizona.edu
louie@sayshell.umd.edu (Louis A. Mamakos) (11/29/90)
>Well actually there are several nexts available with parity memory. >its an option, if you want. Of course, it costs extra >All four machines are available with parity. According to the beta release notes, installing parity memory will also introduce a wait state for memory acceses. So it looks like you will pay a performance penelty if you go that route. You also have to populate the machine with either ALL parity memery or NO parity memory. louie
tgingric@magnus.ircc.ohio-state.edu (Tyler S Gingrich) (11/30/90)
In article <12081@life.ai.mit.edu> caroma@rice-chex.ai.mit.edu (Carl R. Manning) writes: >In article <1990Nov28.191405.25218@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >> Whether they have 8MB, 12MB, or even more, they'll be throwing those >>SIMMs away and replacing them as soon as they can afford to when they >>discover NeXT has stuck them with nMBx8 SIMMs rather than nMBx9's. Jeesh. >>Nonparity memory was obsoleted in the 1950's. > >Memory is cheap; add a few more bits and you can have ECC error >correction of single bit errors. Perhaps futures NeXTs can be >designed for people or servers who need this much reliability, at >least as an option. I would think that this security could be a good >selling point -- look at how 4wd cars and anti-lock brakes are selling >these days. > You can get ANY of the Next computers with Parity memory. The additional cost (list prices) is $500 on Mono systems & $1000 on Color systems. Also, you can only order 16Mb or 32Mb parity memory systems. This increases the base price for any of the systems. Tyler
smithw@hamblin.math.byu.edu (Dr. William V. Smith) (11/30/90)
tgingric@magnus.ircc.ohio-state.edu (Tyler S Gingrich) writes: >>In article <12081@life.ai.mit.edu> caroma@rice-chex.ai.mit.edu >>(Carl R. Manning) writes: >>In article <1990Nov28.191405.25218@mp.cs.niu.edu> >>bennett@mp.cs.niu.edu (Scott Bennett) writes: >>> Whether they have 8MB, 12MB, or even more, they'll be throwing those >>>SIMMs away and replacing them as soon as they can afford to when they >>>discover NeXT has stuck them with nMBx8 SIMMs rather than nMBx9's. >>>Jeesh. >>>Nonparity memory was obsoleted in the 1950's. >> >>Memory is cheap; add a few more bits and you can have ECC error >>correction of single bit errors. Perhaps futures NeXTs can be >>designed for people or servers who need this much reliability, at >>least as an option. I would think that this security could be a good >>selling point -- look at how 4wd cars and anti-lock brakes are selling >You can get ANY of the Next computers with Parity memory. The additional >cost (list prices) is $500 on Mono systems & $1000 on Color systems. >Also, you can only order 16Mb or 32Mb parity memory systems. This increases >the base price for any of the systems. >Tyler Scott has a good point here: you don't want to order parity memory with your NeXT. The (new) board is wired for it anyway. So get the minimum memory config, and buy third-party parity SIMMS, a MUCH cheaper alternative, whether you buy min parity config from NeXT and add on third party, or buy reg. memory config and pull out the 8 SIMMS and replace with 9 bit third party. Too bad NeXT doesn't ship a "no memory option" [subtracting *their* price for the removed memory]- that was a joke, of course. Chow. -Bill- -- __________________Prof. William V. Smith____________________ EMail: smithw@hamblin.math.byu.edu or uunet!hamblin.math.byu.edu!smithw SMail: Math Dept. -- 314 TMCB; BYU; Provo, UT 84602 (USA) NeXTmail: smithw@mathnx.math.byu.edu Phone: +1 801 378 2061 FAX: +1 801 378 2800
dkoski@hercules.as.arizona.edu (David Koski) (11/30/90)
I was wondering about the eight megs too. The spacrstation SLC's here seem to need more memory, but then again they have their swap space out on the network! I asked the next rep here about memory and he said that if you need to expand, you must do it in sets of four chips, so sell four 1M simms and get 4 more 4M simms (total of 20M memory). David Koski
bennett@mp.cs.niu.edu (Scott Bennett) (11/30/90)
In article <1990Nov29.161041.15775@magnus.ircc.ohio-state.edu> tgingric@magnus.ircc.ohio-state.edu (Tyler S Gingrich) writes: >In article <12081@life.ai.mit.edu> caroma@rice-chex.ai.mit.edu (Carl R. Manning) writes: >>In article <1990Nov28.191405.25218@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >>> Whether they have 8MB, 12MB, or even more, they'll be throwing those >>>SIMMs away and replacing them as soon as they can afford to when they >>>discover NeXT has stuck them with nMBx8 SIMMs rather than nMBx9's. Jeesh. >>>Nonparity memory was obsoleted in the 1950's. >> >>Memory is cheap; add a few more bits and you can have ECC error >>correction of single bit errors. Perhaps futures NeXTs can be >>designed for people or servers who need this much reliability, at >>least as an option. I would think that this security could be a good >>selling point -- look at how 4wd cars and anti-lock brakes are selling >>these days. >> A closer analogy would be to ask oneself whether one would like to buy a car that had no indicators (not even idiot lights) for high coolant temperature, low oil pressure, electrical net discharge, etc. > > >You can get ANY of the Next computers with Parity memory. The additional Really? Was it an option on the 68030 cubes? Can the 68030 boards handle nMbx9 SIMMs? My machine is a brand-new, old machine (from B'land's oversold demo unit clearance:-), so if I can replace the garbage that's in it with civilized memory, I'd like to know. >cost (list prices) is $500 on Mono systems & $1000 on Color systems. > >Also, you can only order 16Mb or 32Mb parity memory systems. This increases Does anyone know the reason for the restriction? >the base price for any of the systems. > >Tyler > And in article <1990Nov29.130142.15813@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >>Well actually there are several nexts available with parity memory. >>its an option, if you want. Of course, it costs extra >>All four machines are available with parity. > >According to the beta release notes, installing parity memory will >also introduce a wait state for memory acceses. So it looks like you >will pay a performance penelty if you go that route. Why on earth (or anywhere else) would they introduce a wait state for normal (i.e. parity) memory? All this is starting to make me think NeXT has a hidden, dark side sort of like Apple's... > >You also have to populate the machine with either ALL parity memery or NO >parity memory. Well, of course. BTW, does anyone know where I can get some useful documentation of the hardware and documentation beyond the novice user level for the software? The _NeXT_User_Reference_ manual that came with the machine refers to a _NeXT_System_Reference_ manual, but NeXT, Inc. claims that this manual is no longer available. > >louie > 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! * **********************************************************************
cs3ea3by@maccs.dcss.mcmaster.ca (Andrew Tyldesley) (11/30/90)
I have ordered the basic slab will I be able to upgrade my memory at a later date to the optional parity setup at a reasonable price or is this something that is only available when the machine is ordered. Thanks... Tills
caroma@wheat-chex.ai.mit.edu (Carl R. Manning) (12/01/90)
In article <1990Nov30.013031.25032@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >In article <1990Nov29.161041.15775@magnus.ircc.ohio-state.edu> tgingric@magnus.ircc.ohio-state.edu (Tyler S Gingrich) writes: >>In article <12081@life.ai.mit.edu> caroma@rice-chex.ai.mit.edu (Carl R. Manning) writes: >>>Memory is cheap; add a few more bits and you can have ECC error >>>correction of single bit errors. Perhaps futures NeXTs can be >>>designed for people or servers who need this much reliability, at >>>least as an option. >> >>You can get ANY of the Next computers with Parity memory. > >>someone else writes: >>>Well actually there are several nexts available with parity memory. >>>its an option, if you want. Of course, it costs extra >>>All four machines are available with parity. >> Some people seem to have jumped onto this thread late, so I'll repeat and reword parts of my posting: I realize that the NeXT can have parity memory; my original question remains unanswered: What does the NeXT do when it gets a memory parity error? (e.g. Does it lock up the machine immediately? Or does it report the error and allow you to decide whether to try continuing? If the error is in memory which isn't critical to what I'm doing, I'd rather not lose all my work with a crashed machine -- at least give me the chance to try to save what work I can.) I have a feeling some people may be missing part of the point of my posting. As the amount of memory increases, the chances go up that a bit will get flipped by a passing cosmic ray or that some chip or part of a chip will go bad. Parity memory adds one bit to each word, which allows detection of single bit errors. ECC (error correction code) memory adds a few more bits, which add enough redundancy so that words can be correctly reconstructed even if some bit(s) go bad. A common form of ECC allows single bit error correction and double bit error detection. Thus, it is possible to organize memory so that a passing cosmic ray or single failing chip needn't stop your machine; this security can be an important selling point for people who depend on their machine to accomplish their work. So I suggest the next generation NeXT's might offer the option of error correcting code memory rather than just parity. Ordinary PC's offer parity; more `premium' PC's and workstations offer ECC. -- CarlManning
blenko-tom@cs.yale.edu (Tom Blenko) (12/01/90)
|... As the amount of memory increases, the chances go up that a |bit will get flipped by a passing cosmic ray or that some chip or part |of a chip will go bad. Parity memory adds one bit to each word, which |allows detection of single bit errors. ECC (error correction code) |memory adds a few more bits, which add enough redundancy so that words |can be correctly reconstructed even if some bit(s) go bad. A common |form of ECC allows single bit error correction and double bit error |detection. Thus, it is possible to organize memory so that a passing |cosmic ray or single failing chip needn't stop your machine; this |security can be an important selling point for people who depend on |their machine to accomplish their work. First, there are a variety of ways that memories fail, and "a few more bits" are not going to address all of them. There are always cost ($$ and performance)/reliability tradeoffs. I presume NeXT is offering the option in order to garner government purchases (which sometimes require parity memory). Second, the subject of parity vs. non-parity memories has been discussed at length in other newsgroups. It is usually non-productive: not everyone's needs are the same, and the people with the most loudly-voiced opinions often seem to know the least. Hence I suggest NOT repeating the exercise here. Tom
kenb@amc-gw.amc.com (Ken Birdwell) (12/01/90)
>caroma@wheat-chex.ai.mit.edu (Carl R. Manning) writes: > >I realize that the NeXT can have parity memory; my original question >remains unanswered: What does the NeXT do when it gets a memory parity >error? (e.g. Does it lock up the machine immediately? Or does it report >the error and allow you to decide whether to try continuing? If the >error is in memory which isn't critical to what I'm doing, I'd rather >not lose all my work with a crashed machine -- at least give me the >chance to try to save what work I can.) >[stuff about cosmic rays causing parity errors and EEC and stuff] I suppose that the process that got the parity error could get a SIGBUS error. I'm sorry but it's really dangerous to keep running after that sort of thing happens. On most UNIX system you'll get a 'panic: parity error' with no idea of where and the system will shut itself off. Now this is alot better then doing stuff like, spewing to a now random file handle or jumping into a function that formats your hard disk or at a minimun trashes all your saved data because some comparison failed or whatever but I agree, powering down is nasty. I think that killing the process (if possible; if parity error occured in the schedular, youre screwed) is a resonable thing to do. Its kinds nice to not let your program go into Lala-land without telling you. Just think of it as a random SEGV, and I know of no-one who thinks it's resonable to continue after one of those (except for Mac and DOS people :^). --
scott@next-5.gac.edu (Scott Hess) (12/02/90)
In article <4326@amc-gw.amc.com> kenb@amc-gw.amc.com (Ken Birdwell) writes: >I suppose that the process that got the parity error could get a SIGBUS >error. I'm sorry but it's really dangerous to keep running after that sort >of thing happens. On most UNIX system you'll get a 'panic: parity error' >with no idea of where and the system will shut itself off. Now this is alot >better then doing stuff like, spewing to a now random file handle or jumping >into a function that formats your hard disk or at a minimun trashes all your >saved data because some comparison failed or whatever but I agree, powering >down is nasty. I think that killing the process (if possible; if parity >error occured in the schedular, youre screwed) is a resonable thing to do. >Its kinds nice to not let your program go into Lala-land without telling you. >Just think of it as a random SEGV, and I know of no-one who thinks it's >resonable to continue after one of those (except for Mac and DOS people :^). Best solution (IMHO) is to get sent a SEGV-like signal, but let it work more like SIGSTOP. Then, the user can choose whether to screw over their machine, or not . . . In _most_ processes, it's not that big of a deal (max loss, probably a file or so), but setuid processes would be dangerous to do this on, so only let the superuser continue those. Another parallel process that should be taking place is that the swapper should mark that page bad, and take appropriate action based on that. For one, don't let anyone use that page, now. Also, many faults of this type can be survived, for instance if it occurs in a code segment (just re-read from the executable), or in a file mapped to memory, which would be similar (well, if read-only). Boy, this sounds like fun! I don't envy whoever's putting this stuff together :-) -- scott hess scott@gac.edu Independent NeXT Developer (Stuart) GAC Undergrad (Horrid. Simply Horrid. I mean the work!) <I still speak for nobody>
ccastcr@prism.gatech.EDU (Russo, Chris A.) (12/04/90)
I realize how parity is useful in communications type applications where
stuff can get lost, but how is parity useful in on board ram?
Just wondering.
--
Russo, Chris A.
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!ccastcr
Internet: ccastcr@prism.gatech.edukoverber@hawk.ulowell.edu (Kurt Overberg) (12/06/90)
In article <18042@hydra.gatech.EDU> ccastcr@prism.gatech.EDU (Russo, Chris A.) writes: > > I realize how parity is useful in communications type applications where >stuff can get lost, but how is parity useful in on board ram? Yes, even RAM is susceptable to errors. It is useful as far as error detection and correction. If you have a memory error, parity ram will try to correct the error at much as possible. I have heard (no proof) that parity ram is required on all hospital (medical) computers, but then again, this is not substantiated. The actual helpfulness of parity ram is, however, questionable. > Just wondering. Hope this helps. >-- >Russo, Chris A. >Georgia Institute of Technology, Atlanta Georgia, 30332 >uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!ccastcr >Internet: ccastcr@prism.gatech.edu +--------------------------+--------------------------------------------------+ | This space | "There once was a time when ( ACK ! ) | | for rent | my life was so wonderful..." (_______) | | | "Then they sent me away, taught me o | |#include <stddisclaim.h> | how to be logical...sensible, o | |--------------------------| rational, a vegetable..." _ /| | |koverber@hawk.ulowell.edu | -Supertramp \`o.O' | +--------------------------+--------------------------------------------------+
kls30@duts.ccc.amdahl.com (Kent L Shephard) (12/07/90)
In article <1567@ulowell.ulowell.edu> koverber@hawk.ulowell.edu (Kurt Overberg) writes: > > It is useful as far as error detection and correction. If you > have a memory error, parity ram will try to correct the error at ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Not true parity and error correction are totally different. 1 bit parity (basically an XOR of all the bits) like on IBM PCs, optional on Macs, and I suppose the NeXT will only detect a bit flipping if 2 bit flip 1-->0 and 0--> you don't get a parity error with one bit detection. Error correction is a different animal entirely. It requires more bits, more complicated logic etc. > much as possible. I have heard (no proof) that parity ram is > required on all hospital (medical) computers, but then again, this > is not substantiated. The actual helpfulness of parity ram is, > however, questionable. ~~~~~~~~~~~~~ Depends on if you halt the system, or issue an interrupt that has a sevice routine that asks if you would like to continue or not. If your doing a critical calc. that has to be right you don't want a bit flipping in the MSB, but if your doing word processing 1 bit in 1 character isn't going to make a bit of diff. if you go back and proofread. > >+--------------------------+--------------------------------------------------+ >| This space | "There once was a time when ( ACK ! ) | >| for rent | my life was so wonderful..." (_______) | >| | "Then they sent me away, taught me o | >|#include <stddisclaim.h> | how to be logical...sensible, o | >|--------------------------| rational, a vegetable..." _ /| | >|koverber@hawk.ulowell.edu | -Supertramp \`o.O' | >+--------------------------+--------------------------------------------------+ -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
mikec@wam.umd.edu (Michael D. Callaghan) (12/07/90)
Speaking of memory, is it okay if I just steal the SIMMs from my Mac II, and put them into my Cube? They are 80ns 1meg SIMMs, for what it's worth. MikeC -- ___________________________________________________ Michael D. Callaghan,MDC Designs, University of Merryland mikec@wam.umd.edu
tjb@unhd.UNH.EDU (Thomas J. Baker) (01/09/91)
I recently got my '030 cube and am in the process of upgrading it. I currently have 8 1mb simms installed and I am debating the pros and cons of getting an additional 8 1mb simms for a total of 16mb or 4 4mb simms for a total of 24mb. The extra cash saved on 8 1mb (4*~190=750 - 8*~40=320 == $430) would go towards a 9600 baud modem to greatly enhance uucp connectivity, currently 2400 baud. The 9600 baud modem would also be great for SLIP or PPP. Is there a significant improvement from 16mb to 24mb? Any recommendations of vendors? (By the way, there is a pretty good intro article on SLIP and PPP on page 33 in the 7 January Unix Today.) Thanks in advance. tjb -- ____________________________________________________________________________ | Thomas J. Baker INTERNET: tjb@unhd.unh.edu | | Computing and Information Services USENET: uunet!unhd!tjb | | Kingsbury Hall, University of New Hampshire BITNET: T_BAKER@UNHH.BITNET | | Durham, NH 03824 Voice: (603) 862-4490 | | | | NeXT: IceCube!tjb@unhd.unh.edu | |__________________________________________________________________________|
zimmer@calvin.stanford.edu (Andrew Zimmerman) (06/14/91)
In article <SCOTT.91Jun14003836@mcs-server.gac.edu> scott@mcs-server.gac.edu (Scott Hess) writes: > >[ Lastly, some flamage. Alot of people make fun of EPS (and > lately, myself) for our insistance that no matter the > raw performance of your CPU, you really are going to need > the memory and disk space. Rather than attempt to argue, > as most apparently don't listen, I would advise anyone > who's doubtful to go out and find a NextStation400M > w/16M or 32M of memory, and a 105M machine with 8M, and > do a side-by-side comparison. It will literally blow your > socks off. We're not talking fractions of a second > differences here - in many cases, it's order of _magnitude_. > For instance, launch Edit on a file on the 105/8 machine. > Then, on the 400/16 machine. The 400/16 is fast enough > that you really don't notice the launch time, while the 105/8 > takes long enough that you start to get up to pace the room. > That's the difference between enjoying your time on the machine, > and spending it in frustration . . .] > >Later, >scott hess scott@gac.edu I would be interested in getting some hard numbers on how much faster a 16 meg machine is compared to an 8 meg machine. Opinions that I have heard range from "worlds of difference" to "doesn't help at all". I would guess that whether memory helps r doesn't help is largely a function of how you have your machine set up and how you use your machine. For example, I have a 200/8 standalone, an only run one or two apps at a time with the Preference App hidden. Launching an app can take between 5 and 15 seconds. (The screen isn't large enough to run more then one or two Apps at a time :-)) We have noticed that a 200/8 network machine tends to do a lot more swapping to disk, and the Launch time is greater. This machine was just upgraded to a 200/16 (with parity). The owner commented that he did not see that great of speed improvement. Launch time should mostly be a function of the hard disk speed (or network) and the amount of memory that is being used for data. The text (instruction) memory should not be paged back to disk. Relaunching a hidden App would of course be faster if it had not been swapped out to memory. Do the people who notice a big speed increase tend to run many Apps at the same time? When you say "Launch", are you talking about the first launch, or launching from a hidden state? Please do not take the above comments to mean that I don't believe Scott and EPS when they say that more memory helps. I am considering purchasing more memory, and want to know if it will make the machine respone that much faster. As such, I would like to understand the context in which Scott and EPS are making their claims. **** BTW, if you really want to see a machine bog down, run mm. I have heard that when our DEC 3100s is running 4 copies of mm, it can take up to 30 seconds to read the mail.txt file. That's on a machine with 24 Meg of memory. *** Andrew zimmer@calvin.stanford.edu
hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy)) (06/14/91)
Unfortunately, I have no way of doing side-by-side comparisons. But upgrading memory from 8MB to 20MB (which is, IMHO the most economical upgrade) made a real difference in the speed of things like TeX (the NeXT is the fastest TeX-machine I have ever run on) and Mathematica. When I had 8 MB and ran Mathematica anything else seemed to run at a snail's pace. With the 20 MB my patience never gets taxed. I presume for heavy Mathematica use 32 MB is preferable. Let's hope that Mathematica 2.0 is less of a memory-hog. Same was true for XNeXT -- with 8 MB it was really sluggish. Greetings, Hardy -------****------- Meinhard E. Mayer (Hardy); Department of Physics, University of California Irvine CA 92717; (714) 856 5543; hardy@golem.ps.uci.edu or MMAYER@UCI.BITNET
gad@eclipse.its.rpi.edu (Garance A. Drosehn) (06/15/91)
Speaking of memory... In MacWeek I noticed that Newer Technology is selling 8Mbyte and 16Mbyte SIMM's. The price for these is certainly out of my range at the moment, but I was wondering whether the NeXT can work with these sizes of SIMMs if someone wanted to buy them. I figure a NeXT with 128Mbytes of memory would be really nice (if I can get someone else to buy me one... :-) - - - - - - - - Garance Alistair Drosehn = gad@rpi.edu or gad@eclipse.its.rpi.edu ITS Systems Programmer (handles NeXT-type mail) Rensselaer Polytechnic Institute; Troy NY USA
prie@escher.cc.rochester.edu (Tod Rieger) (06/15/91)
Seymour Cray foresaw that processor performance would
far outstrip I/O throughput. Consequently, Cray computers
do not have virtual memory: either your application is
entirely in physical memory or it's not running.
Upgrading my standalone slab to 16Mb has all but
eliminated swapping -- only Improv's Presentation Builder
has a hint of it. TeX simply flies.
Since disk I/O is limiting the 8Mb 040 on large apps,
a faster processor must be accompanied by more memory (as
EPS and Hess have stated) if there is to be any speedup.
NeXTime.scott@mcs-server.gac.edu (Scott Hess) (06/15/91)
In article <1991Jun14.125927.18256@neon.Stanford.EDU> zimmer@calvin.stanford.edu (Andrew Zimmerman) writes: In article <SCOTT.91Jun14003836@mcs-server.gac.edu> scott@mcs-server.gac.edu (Scott Hess) writes: > >[ Lastly, some flamage. Alot of people make fun of EPS (and > lately, myself) for our insistance that no matter the > raw performance of your CPU, you really are going to need > the memory and disk space. Rather than attempt to argue, > as most apparently don't listen, I would advise anyone > who's doubtful to go out and find a NextStation400M > w/16M or 32M of memory, and a 105M machine with 8M, and > do a side-by-side comparison. It will literally blow your > socks off. We're not talking fractions of a second > differences here - in many cases, it's order of _magnitude_. > For instance, launch Edit on a file on the 105/8 machine. > Then, on the 400/16 machine. The 400/16 is fast enough > that you really don't notice the launch time, while the 105/8 > takes long enough that you start to get up to pace the room. > That's the difference between enjoying your time on the machine, > and spending it in frustration . . .] I would be interested in getting some hard numbers on how much faster a 16 meg machine is compared to an 8 meg machine. Opinions that I have heard range from "worlds of difference" to "doesn't help at all". That's tough. The problem is that the machine is actually not really much "faster". For instance, it won't calculate a small picture of a Mandelbrot set any faster. Anything that can fit in memory will run about the same speed with the extra memory. What really is noticeable is the launch speed of apps and the like. When I lauch Edit on a file on a 105/8 machine on a network, the disk goes crazy - swapping, I assume. At the very least, launching the same way on a 105/16 machine does not have nearly the disk activity. The time difference is something like 16-20s to 3-5s, which is respectable. That's on a network file, not a local file (shave maybe a second or two, then :-). Of course, once you're editing a document, it makes no difference. But, many people, I've found, don't spend all their time in a single document of a single app. Well, I don't, and most people I work with don't. Then again, these are mostly developers and sysadmins, so they don't spend much time in a single window, but jump between them alot. That's where the memory really makes a difference. We have noticed that a 200/8 network machine tends to do a lot more swapping to disk, and the Launch time is greater. This machine was just upgraded to a 200/16 (with parity). The owner commented that he did not see that great of speed improvement. One thing we noticed here (Well, actually, Gustavus is "here", even though I'm not there at this time) is that when the netboot clients (accelerator disk+8M memory) were upgraded from '030 to '040, there was no noticeable speed increase. When either the '030 or the '040 was upgraded to 12M or 16M, there was a noticeable increase. Launch time should mostly be a function of the hard disk speed (or network) and the amount of memory that is being used for data. The text (instruction) memory should not be paged back to disk. Relaunching a hidden App would of course be faster if it had not been swapped out to memory. Do the people who notice a big speed increase tend to run many Apps at the same time? When you say "Launch", are you talking about the first launch, or launching from a hidden state? Well, hard disk speed makes a difference, but I think memory makes more. For instance, I run IB, Stuart, Workspace, Edit, TimeMon, IconBounce, and Background constantly. The last three don't really count, as they'll quickly achieve a small working set of pages, as I don't touch them after they launch. IB is a large app. The main thing is that it doesn't use the shared libraries, for the most part. So, it looses alot of memory to that. Stuart's small, as is Edit, but Workspace is relatively large, also. And Edit can be large, if you're editing lots of files. Most of my switching is from Edit to Stuart, with Workspace being a distant third, and IB way back there. You can notice the difference between 8M and 16M even when switching between Edit and Stuart, but it's not too bad. You can really notice when switching to a Workspace you've not touched in a couple minutes (when you've been editing/compiling, etc). And you _really_ notice when you call up IB, or any other app that's sat in the background for awhile (like 20 or 30 minutes). On the 16M system, there really isn't a whole lot of difference when switching between any of the apps I list, unless you've let them run for a long time. On an 8M system, you really can tell. I'll give a short list of some launch times for a couple apps on the NeXT. These are not hard& fast measurements. It's a relatively unloaded system, and I'm basically estimating the times. The hardware is a stock NextStation400/16, with nothing else (except the modem I'm talking to you through): Edit: 1.5s Edit on /etc/termcap: <3s IB: 3s Librarian: 4s Mail: <3s Preferences: 5s Preview: <2s WriteNow: 3s Stuart: 3s Improv: 4s Diagram: 5s IconBounce: 1.5s WordPerfect: 7s SoftPC: 4s Alas, I've not got Mathematica on my system, so can't really test it. Later, -- scott hess scott@gac.edu Independent NeXT Developer Graduated GAC Undergrad! <I still speak for nobody> Note: I have moved home for a time. My email address will still be valid. Any SnailMail should be redirected, along with phone calls. At the least, my parents can tell you how to get hold of me, or forward any mail . . . Old: PO 829, GAC, St. Peter, MN 56082 (507) 933-8466 New: RR#4 Box 227 Pipestone, MN 56164 (507) 825-2788
eps@toaster.SFSU.EDU (Eric P. Scott) (06/15/91)
In article <1991Jun14.125927.18256@neon.Stanford.EDU> zimmer@calvin.stanford.edu (Andrew Zimmerman) writes: >I would be interested in getting some hard numbers on how much faster a >16 meg machine is compared to an 8 meg machine. Opinions that I have heard >range from "worlds of difference" to "doesn't help at all". > >I would guess that whether memory helps r doesn't help is largely a function >of how you have your machine set up and how you use your machine. Uh-huh. For example, if you change /etc/ttys to run a getty on the console, and dispense with all the NextStep stuff, 8MB might actually be viable. A machine running 2.0/2.1 "doing nothing" wants 13MB *real memory* in order to keep the "overhead" stuff resident--more on a Color machine. That doesn't leave much breathing room for Apps. An 8MB machine is *guaranteed* to thrash in normal use. All the MIPS in the world don't make a bit of difference if the processor is waiting for pageins. Faster disk transfer rates and smaller seek times don't do YOU a heck of a lot of good if the drive is constantly paging instead of accessing YOUR data. >Please do not take the above comments to mean that I don't believe Scott and >EPS when they say that more memory helps. I am considering purchasing more >memory, and want to know if it will make the machine respone that much faster. >As such, I would like to understand the context in which Scott and EPS are >making their claims. There's a strange schizophrenia about comp.sys.next... "More MIPS! More MIPS! RISC this, RISC that. Power, power, speed, speed, speed! Faster, faster, FASTER!!!" along with "but *I* can live with 8MB, *I* can live with 200MB disk, *I* can live with 2400 bps modems, it's OK if it takes 4 minutes to print a page, 10 minutes to log in, it only takes a hundred floppy disks to back up my files..." There's a certain point of diminishing returns, granted, but it's a lot closer to 32MB than it is to 8MB. If I'm running Terminal+Edit+Librarian+IB (not an unusual combination), there's an obvious difference between 16MB and 20MB. If I'm just running just one of those, there isn't--but that's not normal! Once you learn that you CAN run more than one App at a time, and that it's advantageous to do so (especially considering how well-integrated things are), it's hard to imagine using the NeXT like a you-know-what computer. Q. Who'd want a sports car with a motorcycle-sized fuel tank? A. "Who cares, if you get laid." Sigh... -=EPS=-
zimmer@calvin.stanford.edu (Andrew Zimmerman) (06/15/91)
In article <1720@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >In article <1991Jun14.125927.18256@neon.Stanford.EDU> > zimmer@calvin.stanford.edu (Andrew Zimmerman) writes: >>I would be interested in getting some hard numbers on how much faster a >>16 meg machine is compared to an 8 meg machine. Opinions that I have heard >>range from "worlds of difference" to "doesn't help at all". >> >>I would guess that whether memory helps r doesn't help is largely a function >>of how you have your machine set up and how you use your machine. > >Uh-huh. For example, if you change /etc/ttys to run a getty on >the console, and dispense with all the NextStep stuff, 8MB might >actually be viable. A machine running 2.0/2.1 "doing nothing" >wants 13MB *real memory* in order to keep the "overhead" stuff >resident--more on a Color machine. That doesn't leave much >breathing room for Apps. An 8MB machine is *guaranteed* to >thrash in normal use. All the MIPS in the world don't make a bit >of difference if the processor is waiting for pageins. Faster >disk transfer rates and smaller seek times don't do YOU a heck of >a lot of good if the drive is constantly paging instead of >accessing YOUR data. > >>Please do not take the above comments to mean that I don't believe Scott and >>EPS when they say that more memory helps. I am considering purchasing more >>memory, and want to know if it will make the machine respone that much faster. >>As such, I would like to understand the context in which Scott and EPS are >>making their claims. > >There's a strange schizophrenia about comp.sys.next... >"More MIPS! More MIPS! RISC this, RISC that. Power, power, >speed, speed, speed! Faster, faster, FASTER!!!" along with >"but *I* can live with 8MB, *I* can live with 200MB disk, *I* >can live with 2400 bps modems, it's OK if it takes 4 minutes >to print a page, 10 minutes to log in, it only takes a >hundred floppy disks to back up my files..." > >There's a certain point of diminishing returns, granted, >but it's a lot closer to 32MB than it is to 8MB. > >If I'm running Terminal+Edit+Librarian+IB (not an unusual >combination), there's an obvious difference between 16MB and >20MB. If I'm just running just one of those, there isn't--but >that's not normal! Once you learn that you CAN run more than one >App at a time, and that it's advantageous to do so (especially >considering how well-integrated things are), it's hard to imagine >using the NeXT like a you-know-what computer. > >Q. Who'd want a sports car with a motorcycle-sized fuel tank? >A. "Who cares, if you get laid." > >Sigh... > > -=EPS=- Maybe I didn't make myself clear in my original posting. I have heard conflicting reports whether additional memory makes a significant performance improvement on the NeXT. As such, I asked for specific metrics of improvement, not for comments like it's OK if it takes 4 minutes to print a page, 10 minutes to log in, etc. Such comments really don't help, and only clutter the already overcrowded newsgroup. I would still like to hear from people about the performance of their machines. Please include whether the machine is standalone or networked, amount of memory, the type (size) of HD, and the Apps that you run at the same time. (Thanks) BTW, I do use my NeXT like a you-know-what computer (a DEC 3100). Even with the 8 Meg limit, I'm pretty happy with it. Andrew zimmer@calvin.stanford.edu PS. Its not really that hard to make a machine perform poorly, what is hard is to get the best performance out of a particular configuration.
eps@toaster.SFSU.EDU (Eric P. Scott) (06/15/91)
In article <1991Jun15.085335.4605@neon.Stanford.EDU> zimmer@calvin.stanford.edu (Andrew Zimmerman) writes: >Maybe I didn't make myself clear in my original posting. I have >heard conflicting reports whether additional memory makes a significant >performance improvement on the NeXT. As such, I asked for specific metrics >of improvement What's important is what the end-user sees. Quoting statistics is pretty useless, since they can be made to prove whatever point you want. If you want comparable measurements, tell us WHAT you want measured and HOW you want it measured. You haven't done that. If you're seriously interested in how RAM affects performance ->for what YOU want to use the machine for<-, find yourself a 32MB machine with the same peripherals, and follow the procedure given in NextAnswers' misc.575. And yes, you have to do it YOURSELF. Otherwise, you're going to get what you ask for, but not the answers you really want. -=EPS=-
barry@joshua.math.ucla.edu (Barry Merriman) (06/16/91)
In article <SCOTT.91Jun15011146@mcs-server.gac.edu> scott@mcs-server.gac.edu (Scott Hess) writes: > >I'll give a short list of some launch times for a couple apps on the >NeXT. These are not hard& fast measurements. It's a relatively >unloaded system, and I'm basically estimating the times. The hardware >is a stock NextStation400/16, with nothing else (except the modem I'm >talking to you through): I'll throw in some comparison times from my home machine, which is a NeXT Cube, *030*, 8MB RAM, 330MB Maxtor HD (68MB free) (timed using the Preferences clock with seconds showing) >Edit: 1.5s 22s >IB: 3s 22s >Librarian: 4s 24s >Mail: <3s 19s >Preferences: 5s 25s >Preview: <2s 12s >WriteNow: 3s 16s >Stuart: 3s 18s >Improv 4s 25s >Diagram: 5s 59s >Mathematica -- 22s There's a whole lotta swapping going on when I do these things, too. When I add 4MB RAM shortly, I expect it to make a big improvement. Her's a snapshot of my ambient processes for the above experiments: (If you have any tips to speed things up, let me know!) feynman>ps -augx USER %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND root 121 27.9 2.0 1.24M 160K a R 166h h- std.9600 ttya (getty) me 878 14.3 33.4 7.43M 2.67M ? S 374:03 - console (WindowServer) root 5854 12.8 6.5 1.60M 536 2 R 0:00 ps -augx root 5792 12.6 14.0 3.52M 1.12M ? S 1:50 /NextApps/Terminal -MachLau me 5845 2.8 4.7 1.34M 384K p2 S 0:01 - (csh) root 2 0.0 1.8 1.27M 144K co S 0:40 /etc/mach_init -xx root 3 0.0 0.0 2.39M 0K ? S 0:02 /usr/etc/kern_loader -n root 52 0.0 1.2 1.24M 96K ? SW 0:07 /usr/etc/syslogd root 57 0.0 2.1 4.37M 168K ? S N 0:49 /usr/etc/nmserver root 61 0.0 0.7 1.23M 56K ? SW 0:08 /usr/etc/portmap root 64 0.0 0.7 1.25M 56K ? SW 0:09 /usr/etc/nibindd root -1 0.0 0.0 0K 0K ? S 0:00 <mach-task> root 68 0.0 1.2 1.33M 96K ? SW 5:34 /usr/etc/lookupd root 77 0.0 0.0 1.24M 0K ? SW 0:00 /usr/etc/inetd root -1 0.0 0.0 0K 0K ? SW S 0:00 <mach-task> root 8i8 0.0 0.4 1.29M 32K ? SW 0:05 /usr/lib/lpd root 93 0.0 2.1 1.70M 7 6K ? SW 1:14 /usr/etc/pbs root 1 0.0 0.2 1.31M 16K ? SW 0:01 /usr/etc/init -xx root -1 0.0 0.0 0K 0K ? ?W< 0:00 <mach-task> root -1 0.0 0.0 0 K 0K ? S 1:14 <mach-task> root 112 0.0 0.8 1.31M 64K ? SW 1:10 update root 115 0.0 1.5 1.31M 120K ? SW 0:50 cron root 65 0.0 1.0 1.29M 80K ? SW 4:13 /usr/etc/netinfod local root 83 0.0 0.8 1.34M 64K ? SW 0:08 /usr/libsiendmail -bd -q1h root 7K9 0.0 0.4 2.79M 32K ? SW 0:14 - console (loginwindow) root -1 0.0 0.0 0K 0K ? S 0:39 <mach-task> me 4171 0.0 8.1 6.16M 664K ? S 8:12 /usr/lib/NextStep/Workspace me 4172 0.0 0.0 1.25M 0K p0 SW 0:00 Console Daemon me 5436 0.0 3.1 3.66M 256K ? SW 0:04 /NextApps/Webster -MachLaun root 95 0.0 0.4 1.34M 32K ? S N 0:03 /usr/etc/autodiskmount me 5793 0.0 1.3 1.34M 104K p1 SW 0:01 - (csh) me 5803 0.0 0.9 824K 72K p1 SW 0:03 kermit me 5804 0.0 0.9 824K 72K p1 SW 1:06 kermit root 582 e 0.0 . 9 3.52M 480K ? S 0:06 /NextApps/Preferences -Mach root 98 0.0 1.9 3.97M 152K ? S 5:38 /usr/lib/NextPrinter/npd root 0 0.0 20.0 14.2M 1.60M ? R 238r8 (kernel idle) Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
barry@pico.math.ucla.edu (Barry Merriman) (06/16/91)
In article <1991Jun15.193723.14916@math.ucla.edu> barry@math.ucla.edu (Barry Merriman) writes: >In article <SCOTT.91Jun15011146@mcs-server.gac.edu> scott@mcs-server.gac.edu (Scott Hess) writes: >> >>I'll give a short list of some launch times for a couple apps on the >>NeXT. These are not hard& fast measurements. It's a relatively >>unloaded system, and I'm basically estimating the times. The hardware >>is a stock NextStation400/16, with nothing else (except the modem I'm >>talking to you through): > >I'll throw in some comparison times from my home machine, which >is a NeXT Cube, *030*, 8MB RAM, 330MB Maxtor HD (68MB free) >(timed using the Preferences clock with seconds showing) And here are times from my office machine, which is a NeXTStation 105/8 running off a network. I'll denote launches by "net" and "loc" to indicate wether it was an app on local disk or on a disk on the network (incidentally, the network disk I mount is on a Cube/040/24MB/330MBMaxtor) > >>Edit: 1.5s > 22s 10s (net) >>IB: 3s > 22s 10s (net) >>Librarian: 4s > 24s 14s (net) >>Mail: <3s > 19s 4s (net) >>Preferences: 5s > 25s 8s (net) >>Preview: <2s > 12s 6s (net) >>WriteNow: 3s > 16s 6s (net) >>Stuart: 3s > 18s 5s (net) >>Improv 4s > 25s 15s (loc) >>Diagram: 5s > 59s 13s (loc) >>Mathematica -- > 22s 11s (net) When I launch local stuff, there is swapping that occurs. I expect this to get much better when I upgrade to 20MB RAM, shortly; judging from the above stats, I could get a factor of 3 in launch times. Note that the change from 030->040 gave roughly a factor of 2--3 improvement as well. -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy)) (06/16/91)
For "comparison" here are my launch times on a 400/20MB slab;
When the applications were launched I had the following running:
Emacs,
Stuart with two shells
Cassandra with the screensaver
Kermit.
After launch all applications remained in place.
Edit 1.2 s
Mathematica <6 s
WriteNow <6 s
Improv with API kit < 12 s
Stuart (reopening) <2 s
and above all TeX:
hardy{tex/Wavelets}[54>time latex wavelets
This is CTeX, NeXT Version 3.1a
(wavelets.tex
LaTeX Version 2.09 <7 Dec 1989>
(/usr/lib/tex/inputs/report.sty
Document Style `report' <13 Nov 89>.
(/usr/lib/tex/inputs/sizemac.tex (wavelets.aux)) [1] [2] [3] [4] [5] [6]
[7] [8] [9] [10] [11] [12]
[13] (wavelets.aux) )
Output written on wavelets.dvi (13 pages, 38904 bytes).
Transcript written on wavelets.log.
4.470u 0.485s 0:05.42 91.3% 0+0k 1+6io 0pf+0w
The only objective measurement is the LaTeX time, which is impressive,
while all the other applications (except Mathematica) are open
With mathematica Loaded (but nothing running) the same process took:
Transcript written on wavelets.log.
4.300u 0.516s 0:06.50 74.0% 0+0k 3+6io 0pf+0w
And while mathematica was evaluating a small notebook
4.298u 0.529s 0:15.18 31.6% 0+0k 19+7io 0pf+0w
I don't exactly know what Barry's three times mean; the ones I listed
are until the opened document appears on the screen.
Oh yes -- for what it's worth: vm_stat:
Mach Virtual Memory Statistics: (page size of 8192 bytes)
Pages free: 146.
Pages active: 235.
Pages inactive: 1880.
Pages wired down: 182.
Draw your own conclusions.
Greetings,
Hardy
-------****-------
Meinhard E. Mayer (Hardy); Department of Physics, University of California
Irvine CA 92717; (714) 856 5543; hardy@golem.ps.uci.edu or MMAYER@UCI.BITNETbarry@pico.math.ucla.edu (Barry Merriman) (06/16/91)
In article <HARDY.91Jun15225916@golem.ps.uci.edu> hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy)) writes: > For "comparison" here are my launch times on a 400/20MB slab; >Edit 1.2 s >Mathematica <6 s >WriteNow <6 s >Improv with API kit < 12 s >Stuart (reopening) <2 s >I don't exactly know what Barry's three times mean; the ones I listed >are until the opened document appears on the screen. in the times I computed, it was time from double clicking til all windows and menus had appeared. The above times look promising---I can't wait to upgrade to a 660/20MB confuguration. -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
Irving_Wolfe@happym.wa.com (06/16/91)
I don't have any numbers either, but moving over from my 20 MB slab to an associate's 8 MB slab to help her with something is an awesome experience. The speed difference is comparable to life vs. death.
samurai@cs.mcgill.ca (Darcy BROCKBANK) (06/17/91)
In article <1991Jun15.085335.4605@neon.Stanford.EDU> zimmer@calvin.stanford.edu (Andrew Zimmerman) writes: >Maybe I didn't make myself clear in my original posting. I have >heard conflicting reports whether additional memory makes a significant >performance improvement on the NeXT. As such, I asked for specific metrics >of improvement, not for comments like > it's OK if it takes 4 minutes to print a page, > 10 minutes to log in, etc. >Such comments really don't help, and only clutter the already overcrowded >newsgroup. What clutters the newsgroup is quoting the entire article and adding a couple of comments at the end. I found EPS's comments meaningful. Everything speeds up considerably on memory upgrade. >BTW, I do use my NeXT like a you-know-what computer (a DEC 3100). Even with >the 8 Meg limit, I'm pretty happy with it. That is too bad. Why don't you just stick with the DEC then? I just had my memory upgraded from 8M to 16M on a networked cube, and using it is heaven! Logging in is VERY fast, and keeping multiple applications running is more realistic. Edit does not have to go to disk each time it opens a window. I can keep Apps hidden, and in memory so they are there when I ask for them. I think that the sports car analogy is good. What can you do with the fast engine if you are always stopped for gas? - db
mdixon@parc.xerox.com (Mike Dixon) (06/18/91)
Here's a snapshot of my ambient processes for the above experiments:
(If you have any tips to speed things up, let me know!)
feynman>ps -augx
USER %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND
root 121 27.9 2.0 1.24M 160K a R 166h h- std.9600 ttya (getty)
me 878 14.3 33.4 7.43M 2.67M ? S 374:03 - console (WindowServer)
...
here's a tip: that first line says that over 1/4 of your cpu time is
being wasted on a getty process that's waiting for someone to log on
over serial port a. this happens because of some screw up that sends
getty into a loop repeating the login prompt over and over and over
again when the device on the other end of the line is turned off/not
responding. there doesn't seem to be a good way to fix it yet; i
su and 'kill -STOP' the getty process (you then have to 'kill -CONT'
it again before you'll be able to log in). (i wrote a little perl
script to do this semi-automatically).
if you find a better solution, i'd like to hear about it...
(some posts have claimed that switching to ttyda made the problem
go away; that didn't reliably fix it for me.)
.mike.
--
.mike.SAMcinty@exua.exeter.ac.uk (Scott McIntyre) (06/19/91)
I finally got my NeXT, by the way...and I love it. But I had to settle for the 12mb colour slab since memory was so expensive over here... According to the rom monitor, it's 100ns ram...can I mix faster, or do I have to get 100ns? I am thinking about getting more ram, at least another 8megs, maybe more, but the local suppliers only do the proper chips in 80ns speeds, will this cause any problems? Scott -- mcintyre@nsfnet-relay.ac.uk Scott A. McIntyre SAMcinty@uk.ac.exeter.exua Cornwall House S_MCINTYRE@uk.ac.lut.hicom St. Germans Road mcintyre.s@uk.ac.exeter Exeter, Devon, UK
jchin@wimsey.bc.ca (Joseph Chin) (06/20/91)
I have just upgraded my NeXTstation Colour from 12MB RAM to 20MB, and the performance increase is just dramatical! The system no longer thrashes at the hard drive whenever I have more than one application loaded up. The power of the 68040 is finally showing through! I strongly recommend this upgrade to all owners of the 12MB NeXTstation Colour. It is worth every penny of it. EPS and Scott have been right all along (re: more RAM = better performance), and I have been a strong believer in that philosophy which has proven its worth today! I got my RAM from South Coast Electronics (714-669-9503). They have the 1MBx32-bit SIMM required by the NeXTstation Colour. The retail price for the 8MB NeXTstation Colour RAM kit is around $600 (less if you are a reseller). BEWARE: Adding memory to the NeXTstation Colour is NOT an easy task. The sockets are quite stiff and you can easily damage them if you don't know what you're doing. Pay a certified techie to do it for you if you are not sure of your abilities. Standard disclaimers apply ... :-) Joe -- Joseph Chin Wordcraft Systems Corporation jchin@van-bc.wimsey.bc.ca 201-434 West 12th Avenue (604)879-9687 (voice & NeXTfax) Vancouver, B.C., Canada V5Y 1V3 ********************* NeXT Registered Developer ********************
eatme@iastate.edu (Swanlund David L) (06/21/91)
Hey everybody. So I can't remember anything. Do color stations come with parity memory? I want to get some more for our color slab(which is due to arrive next week), but I can't remember the discussion on the subject. Many thanks... dave NeXTMail to: david@pv5028.vm.iastate.edu regular email: eatme@iastate.edu