24 Oct
1999
24 Oct
'99
5:15 p.m.
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