caanders@sactoh0.UUCP (Chris A. Anderson) (03/22/89)
We're a commercial health care claims management shop for large hospitals and clinics. We're currently looking at several possible hardware choices for replacing our aging Plexus (Sys V.2) computers. Two of the bids we have received are: Pyramid 9815 -or- Sequent S81 (4 processors) Both are configured with 32 Mb main memory, 8 Gb disk storage (yes, that's 8 Gigabytes), with terminal servers hooked via ethernet to the machine. We are committed for the nonce to System V. We plan on having 80-100 users, mostly running in-house database applications (file inquiry/update type stuff). Of those, approx. 20 are development people. The questions we have are: 1. Will having 80-100 users concurrently on the Pyramid degrade terminal response time signif- icantly? We have been told that the 9815 doesn't have the horsepower to service this number of users on ethernet. 2. Several people have said that the Sequent will not handle 8 Gb of storage with anything less than 8 CPU's installed. Is there any truth to this? Why? These questions are sparked by statements by the different vendors in question, and by responses to previous postings I've made to the net asking for information on the two machines. Anybody have any experiences that they care to share? By E-mail, please. If there's any interest, I'll post (or e-mail) a summary. Thanks in advance!!! Chris -- | Chris Anderson email : pacbell!sactoh0!utgard!chris | | QMA, Inc. or : ...!{csuchico,csusac}!fenris | |----------------------------------------------------------------------| | Of *course* I speak for my employer, would he have it any other way? |
dewey@sequoia.UUCP (Dewey Henize) (03/23/89)
In article <764@sactoh0.UUCP> caanders@sactoh0.UUCP (Chris A. Anderson) writes: [stuff I can't answer deleted] >Both are configured with 32 Mb main memory, 8 Gb disk >storage (yes, that's 8 Gigabytes), with terminal servers >hooked via ethernet to the machine. We are committed for >the nonce to System V. [stuff I can't answer deleted] > 2. Several people have said that the Sequent > will not handle 8 Gb of storage with anything > less than 8 CPU's installed. Is there any > truth to this? Why? > >These questions are sparked by statements by the different >vendors in question, and by responses to previous postings >I've made to the net asking for information on the two machines. > >Chris >-- >| Chris Anderson email : pacbell!sactoh0!utgard!chris | >| QMA, Inc. or : ...!{csuchico,csusac}!fenris | >|----------------------------------------------------------------------| >| Of *course* I speak for my employer, would he have it any other way? | I don't know about needing 8 CPUs - we run just about the same amount of disk with 6 and so far disk is simply not an issue (This is on a Sequent S81). It wouldn't seem that it is all that likely all your users will be using wildly different disk areas at the same times, but if they were then that would possibly make a difference. On the other hand, we run 48Mb of memory. Since a lot of memory is used in caching, I imagine that makes a large impact. I will say, though, that on occasion I've been able to tell that having the extra processors seems to make a large difference - several jobs have been running using very high proportions of a couple of the CPUs and the fact we had other CPUs available pretty well 'hid' this from the rest of the users. For what its worth... Dewey Henize -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | There is nothing in the above message that can't be explained by sunspots. | | execu!dewey Dewey Henize | | Can you say standard disclaimer? I knew you could. Somehow... | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
csg@pyramid.pyramid.com (Carl S. Gutekunst) (03/26/89)
In article <404@sequoia.UUCP> dewey@sequoia.UUCP (Dewey Henize) writes: >I will say, though, that on occasion I've been able to tell that having >the extra processors seems to make a large difference - several jobs have >been running using very high proportions of a couple of the CPUs and the >fact we had other CPUs available pretty well 'hid' this from the rest >of the users. This is a classic architectural question that the salescritters will belabor endlessly. Which is "better": a machine with a larger number of smaller CPUs (Sequent, Encore Multimax) or a smaller number of larger CPUs (Arix, Alliant, Celerity, CCI, DEC, Elxsi, Encore's new systems, Pyramid)? The idea of a large number of smaller processors was really radical at the time; and Sequent earned a lot of well deserved press for it. I'd long felt the old Balance was an ideal machine for introductory programming courses, simply because it was more difficult for one user to screw the others by soaking up all the CPU. Unfortunately, the same argument can also be used to buying a flock of IBM PCs. Recently Sequent has been going after OLTP, a market which I thought they should have been chasing long ago; here, the multiple small CPUs make more sense. The other side is that there simply are applications where you need to have that large CPU. Many problems simply can't be broken down and spread across multiple processors. And when users are running really parallel stuff, you can as solidly kill a multi-CPU machine well as its single CPU breatheren. Then there's the night-owls like me, who expect the machine to be damn fast when there's no one else on it. Anybody want to voice their thoughts on this one? I make the silly things, so I don't know what most people are interested it. <csg>
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (03/26/89)
csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
Anybody want to voice their thoughts on this one? I make the silly things,
so I don't know what most people are interested it.
For myself, trying to maintain the facilities for a large flock of
academic users, I am inclined to have a small number of heavy-duty
CPUs, so that when it's getting anything done, it's getting a great
deal done. And the tendency for one process to take over the system
is not what I'd call severe. It happens, but it's quite rare.
The faculty, on the other hand, seem to have more of an interest in
the sorts of problems that can't be addressed without a dozen or so
processors. From my perspective, I find some of their applications
somewhat peculiar, hence not especially practical, but the practical
has to be developed out of the theoretical and impractical anyway.
So we compromise :-). We use a dual-processor Pyramid (and a couple
of other Pyrs besides) as the department's central services machines,
getting the grunt, practical work done of pushing mail and news around
and doing heavyweight computationally-intensive things (e.g., network
simulations that run for 3 days), and generally being a connectivity
hub for these users; and we also have a MultiMax and a BBN Bfly which
are used exclusively by the faculty and grad students for their
theoretical, possibly `impractical' experimentation.
--Karlscarter@caip.rutgers.edu (Stephen M. Carter) (03/27/89)
In article <KARL.89Mar25181226@giza.cis.ohio-state.edu> karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes: >csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > Anybody want to voice their thoughts on this one? I make the silly things, > so I don't know what most people are interested it. > At Rutgers, we have about 5 Pyramids of various vintage. For the research department I am with, we have a 9810 with a 90x running standby duty. The 9810 is used mostly for publications/email and your various small jobs while parallel machines, image grinders, or Suns do the specific work. For what we use it for, we could not have made a better choice. It makes a great general purpose Unix box. We average about 20 users at a time, and on a good day, I haven't seen vmstat show more than 60% cpu usage. Hmm, if I had to pick two items off the top, I'd say that the Pyramid gets gold stars in: - I/O. With the IOP/TPE hardware, io is good. I am sure there are better cpu bang/buck machines out there (ie Sun-4), but if you need io power, Pyramid does well. -Hardware. Our 9810 just doesn't die (knock on simulated woodgrain). In the past 14 months, our two service calls were for the Wyse console. On the down side: I have seen nowhere in any Pyramid documentation any pointers to hardware documentation, configuration manuals, etc. The nice thing about Sun is that they are very open about hardware, and include basic configuration manuals, hardware documentation and the like with every product. My impression on Pyramid is that they rather hide this information from "us poor users". Am I right, or am I missing the order code for the service manuals someplace? There must be a better way than reverse enginering a dip switch to compute the address of a board. Now, for the Pyr folks, two questions: 1) We have a late model Fujitsu MC2444AC tape drive on a 9810 TPE. Tar,dump, and the rest all work fine. However, it will not boot a mini-root from tape. I've tried the release tapes from 3.something, 4.0, and 4.4. Does the drive (third-party, self installed) need special setup settings? It spins the tape of load point and the bar says <booted>. Hit the Z, and the tape spins for a few more seconds, and then the machine checkstops. 2) Like I said above, about the only time our 9810 gets rebooted is after a power failure. Otherwise, it stays up for 60-70 days at a time. Should a machine be rebooted after NN days to prevent software rot? Stephen Carter Rutgers-CAIP Center PO Box 1390, Piscataway NJ 08855-1390 scarter@caip.rutgers.edu
roc@sequent.UUCP (Ron Christian) (03/28/89)
In article <63984@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >The other side is that there simply are applications where you need to have >that large CPU. Many problems simply can't be broken down and spread across >multiple processors. And when users are running really parallel stuff, you >can as solidly kill a multi-CPU machine well as its single CPU breatheren. >Then there's the night-owls like me, who expect the machine to be damn fast >when there's no one else on it. Yeah, me too. For me, that's a holdover from the old Vax days, where you could get decent response only if you waited until 9:00 P.M. or so to do your stuff. On the Sequent machine, I got used to "thinking parallel", spawning background processes with reckless abandon. But occasionally, I needed a single process to finish quickly, and you're right, the machine just isn't "damn fast" when only one task is addressed. And yet... The Vax 11/750 (later 780) on which I cut my Unix teeth is noticeably slower than a single i386 with reasonable support. A single process on the Symmetry *does* go faster than what I used to see late at night on the old machines. It's just that I now expect more, I guess. Perhaps the late, lamented Cydrome had the right idea after all: A bunch of micros in parallel, and a very fast vector processor that they could dip into as necessary. I guess we'll never know, now. :-( The largest advantage, in my opinion, of having a lot of smaller processors, as opposed to a few large ones, is consistency of response. Regular users (as opposed to us "power users") expect a task to always take the same amount of time and are thrown off by the variation in response one sees on your typical uniprocessor machine. The most consistent response (assuming wide variation in number of tasks) is with a large number of processors. The best bang for the buck whilst meeting the first objective is to provide a large number of small processors. Then, if a processor isn't being used much, you haven't wasted much of your investment. But your point is legitimate. Sometimes a task just can't be parallelized. And sometimes a 386 just isn't fast enough. [It feels good to be participating in comp.sys.sequent again. I was out for awhile due to interviewing, and finishing up at Fujitsu, and moving to Beaverton, but things have quieted down now.] Ron
bob@uxf.cso.uiuc.edu (03/31/89)
We have 3 pyramids purchased years ago. one of them had to get swapped out it failed so miserably. we average 1 or 2 board failures every quarter. we have a source license with them and now we learn as of the current version of the operating system they will no longer provide source code (unless you 'subscribe' at the everyday low price of $2000/month) at the $1500 snapshot price. we do self-maintenance (and this is the only reason we still have these machines). the local sales office is absolutely the worst thing i've ever had to deal with. we subscribe to monthly PTF service (it's the ONLY reasonable and reliable way to get anything out of the support center) and refer to it as the "operating system of the month club". on the other hand we've had one sequent for nearly 5 years without any board failures (until an extremely ugly power glitch last friday -- Good Friday -- hmmm). it has recently been upgraded to a b21 and i have seen 126 concurrent users all editting and compiling with good response. i always use the analogy of a grocery store checkout lane. if you have a store-full of people trying to get out and there is only one checker you wait and wait. if there are four checkers, everyone, even the ones with full carts, get serviced quicker. we just bought a s81 for database users. if your choice comes down to more processors or more memory, go for the memory. in the long run you'll be ahead of the game. although since the system is easy scalable, you can add anything later simply by sliding in another board. (this really is the case as we added more processors and more memory when we upgrade to the B21) the support folks at sequent are reasonable people who treat any problem you encounter as THEIR problem and resolution is quick. "from the rumor mill" --- pyramid announced a big mis-server that now won't see light of day for another year or so. it is also rumored that at&t is going to buy pyramid. pyramid stock dropped more than 5 points recently.
cquenel@polyslo.CalPoly.EDU (48 more school days) (03/31/89)
The point I always have to make whenever this comes up: Suppose for the sake of argument you have a single processor machine on one side and an 8 processor machine on the other side with each processor exactly equal to 1/8 of the larger CPU. Suppose the prices and total performances are equal. My argument is that the mono-processor machine is more flexible because any process can chew on the while machine whenever/however it wants. I also claim that when the number of users is reasonably greater than 8, then it will be difficult to tell which machine you're using. I have equated number of users with number of active processes here. It is possible for one user to have 5 active processes (by "thinking parallel" :-) ) and it is possible to have 8 users and have only 5 active processes. I seem to hear some advocates of multi-processors using the old "gee it's neat when I've got all those processors to myself" argument, but I don't think this is a valid argument for a good general-purpose machine. If you are considering a working environment where there are more processors than your average number of active processes most of the time, then you would actually be better off with a mono-processor. Think about it. I have an 8 processor machine and I've spawned 7 processes. I'm only using 7/8 of the machine. If I were on the mono-processor, I'd be using 8/8 of the machine, and (!) all my tasks would finish sooner. Even though I was sharing. It all boils down to this: The burden of proof is on the multi-processing manufacturer. They have to prove they can offer enough MORE bang/buck to counter act any difficulties introduced by multiprocessing. In a heavy multi-user environment where the number of active processes is almost always greater than the number of processors, and you don't have any single process taking up the majority of the machine's resources, then a multi-CPU machine will work very much the same way as a mono-processor machine. If you have a heavy number crunching grind-it-out program, then you will have to "parallelize" it in order to take advantage of any potential bang/buck advantage in a multi-CPU system. Anyway, enough for now. --chris "Virtual" means never knowing where your next byte is coming from. -- @---@ ------------------------------------------------------------------ @---@ \. ./ | Chris Quenelle (The First Lab Rat) cquenel@polyslo.calpoly.edu | \. ./ \ / | Better Red than dead ! | \ / ==o== ------------------------------------------------------------------ ==o==
rwood@vajra.uucp (Richard Wood) (04/01/89)
Cquenel@polyslo.CalPoly.EDU (48 more school days) writes: > > Suppose for the sake of argument you have a single processor > machine on one side and an 8 processor machine on the other side > with each processor exactly equal to 1/8 of the larger CPU. > Suppose the prices and total performances are equal. If your premises listed above were true, then much of your arguement below would be true as well. The significant error is to assume that a single CPU machine and a multiprocessor (with equivalent amounts of aggregate power) would have the same price. If all other design elements were pretty much the same, the multiprocessor should cost less. What are the arguments for the multiprocessor costing more? Significantly more complex design, with caches, probably a faster bus. On the other hand, the single CPU would have to be built with technology that is substantially more complex than the eight. For instance, today's '386 chips can be designed very easily to get 3 or so MIPS of power (more with a more expensive design). You can't get a '386 running 24 MIPS (eight times faster). Theoretically, you could, if you built it out of ECL or something. But that single CPU would no longer be a chip - it would now be a multichip design. The cost of designing that board will be substantially higher than the cost of designing the basic CPU subsystem in the multiprocessor. Even more importantly, the cost of manufacturing and servicing it would be very, very much higher. A final, but certainly not insignificant detail, is that the multiprocessor is going to get to market *A LOT* faster, due to the simpler overall design. Admiral Grace Hopper (inventor of Cobol) likens it to a farmer that suddenly needs to plow a field twice as big as his ox can handle. The single-CPU paradigm would have him buy an Ox that is genetically engineered to be twice as big, and twice as powerful. The multiprocessor paradigm would argue for simply getting a second ox. Any farmer could tell you which would be cheaper :-) The basic rationale is that it is cheaper to use off the shelf technologies as building blocks, instead of designing new processors for each and every generation. > My argument is that the mono-processor machine is more flexible > because any process can chew on the while machine whenever/however > it wants. No one will argue with you. A single source of cycles will always be able to allocate them with more flexibility. This actually follows directly from queuing theory. > I also claim that when the number of users is reasonably greater > than 8, then it will be difficult to tell which machine you're > using. I have equated number of users with number of active > processes here. It is possible for one user to have 5 active > processes (by "thinking parallel" :-) ) and it is possible to have 8 > users and have only 5 active processes. It actually happens (at least under Unix) even without "thinking parallel," although that does dramatically increase the flow. Sit down at a single user workstation sometime and do a "ps ax | wc -l". All the background stuff Unix does can take advantage of those "other" CPUs. (I.e., my workstation has 45 processes listed, and I'm hardly doing anything - true, most of those will wait hours before seeing action). A prime example is the inherent multiprocessing that is showing up in todays computing model. The window I'm editing in right now taps several different processes, including the editor, the terminal emulator (wish I had xrn...), the X-Server process, some NFS daemons on my local machine, and some on the server somewhere else in the building. > I seem to hear some advocates of multi-processors using the old > "gee it's neat when I've got all those processors to myself" > argument, but I don't think this is a valid argument for a > good general-purpose machine. > > If you are considering a working environment where there > are more processors than your average number of active > processes most of the time, then you would actually be better off > with a mono-processor. Think about it. Except, perhaps one should take into account the fact that the monprocessor is going to cost dramatically more, as explained above. There is some "clumsiness" about using a multiprocessor in a non-parallel processing environment, but the cost payoff can be dramatic. And > I have an 8 processor machine and I've spawned 7 processes. > I'm only using 7/8 of the machine. If I were on the mono-processor, > I'd be using 8/8 of the machine, and (!) all my tasks would > finish sooner. Even though I was sharing. > > It all boils down to this: > > The burden of proof is on the multi-processing > manufacturer. They have to prove they can offer > enough MORE bang/buck to counter act any difficulties > introduced by multiprocessing. The burden of proof should *always* be on the person trying to sell, regardless of what they're selling. There are tradeoffs in every decision. For this kind of purchasing problem, the questions are two: Do I have an environment that makes full use of multiple processors? If no... Is the presumably decreased cost of the multiprocessor worth the loss of flexibility in how I use the machine? > If you have a heavy number crunching grind-it-out program, > then you will have to "parallelize" it in order to take > advantage of any potential bang/buck advantage in a multi-CPU > system. There is another way that "heavy number crunching" programs can take advantage of a multiprocessor: concurrency. Run multiple versions of the same program simultaneously on different data sets. This assumes two things: first, that there are different data sets that need to be processed; if you only have the need to run one simulation at any time, for instance, then this wouldn't be the case. Second, it assumes that throughput is a reasonable substitute for response time. If having ten jobs done in ten minutes isn't as good as having one job done in one minute, than the thumper (to use a motorcycling term) is the proper tool. [A thumper is a single cylinder engine; the obvious analogy is left as an exercise for the reader] -- ---------------------------------------------------------------------------- Does it need saying that I'm not speaking as an official representative of DEC? =============================================================================== Richard Wood ! U. S. Worksystems, Palo Alto ! Digital Equipment Corporation
cook@pinocchio.Encore.COM (Dale C. Cook) (04/03/89)
In article <9903@polyslo.CalPoly.EDU> cquenel@polyslo.CalPoly.EDU (48 more school days) writes: >The point I always have to make whenever this comes up: > >Suppose for the sake of argument you have a single processor >machine on one side and an 8 processor machine on the other side >with each processor exactly equal to 1/8 of the larger CPU. >Suppose the prices and total performances are equal. > Good analysis, 48 more school days! However, I think you overlook the time lost to context switching and scheduling with the single compute engine. In the Alliant (and I think Convex) boxes, a lot of the work of executing concurrent DO loops is done in the hardware. Thus the scheduler only need incur the overhead of setup once per loop. Also, as another poster pointed out, the costs of a single hot box (Cray, NEC, etc) far exceeds N x's the minisuper cost. That defines the niche that every parallel minisuper maker has targeted. On the general purpose multi-processing side, I doubt that the "latency" and general interactivity (is that a word?) of a single processor being rapidly rescheduled amongst a large number of users will ever approach that of a multiheaded machine such as an Encore or Sequent. That's mostly subjective, but I think it's real. - Dale (N1US) INTERNET: cook@pinocchio.encore.com UUCP: {buita || talcott || husc6 || bellcore} !encore!pinocchio!cook
jlm@motcsd.UUCP (Jeffrey L. Morris) (04/06/89)
In article <68000001@uxf.cso.uiuc.edu> bob@uxf.cso.uiuc.edu writes: > >We have 3 pyramids purchased years ago. one of them had to get swapped out >it failed so miserably. we average 1 or 2 board failures every quarter. >(deleted) >on the other hand we've had one sequent for nearly 5 years without any >(deleted) >we just bought a s81 for database users. if your choice comes down to more >(deleted) >the support folks at sequent are reasonable people who treat any problem you >encounter as THEIR problem and resolution is quick. > >"from the rumor mill" --- pyramid announced a big mis-server that now won't >see light of day for another year or so. it is also rumored that at&t is going >to buy pyramid. pyramid stock dropped more than 5 points recently. My mistake, I thought this was the pyramid newsgroup, not comp.sequent.job.wanted !!! 8^) Newsgroups: comp.sys.pyramid Subject: Expires: References: Sender: Reply-To: jlm@csd.mot.COM (Jeffrey L. Morris) Followup-To: Distribution: world Organization: Motorola Computer Systems, Cupertino CA Keywords: Newsgroups: comp.sys.pyramid Subject: Re: Questions about Pyramid/Sequent Summary: Expires: References: <764@sactoh0.UUCP> <68000001@uxf.cso.uiuc.edu> Sender: Reply-To: jlm@V9.UUCP (Jeffrey L. Morris) Followup-To: Distribution: Organization: Motorola Computer Systems, Cupertino, CA. Keywords: In article <68000001@uxf.cso.uiuc.edu> bob@uxf.cso.uiuc.edu writes: > >We have 3 pyramids purchased years ago. one of them had to get swapped out >it failed so miserably. we average 1 or 2 board failures every quarter. >(deleted) >on the other hand we've had one sequent for nearly 5 years without any >(deleted) >we just bought a s81 for database users. if your choice comes down to more >(deleted) >the support folks at sequent are reasonable people who treat any problem you >encounter as THEIR problem and resolution is quick. > >"from the rumor mill" --- pyramid announced a big mis-server that now won't >see light of day for another year or so. it is also rumored that at&t is going >to buy pyramid. pyramid stock dropped more than 5 points recently. My mistake, I thought this was the pyramid newsgroup, not comp.sequent.job.wanted !!! 8^) #include <disclaimer.h> Jeffrey L. Morris {apple|hpda|pyramid}!motcsd!V9!jlm (408) 864-2066 -- #include <disclaimer.h> Jeffrey L. Morris {apple|hpda|pyramid}!motcsd!V9!jlm (408) 864-2066