steve@fnord.umiacs.umd.edu (Steven D. Miller) (07/15/89)
DEC had a big product announcement on 7/11. Since I haven't seen anything here about the announcements, I thought I'd summarize what I know. I'm almost certain that other machines (in the VAX line at least, which I confess that I pay little attention to) were announced; see your sales rep for more details. Here's the quick summary of what was announced: 1) DECstation 2100. This is like a 3100, but runs at a lower clock rate. It's about 9-10 MIPS, but is otherwise identical to the 3100. The list price is substantially lower than on the DECstation 3100, and DEC claims that the 2100 meets or beats SPARCstation 1 performance. (DEC says the 2100 is $1K cheaper than the SS1, but I think they're both around $9K for an entry-level system. The DECstation is probably a little bit cheaper. I could just be confused...) 2) DECserver 5400. Features: MIPS R3000 chipset, 15-16 MIPS, 2.1 MFLOPS DP LINPACK, 4.8 MFLOPS SP LINPACK. 16-64MB memory (I don't know about parity/ECC/whatever) I/O bus is the Q-Bus Packaging: BA213 pedestal or H9644 cabinet Disks -- DSSI (RF series) or SDI (RA series) in general RF70 (400MB DSSI; 3 in BA213 package) RA90 (1.2GB SDI; 2 in H9644 package) RA70 (280MB SDI; 2 in H9644, plus RA90s) Expansion cabinets available Probably (I don't know) most QBus peripherals supported under VAX Ultrix work under RISC Ultrix 3) DECserver 5810/DECserver 5820. Features: MIPS R3000 chipset, 18-20 MIPS per CPU, 2.1/4.8 MFLOPS LINPACK per CPU, 2 CPUs max; I suspect that plugging in more CPUs will work, but I also suspect that two saturate the XMI bus, and that's why DEC doesn't want to sell this with more than two CPUs 32-256MB memory (ECC) BI bus as I/O bus Packaging identical to VAX 6000 series (yes, CPU swaps are technically feasible, though it's not clear yet if there's any way to buy one) TK70 built in SDI disks; 2 RA90s fit in main cabinet, and can get expanders Supports KLESI tape controller, KDB50 disk controller, DEBNI Ethernet controller, CI/HSC stuff, ttys, and perhaps other BI stuff (I can only write so fast...) They all sound pretty neat. Now if I could only find a way to justify a 5820... -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
grr@cbmvax.UUCP (George Robbins) (07/15/89)
In article <18553@mimsy.UUCP> steve@fnord.umiacs.umd.edu (Steven D. Miller) writes: > > DEC had a big product announcement on 7/11... > > 3) DECserver 5810/DECserver 5820. Features: > > MIPS R3000 chipset, 18-20 MIPS per CPU, 2.1/4.8 MFLOPS > LINPACK per CPU, 2 CPUs max; I suspect that plugging > in more CPUs will work, but I also suspect that two > saturate the XMI bus, and that's why DEC doesn't want > to sell this with more than two CPUs Well, maybe that no Ultrix supported CPU supports more than two processors to date (see previous discussion on this). The XMI bus appears to be adequately fast, given that the CPU cards each have a reasonable size cache. Sounds *real* nice to me, *iff* the price tag is at the low end of the 6X00 range and not off the high end. Lots of MIPS, real I/O (even if it's all BI/CI based) and I don't have to worry about the VMS types trying to make off with it. > Packaging identical to VAX 6000 series (yes, CPU swaps > are technically feasible, though it's not clear yet > if there's any way to buy one) Probably you will be able to get them, but not afford them. The pricing on the 6200/6300 CPU cards looks like the biggest rape since the 8600->8650 upgrade. It looks like DEC is trying hard to maintain high-end system sales by artificially high pricing on mid-range CPU card pricing... I mean they're allowed to, but if I go for a multi-processor architecture, I want multi-processors, not a uni-processor and a bunch of slots that I can't justify the $$$ to fill. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
mark@mips.COM (Mark G. Johnson) (07/15/89)
In article <18553@mimsy.UUCP> steve@fnord.umiacs.umd.edu (Steven D. Miller) writes: > Here's the quick summary of what was announced: > > 3) DECserver 5810/DECserver 5820. Features: > MIPS R3000 chipset, 18-20 MIPS per CPU, 2.1/4.8 MFLOPS > LINPACK per CPU, 2 CPUs max; I suspect that plugging > in more CPUs will work, but I also suspect that two > saturate the XMI bus, and that's why DEC doesn't want > to sell this with more than two CPUs > 32-256MB memory (ECC) > BI bus as I/O bus -------------------------------------------------------------------------- When the R3000 processor takes a cache-miss, an entire "cache block" -- (1 to 32 words, boot-configured) -- is fetched from main memory. The CPU/cache can receive them at a rate of one word/cycle (4 bytes/40ns) or a bandwidth of 100 Megabytes/second. Could someone enlighten me? What's the peak bandwidth of the "XMI bus"? Can it do >= 100 MBytes/sec? Can it do N * 100MB/s (for say N=1.3 in a 2-way multiprocessr)? Thanks. -- -- Mark Johnson MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 ...!decwrl!mips!mark (408) 991-0208
grr@cbmvax.UUCP (George Robbins) (07/16/89)
In article <23363@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes: > In article <18553@mimsy.UUCP> steve@fnord.umiacs.umd.edu (Steven D. Miller) writes: > > Here's the quick summary of what was announced: > > 3) DECserver 5810/DECserver 5820. Features: ... > -------------------------------------------------------------------------- > > When the R3000 processor takes a cache-miss, an entire "cache block" > -- (1 to 32 words, boot-configured) -- is fetched from main memory. > > The CPU/cache can receive them at a rate of one word/cycle (4 bytes/40ns) > or a bandwidth of 100 Megabytes/second. > > Could someone enlighten me? What's the peak bandwidth of the "XMI bus"? > Can it do >= 100 MBytes/sec? Can it do N * 100MB/s (for say N=1.3 in > a 2-way multiprocessr)? Thanks. Well, as I understand it, it's nominally a 100 M-byte/sec bus or as DEC puts it "a maximum sustained bandwidth of 100 M-byte/sec". There is support for block read/write transfers and memory boards are logically multi-word wide with 2/4/8 way memory interleaving available to boost memory subsystem thruput. Real numbers on cycle times, transactions and peak thruput seem hard to come by. For the sake of argument, let's assume that the XMI bus can provide the instantaneous thruput to handle cache load/store operations. The question then boils down whether or not there is a large enough on-board cache to allow effective sharing of the bus. With the 6200/6300 processors DEC was willing to put a 256K-byte of cache on each CPU board, which suggests considerable sensitivity to XMI bus thruput issues. I think with a cache this size or larger, the XMI bus should be able to support N-way multi- processing fairly effectively. On the other hand, one can call in CISC/RISC arguments and assert that the XMI bus is designed for a rather CISC'ish processor architecture and would be swamped by a the memory hungry RISC architecture. Playing numerology games suggest that the XMI bus was indended to support around 10 processor/io elements, each good for about 10 MB/sec. If the RISC based processor eats 2X or 4X this kind of number, you'd expect to see some different configuration rules. Of couse it's hard to tell, DEC loves to alternate balls-to-the-wall high thruput, wide margin, designs with cost driven, compromise or cripple everything designs (or unfortunate combinations of the two 8-)... Lately though it's seems they've picked up on IBM's "100 incrementally expensive steps to true performance", so who knows? I wonder if there is any literature available yet? The VMS guys here were talking about new announcements (6400 etc.) in the next couple of weeks. Are the Ultrix/RISC guys allowed to come out of the closet again and tantalize us with some facts? -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
elgie@canisius.UUCP (Bill Elgie) (07/16/89)
In article <7325@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: > ...re the DECsystem 58nn (6000 series box): > > For the sake of argument, let's assume that the XMI bus can provide the > instantaneous thruput to handle cache load/store operations. The question > then boils down whether or not there is a large enough on-board cache to > allow effective sharing of the bus........ I think with a cache this size > ..(256 Kb)..or larger, the XMI bus should be able to support N-way multi- > processing fairly effectively. Quote from DEC: "...the CPU includes a first-level cache of 128 Kbytes, supp- lemented by a second-level cache of 256 Kbytes." > > Of couse it's hard to tell, DEC loves to alternate balls-to-the-wall high > thruput, wide margin, designs with cost driven, compromise or cripple > everything designs (or unfortunate combinations of the two 8-)... Lately > though it's seems they've picked up on IBM's "100 incrementally expensive > steps to true performance", so who knows? > Overall, I have been surprised by DEC's RISC-based system pricing: much lower than I had expected. > I wonder if there is any literature available yet? The VMS guys here > were talking about new announcements (6400 etc.) in the next couple of > weeks. > The 6400 was announced the same day as the new RISC systems. Also announced was a 2.8 MVUP Microvax 3100 server, $6,680 with 4 megs and a 100(?) meg hard disk. A question for MIPS and DEC/ULTRIX people: the DECsystem 5400, with internal clock speed of 20 MHz, is rated at "16.6 MIPS", while the 5810, at 25 MHz, is rated by DEC at "18.7 MIPS". Why the samll difference ? Memory bandwith ? Just curiosity, but would appreciate an answer anyway. P.S.: For those who may not know, DEC has an online "store" that answers most of the questions that have been asked about the July 11 announcement. Most of the info was in by mid-morning of the 11th. The "store" is ob- viously not a source for truly in-depth technical info, obviously. You can get an account for it very easily (albeit slowly) by calling one of the nos. listed on DEC's "DEC DIRECT" catalog. You can also dial in to 1-800-332-3366; hit ctrl-c when asked to log in. I don't know if this login bypass was intended, but it works. greg pavlov (under borrowed account), fstrf, amherst, ny
grr@cbmvax.UUCP (George Robbins) (07/18/89)
In article <18553@mimsy.UUCP> steve@fnord.umiacs.umd.edu (Steven D. Miller) writes: > > 3) DECserver 5810/DECserver 5820. Features: > > BI bus as I/O bus > Packaging identical to VAX 6000 series (yes, CPU swaps > are technically feasible, though it's not clear yet > if there's any way to buy one) Well, not quite identical. It looks like for the standard configuration(s) they've yanked out one of the two BI cages standard in most of the 6000 series and put provision for mounting a couple of RA90 drives internally instead. This makes for a pretty compact system if you only need a little (2 GB) disk, but otherwise seems likely to sell a lot of VAXBI expansion cabinets. DEC did also announce the 6400 series. No great surprises - 7 VUPS/cpu which puts it up with the high-end 8000 series processors. Also, an option to add 1 or 2 "vector processors" to the XMI cage "soon", Only supported in a VMS/Fortran environment, of course. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)