david@ukma.UUCP (David Herron, NPR Lover) (05/09/85)
Anybody run 4.2 on a Micro-Vax II?
Were there any problems getting it up ( :-) )?
Or with uVaxI for that matter?
We're likely to be getting one soon and want to know what to run on it.
Any ideas on *real* performance?
Any other questions you'd like to answer?
--
--- David Herron
--- ARPA-> ukma!david<@ANL-MCS> or david%ukma.uucp@anl-mcs.arpa
--- Or even anlams!ukma!david@ucbvax.arpa
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
--- cbosgd!ukma!david
"The home of poly-unsaturated thinking".dave@uwvax.UUCP (Dave Cohrs) (05/11/85)
We have uVaxI's and run (basically) Ultrix on them. However, we have not
refrained from adding local fixes to this and have replaced the Ultrix
networking code with our very-hacked networking code. There are a number
of little differences between the uVaxI and a real Vax (like, lots of
intructions are emulated). The closest thing in 'real' vax land is the 730.
The uVaxI is slow. Period. However, DEC didn't promise speed on it, so...
The biggest problem is the disk. Next is the Qbus memory. The memory
problem is supposed to be better on the uVaxII (rumor). I have also
heard that the uVaxII is 70-80% a 780 in raw processor speed. There are
a couple problems with the current Ultrix release for the uVaxI (the
binary vmunix worked fine, however the source seems to be a bit older),
but we are hoping that these will be fixed with the next release. All
in all, the uVaxI isn't a bad machine, just don't expect miracles from
it. The uVaxII should really be nicer, but I'll know more abut this in
a couple months.
--
dave cohrs
...!{allegra,harvard,ihnp4,seismo}!uwvax!dave
dave@wisc-limburger.arpa
(bug? what bug? that's a feature!)root@bu-cs.UUCP (Barry Shein) (05/13/85)
I guess what I am more or less confused about is, why are people buying microvaxes? I can think of only a few reasons: 1. You run VMS, so you got no choices (you fool.) 2. DEC is giving them to you for free or nearly (good reason.) 3. You have significant applications that require the architecture specifically (macro code, q-bus periphs) 4. You have great expectations for the box. Seems from my analysis they are slower and more expensive than similar 68K boxes and promise to remain so for years, especially I/O (rumour has it that some of the 68020s will be approaching the compute speed of the 8600 for about 2% (20K/1M) the price this fall.) Other 32-bit processors (3B2 etc) have a similar outlook. Please, systems administration type responses, I'm really curious. We can probably save the 'service' claims, this is always contradictory, especially when DEC loves to tell you they can't fix it cuz it's UNIX. -Barry Shein, Boston University
snoopy@ecrcvax.UUCP (Sebastian Schmitz) (05/13/85)
Summary: Expires: References: <1736@ukma.UUCP> <uwvax.189> Sender: Reply-To: snoopy@ecrcvax.UUCP (Sebastian Schmitz) Followup-To: Distribution: Organization: European Computer-Industry Research Centre, Munchen, W. Germany Keywords: I will have a good look at a MicroVax 2 soon: its got its world-premiere here in Munich tomorrow. Watch this space for details. -- Love, Sebastian (Snoopy) "You haven't done it, till you've done it with pointers !" ( \!mcvax\!unido\!ecrcvax\!snoopy ) /* N.B. valid csh address */
dan@rna.UUCP (Dan Ts'o) (05/13/85)
In article <> root@bu-cs.UUCP (Barry Shein) writes: >I guess what I am more or less confused about is, why are people buying >microvaxes? I can think of only a few reasons: > > 1. You run VMS, so you got no choices (you fool.) > 2. DEC is giving them to you for free or nearly (good reason.) > 3. You have significant applications that require > the architecture specifically (macro code, q-bus periphs) > 4. You have great expectations for the box. > >Seems from my analysis they are slower and more expensive than similar >68K boxes and promise to remain so for years, especially I/O (rumour has >it that some of the 68020s will be approaching the compute speed of the >8600 for about 2% (20K/1M) the price this fall.) Other 32-bit processors >(3B2 etc) have a similar outlook. But MicroVaxen aren't really that uncompetitive. The MicroVAX I is slow, but so are many 68000 boxes. Using a series of Unix system benchmarks, the MicroVAX I running Ultrix-32m was neck and neck with the Callan. The Callan was faster in incrementing an int, but the MicroVAX I was faster at nroff, and thats what I care about. MicroVAX I and the Callan are similarly priced but with the MicroVAX you get VAX binary compatibility, 4.2BSD with Ethernet capability, and a wide range of Qbus peripherals to chose from. AT&T's 3B2 is in the same ballpark and it just as slow or slower. More expensive 68000 boxes like the Masscomp are faster but much more expensive. Meanwhile the MicroVAX II has almost 11/780 performance at under $20000. Its been said before: there is a major difference between chip performance and system performance. The 68000 chip is quite a performer, but I don't believe that your average $10000 68000 box delivers half that performance. You always lose in disk, memory management, floating point and communications.
snoopy@ecrcvax.UUCP (Sebastian Schmitz) (05/15/85)
Summary: Expires: References: <1736@ukma.UUCP> <bu-cs.391> Sender: Reply-To: snoopy@ecrcvax.UUCP (Sebastian Schmitz) Followup-To: Distribution: Organization: European Computer-Industry Research Centre, Munchen, W. Germany Keywords: Hello my avid ones, this is a newsflash from ECRC's reporter on the new DEC MicroVAX ][ machine:it had its world premiere in Munich. In the beginning this looked quite nice. The new MicroVAX ][ is the latest VAX: its a single chip VAX (so they say) and its claimed to have 80% of the power of a 780. Its meant to support up to 48 users but typically it will be less. Price wise it seems competitive: an MV ][ with a dual floppy amd integral streamer cassette tape (95 MB), 2MB Ram, 71 MB winchester and Ethernet interface will cost less than DM 100k. (For B-movie actor fans this means about US$ 30k) The backplane will support two controllers for discs but the floppy drive and tape drive are included so you can presently have at most 3 * RD 53 (@ 71MB each = 121 MB) in there with everything else. Why on earth will two controllers only support five discs ? 2.5 discs/controller doesn't look right somehow. In other words I don't know. The actual architecture: its a full VAX but of course no PDP11 compatibility mode. Its a Q-Bus machine and the memory is on a special 32bit bus. This is different to the MV I which had a dual ported memory used by the CPU and the I/O stuff via the Q-Bus. This was one of the reasons why the MV I was/is so dreadfully slow. The MV ][ cures this with the special bus (but I wonder what happens when those dreaded DMA devices come along). The $64,000 question: what about UNIX. Well needless to say not 4.2 (due to lack of Q-Bus device drivers) but rather ULTRIX 32m (for MicroVAX). DEC claim that ULTRIX is already working (without the problems the MV I had - ho, ho ho. :-) ) and available. They also claim to have invested more than us$15 million into ULTRIX last year. This sounds amazing. The few changes they made to 4.2 certainly don't seem like they cost 15 * 10^6 dollars - but then of course DEC may pay *very* good salaries ( we bow our head in silence for those trampled in the mad rush for DEC personnel office :-) ) The even more astounding claim was that they claim that VMS is faster than 4.2. I nearly fainted. After the room has stopped spinning, I managed to gasp that so far I have spoken to many people and I know of at least two sites who have thrown out VMS (on 780's) and taken in UNIX because of speed. That is a *lot* of work and that must say something about how much is to be gained in the process. They also claim that the DEC Ada (what !?!) is the fastest Ada around. Thats nice but who wants *d* anyway ? DEC want to invest heavily into compiler construction. They want to produce better FORTRAN and COBOL compilers. AAARGGGhhhhh...I nearly lost the buffet lunch... They also claim that the MV ][ is faster than any 680X0 (x= set of 0,1,2) machine on the market or in fact any other 32-bit single chip product. This may be true but I've put it into the 'extortionate claims' list because it sure sounds like one. It may also be true because there simply are not a lot of 68020 systems on the market at this moment. Actually I couldn't think of any offhand, HELP !! The MV I will die by the end of the year. Its not surprising. I won't miss it. The above opinions are absolutely my own and please imagine the usual footnotes here: Now to answer the question: why would people want such machine ? Well I used to work for a DEC distributor here in Germany and I was told by someone from DEC that they have one customer in the US who does seismic exploration and that he's always getting annoyed because his software people slow down the 'big VAX' (then a 780) which should only run the seismic analysis software. So he went out and bought an MV I for everyone of his developers. I presume he got massive discounts because he certainly didn't get speed. Mind you it did take a load off the big VAX. I feel the only reason to get such a machine is when you want to write assembly language progs which are binary portable within the VAX range. Ahh but then are they ? How about system calls,etc. Perhaps we should get something going in net.flame but then I don't get that so you'll just have to bear this trite. Love, Sebastian (Snoopy) "You haven't done it, till you've done it with pointers !" ( \!mcvax\!unido\!ecrcvax\!snoopy ) /* N.B. valid csh address */ -- Love, Sebastian (Snoopy) "You haven't done it, till you've done it with pointers !" ( \!mcvax\!unido\!ecrcvax\!snoopy ) /* N.B. valid csh address */
faustus@ucbcad.UUCP (Wayne A. Christopher) (05/15/85)
> I guess what I am more or less confused about is, why are people buying > microvaxes? I can think of only a few reasons: You've left out the major advantage, which is that they are VAXes. Binary compatibility is useful to have. Wayne
jack@boring.UUCP (05/15/85)
In article <92@ecrcvax.UUCP> snoopy@ecrcvax.UUCP (Sebastian Schmitz) writes: >The $64,000 question: what about UNIX. Well needless to say not >4.2 (due to lack of Q-Bus device drivers) but rather ULTRIX 32m >(for MicroVAX). You've got me confused here. What's the difference between Q-bus device drivers and unibus device drivers? As far as I know, all the XXV-99 interfaces by DEC are software compatible with their unibus XX-99 brothers, or am I missing something here? Are there problems with unibus maps/qbus maps, or is something else the problem? -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
andrew@stc.UUCP (Andrew Macpherson) (05/16/85)
In article <391@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: >I guess what I am more or less confused about is, why are people buying >microvaxes? I can think of only a few reasons: > > 1. You run VMS, so you got no choices (you fool.) I've just been to the London launch, we were promised that Ultrix 32m was available now. On the other hand I came away with the impression that until the qda50 was available, forget it for multi-user applications. (this wasn't what DEC were saying, rather what they were not saying). The configuration as a workstation with a small disk + ether board would suit me at work, but I suspect there are cheaper (?Sun?) ways to the same end. As an aside I find "vaxes" hard to say, what about "vaxen" (it even sounds more like work-horse :-) -- Regards, Andrew Macpherson. <andrew@stc.UUCP> {creed, idec, root44, stl, ukc}!stc!andrew
david@ukma.UUCP (David Herron, NPR Lover) (05/17/85)
In article <391@bu-cs.UUCP>, root@bu-cs.UUCP (Barry Shein) writes: > I guess what I am more or less confused about is, why are people buying > microvaxes? I can think of only a few reasons: > > 1. You run VMS, so you got no choices (you fool.) Sorry, we don't do that ... > 2. DEC is giving them to you for free or nearly (good reason.) Not this either ... NSF grant. > 3. You have significant applications that require > the architecture specifically (macro code, q-bus periphs) Actually ... We have a lot of applications that are large and compute bound (Macsyma comes to mind). They don't need bus bandwidth that much. (i.e. we won't run ingres on this machine, or not much anyway). > 4. You have great expectations for the box. Yes ... I expect the CPU to be most of a -780. And for a tiny fraction of the cost. Enabling us to buy a number of these machines. > Seems from my analysis they are slower and more expensive than similar > 68K boxes and promise to remain so for years, especially I/O (rumour has > it that some of the 68020s will be approaching the compute speed of the > 8600 for about 2% (20K/1M) the price this fall.) Other 32-bit processors > (3B2 etc) have a similar outlook. The problem with 68K machines is that there aren't any *real* versions of Unix available for them yet. Ask again in a couple of weeks though. We have the Motorola port of System V that AT&T is distributing. And are trying to get it to work on a compupro 68K machine. Then we'll be able to say how good it is. But with System V we don't have ethernet capability off the shelf. Not like we do with a uVaxII running 4.2. At least that's the hope. Actually I'd like to see a 68020 machine that runs as fast as you claim. I'd like to port 4.2 to it. It'd be a screaming machine. > especially when DEC loves to tell you they can't fix it cuz it's UNIX. HA! See my posting the other day about the rev 7 upgrade? :-) -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> --- or david%ukma.uucp@anl-mcs.arpa --- Or even anlams!ukma!david@ucbvax.arpa --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david "It's *Super*User* to the rescue!"
sasaki@harvard.ARPA (Marty Sasaki) (05/18/85)
At the local microVAX-II demo/technical presentation someone from MIT
who was a field test site mentioned that when running Macsyma the
microVAX-II ran faster than a VAX-11/780. The numbers that DEC gave for
ULTRIX-32m showed that the microVAX ran faster in general than the 780,
up to about 10% with "average" (whatever that means) workloads.
I think that this was with lots of memory since the i/o is currently
very slow.
When asked whether the microVAX-II was going to limit 750 and 780 sales,
the DEC guy admitted that it would, but that it was better for DEC if
people bought microVAXen rather than the competition.
--
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138kaiser@jaws.DEC (Pete Kaiser, HLO2-1/N10 225-5441) (05/19/85)
Sebastian Schmitz writes about the MicroVAX II, and has some questions and comments. I hope I won't be the only one to reply to them, and in particular I hope some of the MicroVAX II field test sites, and especially the ones that have been running Ultrix-32m, will also respond. Let me also say at the outset that I admit that (a) I work for Digital, and (b) I think the MicroVAX II is a very nifty engine. > The new MicroVAX ][ is the latest VAX: its a single chip VAX > (so they say) and its claimed to have 80% of the power of a > 780. Its meant to support up to 48 users but typically it will > be less. It really is a single-chip VAX. The chip is a double-metal NMOS chip with about 125000 transistor sites and on-board memory management. Depending on applica- tion, the proportion of a VAX-11/780 it represents may be up to more than 100%; however, around 80 - 90% is a more typical range. And I wouldn't, personally, say that it's "meant to support up to 48 users", although you could certainly hook that many up to it. For years lots of people have said, in one phrasing or another, "Wouldn't it be great to have a 780 all to myself?" And that's what it's for: to be a very powerful, affordable 780-class machine for a small number of users. > Price wise it seems competitive: an MV ][ with a dual floppy > amd integral streamer cassette tape (95 MB), 2MB Ram, 71 MB > winchester and Ethernet interface will cost less than DM 100k. > (For B-movie actor fans this means about US$ 30k) The key is "affordable". The lowball system, which includes 2MB of memory, disk, floppy drive, console port and Ethernet controller, is less than $19K in quantities of 1 domestically. The point is that it shouldn't be necessary to spread the cost among 48 (or even 30) users to make it economical. > The backplane will support two controllers for discs but the > floppy drive and tape drive are included so you can presently > have at most 3 * RD 53 (@ 71MB each = 121 MB) in there with everything > else. Why on earth will two controllers only support five > discs ? 2.5 discs/controller doesn't look right somehow. In > other words I don't know. Sebastian writes in his note about what are several different standard system configurations. In this paragraph he has in mind one of the ones in the BA123 cabinet, the "World Box". Leaving aside what 3 * 71MB equals, I'll correct him slightly as regards the U.S. domestic market: currently up to four 5-1/4-inch form factor devices may be mounted in the BA123. I believe the standard high- ball configuration in the BA123 includes three RD53 Winchester disks plus a TK50 (95MB streaming cartridge tape). There are actually five slots for devices in the BA123, but although the power supply will drive five in steady-state opera- tion, it won't quite stand the current surge at startup, so for now only four are allowed. > The actual architecture: its a full VAX but of course no PDP11 > compatibility mode. Its a Q-Bus machine and the memory is on a > special 32bit bus. This is different to the MV I which had a > dual ported memory used by the CPU and the I/O stuff via the > Q-Bus. This was one of the reasons why the MV I was/is so > dreadfully slow. The MV ][ cures this with the special bus (but > I wonder what happens when those dreaded DMA devices come > along). The MicroVAX I doesn't have a dual-ported memory; the memory is on the Q-bus, pure and simple. This means that the CPU and I/O devices must contend for the bus, which does indeed slow down the CPU. The MicroVAX II's memory is off the Q-bus entirely, but mapped to it through scatter-gather registers just as the Unibus is mapped on macroVAXes. This has some interesting repercussions. The first is "what happens when those dreaded DMA devices come along": nothing. The CPU can access memory at absolute full speed (6MB/sec) at the same time the Q- bus is accessing memory at its full speed in DMA "bus hog" mode (3.3MB/sec), because the memory's speed is 10MB/second. In other words, the machine can compute and do I/O both at full speed simultaneously. The second repercussion of the memory's interaction with the Q-bus through the scatter-gather map is that Unibus drivers have been copied off 780s and just dropped onto the MicroVAX II ... and worked. On Ultrix-32m. > The $64,000 question: what about UNIX. Well needless to say not > 4.2 (due to lack of Q-Bus device drivers) but rather ULTRIX 32m > (for MicroVAX). I've said it here earlier, and I'll say it again: Ultrix-32 is 4.2BSD. The one concession to the MicroVAX is that a rather small list of things is omitted from Ultrix-32m (the MicroVAX release of Ultrix) to avoid using valuable disk space. I'm sorry to say I don't remember the entire list, even though I have Ultrix- 32m, but it's nothing that bothers me much. For instance, I can live without on-line documentation, since I have it nearby on a shelf anyway. And it does seem reasonable that a Q-bus machine needs no Unibus drivers. > [W]hy would people want such [a] machine? Left as an exercise for the reader. > I feel the only reason to get such a machine is when > you want to write assembly language progs which are binary > portable within the VAX range. Ahh but then are they ? How > about system calls,etc. They are. You can take your executables from any VAX, copy them onto a MicroVAX II and run them as is. There's one simple exception to this rule: hardware- dependent code. (I trust this is no great surprise, since the same rule holds true even among macroVAXes.) Hardware-dependent code includes references to privileged registers and some things about I/O -- although, as I mentioned above about drivers, some surprising things work identically between macroVAXes and the MicroVAX II. I hope I've stuck sufficiently to the facts here. Questions? Flames? ---Pete Kaiser%JAWS.DEC@decwrl.arpa, Kaiser%BELKER.DEC@decwrl.arpa {allegra|decvax|ihnp4|ucbvax}!decwrl!dec-rhea!dec-jaws!kaiser DEC, 77 Reed Road (HLO2-1/N10), Hudson MA 01749 617/568-5441
gxm@raybed2.UUCP (GERARD MAYER) (05/21/85)
After working with BSD 4.2 on vax 750 and 780 for two years and then having a SUN for 8 months what advantage would a uVaxII have over a SUN ? A good tradeoff review between the two would be a real benefit to many potential purchasers. Gerard Mayer Raytheon Research Division uucp ...!linus!raybed2!gxm
dan@rna.UUCP (Dan Ts'o) (05/21/85)
In article <> kaiser@jaws.DEC (Pete Kaiser, HLO2-1/N10 225-5441) writes: >I've said it here earlier, and I'll say it again: Ultrix-32 is 4.2BSD. The one >on-line documentation, since I have it nearby on a shelf anyway. And it does >seem reasonable that a Q-bus machine needs no Unibus drivers. > ... >I hope I've stuck sufficiently to the facts here. Questions? Flames? (I do think the uVAX II is a decent machine). Question: PRECISELY, what is the difference between Ultrix-32m for the uVAX II and the 4.2BSD source distribution from Berkeley ? Let me help you start the list, correct me please if I'm wrong: - No online documentation \ - No user-contributed software > These aren't too important - No UNIBUS drivers (really?) / - Better error reporting, DEC-style - Hashed inode and linked proc queues - expensive source license \ - Emulation for missing instructions > These are very important - Bootstraps for MSCP Qbus devices / Please list the real substantive differences. I am particularly in changes to the memory management code, machine trap handling and missing instruction emulation. The basic question is: What do I need to do to take a 4.2BSD distribution tape and get a uVAX II running ? (Why not get Ultrix-32m you ask? because I understand that the source costs $7000 to universities, furthermore, what happens with 4.3 and 4.4 BSD ?) A tidbit: The uVAX II, like the uVAX I, apparently only recognizes a small set of devices in its boot ROMS: specifically MSCP disks, MRV-11 PROM and a DEQNA Ethernet board. This fact means that disks such as RK07, RMxx and third party emulations will not boot on the uVAX II unless you burn a MRV-11 PROM with an appropriate boot routine or new controllers come with VAX boots (current Qbus controllers have PDP-11 boot ROMS). Thus you must buy at least one MSCP disk. There are currently no MSCP controllers available which interface to SMD disks, e.g. the Eagle (Dilog should have one in a few months though I hear there have been legal problems).
snoopy@ecrcvax.UUCP (Sebastian Schmitz) (05/22/85)
Summary: Expires: References: <decwrl.2267> Sender: Reply-To: snoopy@ecrcvax.UUCP (Sebastian Schmitz) Followup-To: Distribution: Organization: European Computer-Industry Research Centre, Munchen, W. Germany Keywords: Thank you very much Pete for setting me right on a few points re. the MV ][. However I would like to point out that it was DEC staff who claimed that the MV I had a dual ported memory. I also always thought that the MV I was basically a VAX on a Q-Bus and hence so slow. The only other machine I knew of at the time which was a 32 bit thing (provided you allow me to say a M68k is a 32bit machine) was the Cadmus and they do have dual ported memory for the CPU to tick whilst the peripherals sit on the (slower) QBus. The Cadmus is spoken of as a 'fast' machine (whatever that means =~ a 730/750 I presume ????) Also my remark about binary compatibility was because I was doubtful, in how much ULTRIX for little VAXen was the same as ULTRIX for the bigger VAXen. I do know that ULTRIX for the Biggies is 4.2 with a few dinky bugfixes/spedups, a daemon for the error log etc... I was just wondering how much they stuck to ULTRIX for the smaller VAXen, because from some of the stuff I heard on the Net, it seemed that the MV I was not that successful in this area. But then I must say that DEC do learn if they do something wrong. Good for you - there are not many companies that admit as freely as DEC to the fact that "yes, this was not so clever". Finally the configuration with the 5 hard discs was spoken of as possible but not recommended (for back-up reasons etc.). The 5 "secondary storage" modules per MV ][ were explained to me somewhat peevishly as problems with the two controllers address spaces in the QBus. This was only in passing though and I may well have misheard. I'm sure noone mentioned the power supply though. Once again, thanks for the first "hard info" on this. Now: off the net for further chat. We can gladly converse individually. Incidentally I do agree that the MV ][ should not have 48 terminals on it. But then DEC in the US always knows a lot more than DEC Germany about new machines etc.. Sigh. Wish you were here (sorry Pink Floyd :-)) -- Love, Sebastian (Snoopy) "You haven't done it, till you've done it with pointers" \!mcvax\!unido\!ecrcvax\!snoopy /* N.B. valid csh address */
wan@gacsr.UUCP (Peter N. Wan) (05/23/85)
In article <136@harvard.ARPA> sasaki@harvard.UUCP (Marty sasaki) writes: >When asked whether the microVAX-II was going to limit 750 and 780 sales, >the DEC guy admitted that it would, but that it was better for DEC if >people bought microVAXen rather than the competition. > Marty Sasaki net: sasaki@harvard.{arpa,uucp} Our DEC guy said that the difference would be that the 750 is clusterable, but that uVAX-II is not now, and probably not ever going to be clusterable. -- Peter N Wan BELL : (404) 586-9663 [office] / (404) 355-6208 [home] UUCP : ...!{allegra,hplabs,ihnp4,rlgvax,ut-ngp,ut-sally}!gatech!gacsr!wan : ...!{akgua,emory}!gacsr!wan
henry@utzoo.UUCP (Henry Spencer) (05/23/85)
> ... what advantage would a uVaxII have over a SUN ? A good > tradeoff review between the two would be a real benefit to many potential > purchasers. Well, I can guess at one tradeoff right off the bat: if you thought that ordering from Sun gave you a good chance to practice patient waiting, just try ordering a new highly-popular machine from Dec! I haven't heard about uVaxII deliveries, but I do know that the ETA on an 11/24 ordered just after announcement was a full year. Our 11/44 -- ordered not long after the machine was announced -- took about 4 months, and that was quick: the configuration we ordered did not have much memory, which sped things up. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jim@mcvax.UUCP (Jim McKie) (05/26/85)
In article <5621@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > ... what advantage would a uVaxII have over a SUN ? A good > tradeoff review between the two would be a real benefit to many potential > purchasers. Well, I can guess at one tradeoff right off the bat: if you thought that ordering from Sun gave you a good chance to practice patient waiting, just try ordering a new highly-popular machine from Dec! I haven't heard about uVaxII deliveries, but I do know that the ETA on an 11/24 ordered just after announcement was a full year. Our 11/44 -- ordered not long after the machine was announced -- took about 4 months, and that was quick: the configuration we ordered did not have much memory, which sped things up. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry I also ordered an 11/24 in Scotland just after it was announced, took less 3 months to arrive (another month for the Unibus-map module). I don't know what the delivery times of uVaxes are, but DEC have always been in the correct ballpark for other Vaxes we've ordered. The first SUN's we ordered took 18 months for all the parts to arrive, the recent ones (after they'd set up their European organisation) took something like 6 (but they still aren't working properly yet...). --jim
friesen@psivax.UUCP (Stanley Friesen) (05/28/85)
In article <400@rna.UUCP> dan@rna.UUCP ( Ts'o) writes: > > PRECISELY, what is the difference between Ultrix-32m for the uVAX II >and the 4.2BSD source distribution from Berkeley ? > > Let me help you start the list, correct me please if I'm wrong: > > - No online documentation \ > - No user-contributed software > These aren't too important > - No UNIBUS drivers (really?) / > - Better error reporting, DEC-style > * Hashed inode and linked proc queues ********* ?? > - expensive source license \ > - Emulation for missing instructions > These are very important > - Bootstraps for MSCP Qbus devices / > I have a hard believing the *'d item. BSD4.x has had hashed inodes and linked process queues since before it was released! I should know, I have seen pre-release listings of the kernel source from Berkeley and these features are there. I cannot see Berkeley removing them after putting them in! -- Sarima (Stanley Friesen) {trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen
guy@sun.uucp (Guy Harris) (06/01/85)
> I have a hard believing the *'d item. BSD4.x has had hashed > inodes and linked process queues since before it was released! > I should know, I have seen pre-release listings of the kernel source > from Berkeley and these features are there. I cannot see Berkeley > removing them after putting them in! What is the value of "x" in "BSD4.x"? 4.1BSD had hashed inode and buffer lookup, which stayed around in 4.2. 4.2 (and, I think, 4.1) also had pointers to a process' parent, youngest living child, next older sibling, and next younger sibling, but didn't use any of those other than the parent pointer. 4.3 uses those pointers (it's a trivial change to make 4.2 use them), and also has a linked list of non-empty process table slots, which 4.2 did not have. Guy Harris