blue@techunix.BITNET (Baruch Cochavy) (10/03/89)
Hello ,
We are now in the process of looking into running DG/UX on our
old MV/4000 and MV/2000. Can anyone comment on that, or supply some
performance comparisons, preferably based upon practical experience
of such an upgrade ?
Also, and I realize this is not the best news group to handle
it, can someone comment on the AViiON, or compare it to VAX11/780 or
something else in the same range ?
Thanks in advance,
Baruch Cochavy
blue@techunix.technion.ad.IL
blue@techunix.BITNETjohn@amc-gw.UUCP (John Sambrook) (10/04/89)
In article <8758@discus.technion.ac.il> Baruch Cochavy writes: > We are now in the process of looking into running DG/UX on our >old MV/4000 and MV/2000. Can anyone comment on that, or supply some >performance comparisons, preferably based upon practical experience >of such an upgrade ? In a previous position at the University of Washington, I was responsible for converting from AOS/VS 5.something to DG/UX 1.0 on a DG MV/10000. Of course, there were a lot of problems, but performance (when the machine was running :-) wasn't one of them. It took a few revisions of DG/UX to get the most serious problems resolved, but when I left the position we were at revision level 3.11 of DG/UX and the machine was working reasonably well. I would also point out that DG/UX is a great development (or at least testing) environment, if you are developing UNIX applications! Why is this? Well, you have a couple of things going for you: 1. You have a machine that is almost legend within the C / UNIX community. If you don't understand how to write clean C code, spend a few years on an MV, and you will soon learn to properly type your pointers, and you will become intimately familiar with the argument types of the various library routines! 2. You have an excellent C compiler. It's well documented, it works, and it has about every option you could imagine to help you debug bogus code. 3. I was excited about the new debugger in DG/UX 4.0, but never got to use it. It really looked like a great tool. I'd be interested in knowing how it worked out. > Also, and I realize this is not the best news group to handle >it, can someone comment on the AViiON, or compare it to VAX11/780 or >something else in the same range ? Comparing it to an 11/780 would be rather odd. Maybe you should compare it to something like a Sun Sparcstation or a DEC PMAX. John Sambrook DNS: john@amc.com Applied Microsystems Corporation UUCP: amc-gw!john Redmond, Washington 98073 Dial: (206) 882-2000 ext. 630 P.S. Hi Karl. -- John Sambrook DNS: john@amc.com Applied Microsystems Corporation UUCP: amc-gw!john Redmond, Washington 98073 Dial: (206) 882-2000 ext. 630
gary@dgcad.SV.DG.COM (Gary Bridgewater) (10/06/89)
In article <8758@discus.technion.ac.il> blue%techunix.bitnet@jade.berkeley.edu (Baruch Cochavy) writes: > We are now in the process of looking into running DG/UX on our >old MV/4000 and MV/2000. Can anyone comment on that, or supply some >performance comparisons, preferably based upon practical experience >of such an upgrade ? Yes. DG/UX is a simpler operating system than AOS/VS. Since the iron is the same, executing fewer instructions makes DG/UX run 'faster'. Since the OS does less for you you have to do more for it. This is completely analogous to AOS vs RDOS and is why people who were happy with RDOS were unhappy with AOS. DG/UX is more complicated that RDOS. Example: DG/UX does highest priority, first-come first-served scheduling vs AOS/VS's round robin, hueristic scheduling. This makes for quicker scheduling decisions under DG/UX and is what Unix users want but it may come as a surprise to people running multiple cpu-bound jobs who are used to AOS/VS. On the other hand, DG/UX has nothing to compare with Batch - you have to roll your own. But, in general, AOS/VS and Unix are both minicomputer oriented, multi- user operating systems. They both want to provide the same sorts of services and they generally expect the user to be logged onto a terminal. Its hard to go much beyond that since you provide no indication of what you are currently using the systems for and/or what you plan to do with them under DG/UX. But if you just want Unix then you will get it. Be sure to get 4.02. MV DG/UX is a meld of primarily Sys V 5.3 with BSD 4.2 extensions ( streams, job control, Berkeley 4.2 TCP/IP). The MV C compiler and the linker are 99% the same as AOS/VS. You can move .obs back and forth to some extent (this may change, but it is handy while converting). Of course this excludes anything that is OS specific like sys_xxx calls. DG/UX should not be confused with MV/UX in any way. > Also, and I realize this is not the best news group to handle >it, can someone comment on the AViiON, or compare it to VAX11/780 or >something else in the same range ? Running DG/UX 4.10 using the GNU compiler, its seems to be on a par with our Sun 4/280. My AViiON 310 has a 189MB shoebox disk while the Sun 4 has 2 900MB Fuji disks so I lose a lot in terms of swapping, file I/O, etc. I get it back in quicker CPU cycles. In terms of our MV systems - it kicks an MV/20000 in the teeth. I don't have a local 40000 to compare to. An MV/20000 is about twice an MV/10000sx and an MV/10000sx is about 1.5 a VAX 11/780. (An MV/10000sx is about 2.5x an MV/4000 .) Running X, I can paint the screen in about the time a Sun 3/60 takes to clear the screen and define the window borders. These aren't hard numbers but then this isn't comp.arch and I'm not Bob Cousins. :-> AV DG/UX 4.10 is a meld of SysV 5.3+4 and BSD 4.3 with a twist of POSIX and 88K OPEN. I speak as a user only and these are my own observations. -- Gary Bridgewater, Data General Corp., Sunnyvale Ca. gary@sv4.ceo.sv.dg.com or {amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary No good deed goes unpunished.
mlewis@unocss.UUCP (Marcus S. Lewis) (10/07/89)
From article <1156@svx.SV.DG.COM>, by gary@dgcad.SV.DG.COM (Gary Bridgewater): > in quicker CPU cycles. In terms of our MV systems - it kicks an MV/20000 > in the teeth. I don't have a local 40000 to compare to. An MV/20000 is > about twice an MV/10000sx and an MV/10000sx is about 1.5 a VAX 11/780. > (An MV/10000sx is about 2.5x an MV/4000 .) OK, I'll bite on that. I read comp.arch too ;-> I manage an MV/20 and for kicks the other day (while the system was loaded) I moved a rather large (600K+) file around the system disk. And the numbers are appallingly low, roughly 80KB/sec throughput from a directory on the system disk to @NULL. This is on a system with about 90 people logged in, on Argus disks. This does NOT compare well with standalone PC disk throughput as reported in comp.arch. But then, this is an apples-and-oranges comparison, right? How does the Aviion kick a 20 in the teeth? Screen painting? I have a circa 1976 8080 that paints the screen faster than a 20, but it is using full memory bandwidth to do it, while the 20 is limited to 9600 baud. So? Believe it or not, I believe your informal comparison, even in general. I submitted an article to DG Review on RISC in general which goes into detail why the Aviion is so much faster than an MV. Something about cycle time. One of the comparisons I came up with that has gotten a chuckle or two is Aviion == Shelby Cobra, MV/20 == 3/4 ton pickup with everything, plus a Cummins diesel engine. It takes real guts to push a Shelby to its limits, and not every driver is even going to try. But even I could make a Dodge truck strain. Try dragging cows around, like my dad, in a Cobra. My point is (with the above comparison) that you can't honestly compare a CISC machine with a proprietary OS to a RISC running a customized generic OS. They aren't doing the same things. Marc -- --------------------------------------------------------------------------- Na khuya mne ehto gavno? | Internet: cs057@zeus.unl.edu preferred machine->| UUCP: uunet!btni!unocss!mlewis ---------------------------------------------------------------------------
gary@dgcad.SV.DG.COM (Gary Bridgewater) (10/09/89)
In article <2016@unocss.UUCP> mlewis@unocss.UUCP (Marcus S. Lewis) writes: >From article <1156@svx.SV.DG.COM>, by gary@dgcad.SV.DG.COM (Gary Bridgewater): >> blah, blah, blah >I manage an MV/20 and for kicks the other day (while the system was >loaded) I moved a rather large (600K+) file around the system disk. And >the numbers are appallingly low, roughly 80KB/sec throughput from a >directory on the system disk to @NULL. This is on a system with about >90 people logged in, on Argus disks. This does NOT compare well with >standalone PC disk throughput as reported in comp.arch. But then, this >is an apples-and-oranges comparison, right? right. But how did you move it? move/buff=32768 or cop/imtr=32768 speed that up. The cli was optimized for small memory aos systems. Sigh. This is why DUMP_II and LOAD_II (and DUMP_III/LOAD_III) act like they came from another planet when compared to dump and load. >How does the Aviion kick a 20 in the teeth? Screen painting? I have a >circa 1976 8080 that paints the screen faster than a 20, but it is using >full memory bandwidth to do it, while the 20 is limited to 9600 baud. Actually, I was talking bit-mapped. The screen is 1280x1024 pixels on which I bring up a 70 line 136 char wide xterm window. And the comparison was to a (what is it?) 980 x 856 Sun 3/60 with a 62 line 132 char wide window. In terms of asynch, I hooked up a 9600 line MV/20 console line and can use the AViiON as a terminal emulator. But why are you running your terminals at 9600 baud on an MV/20? Run 'em up to 19.2 or 38.4 if you have the newer boards/terminals. >So? Believe it or not, I believe your informal comparison, even in >general. I submitted an article to DG Review on RISC in general which >goes into detail why the Aviion is so much faster than an MV. Something >about cycle time. One of the comparisons I came up with that has gotten >a chuckle or two is Aviion == Shelby Cobra, MV/20 == 3/4 ton pickup with >everything, plus a Cummins diesel engine. It takes real guts to push a >Shelby to its limits, and not every driver is even going to try. But >even I could make a Dodge truck strain. Try dragging cows around, like >my dad, in a Cobra. The MV/20s we use here are dual-cpu with 64MB and triple IOCs. They are a bit more than a 3/4 ton pickup. But your metaphor is compelling. A big hog MV/20 can handle a lot of users with reasonable response but just one user still gets just a bit better than that. An AViiON kicks right in but I haven't tried a bunch of users since we don't have any big servers yet. We do have a lot of users on a smaller MV/20-I running DG/UX and it runs quite well under load. >My point is (with the above comparison) that you can't honestly compare >a CISC machine with a proprietary OS to a RISC running a customized >generic OS. They aren't doing the same things. Agreed, but the original poster wasn't very specific and I don't have a VAX so I synthesized the MV numbers to get near one. As with anything else, however, the performance you get is a very big function of what you expect. I have seen sites with 20 people running on a Nova 3 with 32Mb and they were tickled pink. It got the work done in the time they wanted it done. So I say user MIPS, WHETSTONES, US STEEL, etc. to narrow the field to those systems that could do the job, then try YOUR job on them. -- Gary Bridgewater, Data General Corp., Sunnyvale Ca. gary@sv4.ceo.sv.dg.com or {amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary No good deed goes unpunished.