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.
--Karl
scarter@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
johno@dduck.ctt.bellcore.com (John OBrien) (04/04/89)
This has been a great discussion and it's good to see it hasn't degenerated into vendor bashing. Here's my perspective on the fast single processor vs. several "smaller" processors. This is not an endorsement for or against either vendor (can't do that if I want to keep my job). I've worked on both for quite some time with most of the work concentrating on the issues of multi-processor vs single processor. It is interesting to note that that vendors such as Pyramid (among others) have gone from uni-processor systems to multi-processor systems (Pyramid's 98xx series, DEC's 6000 series, etc) for various reasons (most of which are economic). So whether people like it or not, that is the way of the world. Several people have talked about the advantage of one fast processor for number crunching applications. However, that advantage disappears with the addition of just one more user. Simplistically, your single user CPU power is reduced by 50% with the addition of the second user. In a multi-processor environoment, it more users for the system to lose that amount of power. In reality, the capabilities of a multi-processor architecture are limited by the ability of the operating system and architecture to efficiently handle the processors and the interactions between them. John O'B
kirk@sequent.UUCP (Kirk Woods) (04/04/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. Performance is an interesting problem. What aspects of performance are you measuring. For me the only performance that matters is how quickly the computer responds to my request. Before I started using a Sequent S81 with 8 processors, I was using an Intel 80386 based workstation running Xenix. This workstation was hooked into a LAN with typically 20 system processes running. When I went about my usual routine I would typically be running another 10 processes. I was the only user on this workstation and response time was very nice after being on an 18 user VAX 11/750. The response time on the S81 with 8 Intel 80386 micorprocessors with over 400 processes is much better than the single processor workstation with less that 1/10th of the number of processes. This analysis is based on how the system feels as opposed to any benchmark. On the price side, I think you will find a Sequent Symmetry system for 30 software engineers, much more cost effective than 30 workstations; not to mention the additional cost of software and administration for eacht workstation. These are definitely my own opinions and not that of Sequent's. Kirk Woods
mhm@mace.cc.purdue.edu (Michael Marsh) (04/06/89)
In comparing uniprocessors with multiprocessors, some years ago IBM did a study that showed that there are situations where a multiprocessor system has certain advantages over a monoprocessor that is "twice as fast". These are in the areas of interrupts and context switching. Large, fast machines tend to get a lot of their performance from techniques such as sophisticated caches, I/O processors, pipelining. large register sets, and the like. These mechanisms work most efficiently on large jobs using sophisticated compilers which take advantage of the architectural oddities of the particular machine. (Sound like the place to do batch processing? Yup!) Context switching and interrupt processing break these machines, and that is just what you get a lot of with 300 logged-on users. As you add more users to a large monoprocessor, a point will be reached where the system is spending all it's time context switching. A multiprocessor can handle more of this activity before degrading (if designed properly). A second advantage to the multiprocessor architecture is that an interrupt need "interrupt" only one processor, and in some implementations, (sequent's, for one) the interrupt is handled by the processor running the lowest priority process, leaving the more important processes to run uninterrupted. On a monoprocessor, even high priority jobs are prempted by interrupts. There is a psychological advantage to the multiprocessor in that the performance tends to be very uniform over a wide range of loads, whereas a uniprocessor, although faster, will start to slow down quicker, leaving the users with the feeling that they aren't getting all they could out of the machine. Disclaimer: These are the opinions of the author and not necessarily those of Purdue University or Sequent.
rick@uunet.UU.NET (Rick Adams) (04/11/89)
In article <63900002@uxf.cso.uiuc.edu>, bob@uxf.cso.uiuc.edu writes: > the support folks at sequent are reasonable people who treat any problem you > encounter as THEIR problem and resolution is quick. Sorry, I can't let this go by unchallenged. The support people at Sequent are well meaning and try hard, but... In several of my dealings with them, they do not believe me when I say there is a problem and IF I can convince them that a problem exists, they MAY take the trouble to fix it. (I think the problem is not convincing the first level support people, but in getting whoever in engineering has the responsibility to accept that there might be a problem). Let's take a few examples: There is a bug in their X.25 software that leaves a process running and a user "logged in" after the connection has closed. The current "resolution" of this as I understand it (it's been a while) is that its not a bug. Well, since Dynix counts the number of users currently logged in and limits that number to whatever license size you bought, it's clearly a denial of service problem. (I still claim it's a bug in the X.25 driver) Reloading the X.25 software fixes things (and logs out anyone else who happens to be logged in). There is a bug somewhere in their TCP or IP such that when subjected to extremely high loads (Imagine what the SMTP load on uunet is when it's been off the Internet for a few days and suddenly 10,000 machines want to send it mail.) it "loses" SMTP connections requests. By lose I mean that there is a daemon running, listening on the port, but if you try and connect (even through the software loopback) you get NEITHER a connection accepted nor rejected. Its like the host is down. They don't believe this is a problem since they can't reproduce it in their "lab". Fortunately, this is a fairly rare problem, because I don't expect it to ever get fixed. Currently, we have a very serious problem with terminal ports hanging. This hang means that the Sequent totally ignores data sent from the terminal. Nothing short of rebooting will clear this hang. It's as if the driver were stuck in some flow control state that it can't be freed from. (The Sequent sends to the terminal fine). We have to reboot the system on a daily basis to free stuck ports. Obviously not a good situation for a production system. I'm not sure they believe this is a real problem, but it sure is for us. (We will ignore the kludgely "modem control" on their Systech boards. Same ugliness as Suns onthe ALM1) [This one should be easy to fix. It happens several times per day.] The basic problem with the Sequent product is that they have truly wonderful hardware and barely adequate software. People are buying their systems despite the software. Sequent is still, for the most part, shipping 4.2bsd (bugs and all). Their System 5 compatibility is not quite that old (4.2bsd is 7 years old now), but is only V.2 and is not very current. Sun is shipping current versions of Berkeley and ATT code. This is proof that you CAN do it despite claims about going through channels, quality control, etc. If a company the size of Sun (or even DEC) can ship the 1986 4.3BSD release, surely a smaller company like Sequent can ship it within 3 YEARS of release. Since this started as a Pyramid vs Sequent discussion, I should point out that Pyramid software is YEARS ahead of Sequent. I have no direct experience with Pyramid hardware (donations accepted...), but Pyramid software is clearly far superior to Sequents (despite the dual-universe abomination). Maintenance is an interesting issue. Sequent's hardware is so reliable and their software support so marginal that it is extremely tempting to do without a maintenance contract at all. (Yes, it's time for me to renew the maintenance contract...) Every week or two, someone who is considering buying a Sequent asks me how I like my Sequent. I keep telling them the same thing. The hardware's great, the software sucks. If Sequent would take half the time they spend screwing around searching for a better TP1 benchmark and put it into cleaning up the basic system (Just try and stay within 1 or 2 years of your competitors guys. I'm not asking for parity) they could have a truly great product. Judging from the people I've talked to, I bet they lose 10 sales a year because of software inadequacy. You'd think that would justify 1 single engineer to take programs off of the latest distribution tapes and compile them for the next distribution. I KNOW thats all it takes, since virtually all of the programs I use on a regular basis, I TOOK OFF THOSE TAPES. I've replaced all of the communications/networking programs. Thats why the system I have is usable. (If you're a Sequent user, get the berkeley networking tape. So far, all the programs I have tried compile and run with no problems.) The truly maddening part of all this is I bet I've talked to 25 different Sequent people in detail (including the president of the company, who I had dinner with at the last Sequent Users group meeting). Every one of them seemed very interested and concerned and wanted to help. But, if I were grading them it would have to be A for effort and C+ for product. I'm hoping for a major miracle in the next software release. I'm expecting, well... ---rick P.S. Overall, I don't think Sequent is really much better or worse than most other computer companies (Although, it's software is clearly behind). I don't want anyone to mistakenly believe that Sequent is the fantasy vendor that some people have been portraying.
abe@mace.cc.purdue.edu (Vic Abell) (04/11/89)
In article <52535@uunet.UU.NET>, rick@uunet.UU.NET (Rick Adams) writes: > In article <63900002@uxf.cso.uiuc.edu>, bob@uxf.cso.uiuc.edu writes: > > the support folks at sequent are reasonable people who treat any problem you > > encounter as THEIR problem and resolution is quick. > > Sorry, I can't let this go by unchallenged. Well, I can't let Rick Adam's statement go by unchallenged, either. :-) We acquired our first Sequent B8K in 1985 and now have two B21K's and a Symmetry. Other campus organizations have since acquired additional Sequent systems. We have found Sequent to be one of our most reliable and responsive vendors. We have always found them to be helpful with hardware and software problems. We have participated in several joint software ventures with them and have engaged in software and hardware development projects that benefited from their cooperation - porting Berkeley Pascal, a Multibus to UNIBUS converter, language testing and validation, etc. We have not encountered the problems that Rick Adams reports - our terminal connections go through our own ISN hardware and software, and we have upgraded the kernel's TCP/IP code to 4.3BSD-Tahoe. However, before we had the ISN connection, we used Sequent terminal multiplexors on our first B21K and had as many as 180 simultaneous users connected through them without problem. We have had many more problems with Sun's re-interpretations of current versions of Berkeley code, so their doing it proves little. Since I have both Sequent and Sun in the same class, I think Sun deserves the C+ for product; I would give Sequent a B+. Is Sequent perfect? Of course they aren't. Are they as good as CDC, DEC, IBM or Sun? I think they're better. I agree with bob@uxf.cso.uiuc.edu that the Sequent people are reasonable and helpful and I'm always pleased to recommend them to the many people who call me for references. Vic Abell Assistant Director Purdue University Computing Center