Benchmark Wars (was Re: gauging interest in VAX 6000-530)

From: Mike Cheponis <mac_at_Wireless.Com>
Date: Mon Oct 25 00:15:17 1999

On Sun, 24 Oct 1999, Allison J Parent wrote:

> <> If you're doing ray tracing, get a fast PC.
> <> If you're timesharing dozens of people, a VAX is not a bad choice.
> <
> <I remain unconvinced(!).

Wait! What I'm saying is that if you were sufficiently motivated, you could
very well timeshare dozens of people on a PC.


> Then what would work better for fast ray tracing. and why does my ISP have
> a 24x250mhz SGI and not 24 PIII/xeons?

I didn't say anything at all about ray tracing, did I?

>
> <> It's all about "balance" and truly good designers can get good balance fo
> <> the task at hand without being stuck in some rut.
>
> Big time Chuck. I like the mix, I like to mix.


> Thinking of the 11/55 story. 1970, KA10 (PDP10) 300 users (mostly TTYs)
> in schools never using more than maybe 70%. Plus batch processes for version
> clerical tasks related to the operation of the BOCES LIRYCS timeshare
> system. Now That was BIG iron (12 6ft racks!). But if I took all the PCs
> needed to provide the same interconnected services and stacked them up
> they would easily outweigh the KA10 and much more power, try 300x200W
> that is 60KW, the Ka10 was under 10KW and like near 6KW.



> <Here's my back-of-the-envelope:
> <
> <The 16-bit ISA bus on a 486dx2/66 runs at 8 MHz. The total bus throughput
> <for memory operations is 32 megabits/sec. (4 cycles = 500 ns, 16 bits/cycle
>
> yes, but the IO is polled or interrupt and that adds 500% overhead.

Only if the interface h/w is losing. Multiport async boards almost always
have on-board micros that obviates the need for polling. Interrupts transfer
a big batch of data.

>
> <If your dozen uarts are on a memory-mapped card, and you're pumping 19.200
> <b/s continuously to the dozen uarts, that's 184,320 b/s required by the
> <uarts. That's only about 0.6% of the available bus bandwidth (about one
> <uart transfer every 174 Main Memory references.) Yes, you do have to work
> <with such slow memory, and now we understand why cache memory was so import
> <even on dx2/66 motherboards. So, yeah, keeping a dozen terminals blazing
> <output would be "fun" with an ISA-only bus!


"fun" here means "difficult".


> It's not 184320, thats how many are transfered, not the process loading.

Yes....

> The system might require that to be dispersed across 12 buffers and there
> are overheads associeted with that.

Yes. in pdp-11 lingo: mov (r0)+,(r1)+ ... Not ---too--- much overhead. ;-)

But, sure in the general case, when you are actually doing something,
it's going to be tough to use the ISA bus only.


> The actual performance is not impressive. FYI: vax using the same approach
> would really be poor too. This kind of IO was typical of PDP-11s
> and they did it very well. The big iron solution is hardware and non
> competeing busses to unload the cpu from the IO task and not burden the
> memory with the slow IO cycles. Therein is part of the difference.
> Old iron treated the cpu as a valuable resource and were designed with the
> idea that cpu cycles were expensive.

Very well put!


> <(Incidentally, I am -not- advocating ISA as some sort of "wunderbus"; on th
>
> Yes it's perfomance is par with mid range(ca 1977) unibus and Qbus of 10
> years before. By 1981 DEC had decided that those busses were ok for their
> use but they needed faster buses. FYI BI bus was a 64bit bus (minimum
> access was a 8byte chunk) and in use about 8 years before PCI was conceived
> (or VESA, VL). the big iorn was always trying to feed the data rate habit
> and usually long before PCs.

Again, wonderful summary.

> < contrary, I remain amazed that it has taken the PC industry as long as it
> < has to recognize the importance of I/O speed. 64-bit 66 MHz PCI and 2x AG
> < are steps in the right direction... Yes, the microcomputer industry seem
> < hellbent on re-discovering what the mainframe and mini guys knew 20 or 40
> < years ago...)
>
> Yes. thats the whole point.

Exactly.

>
> Allison

-mac
Received on Mon Oct 25 1999 - 00:15:17 BST