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

From: Hans Franke <Hans.Franke_at_mch20.sbs.de>
Date: Mon Oct 25 13:37:14 1999

> > <> 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.

Well, it depends what you are about to do. Of course you can handle
a lot of users at the same time on a small machine, if the task is
right - my personal record is 64 simultanious users on a 8 MHz 286
in a special situation (Well, as obviously, the task was not very
intensive, mainly gathering user requests and multiplexing them on
host chanels, and demuxing and forwarding the results - and the
whole communication was structured in a _very_ friendly fashion
- all talk was done in a block orientated protocoll (HDLC-ish),
where the handling could be done completly inside the drivers -
and these did reside on Z80 subsystems - and of course all in
assembly - but still, this machine was going to the limit -
throughputs up to 400 kByte/s - I did write my own Real Time OS,
includeing some real time debugging tools - I had some nasty memory
management vs interupt handlin bugs, so I wrote a single step module,
where the OS did trace itself... fun:) and more 'standard', a BBS
with up to 4 users on a 8MHz (1ws) 80186 with up/dowload at 38400 bps,
without losing data (Again of course Assm, but this time without
any co-proz help and interrupt driven), coming _very_ close to the
end of the story.

What I want to say, is that it is _very_ depending on your application
structure if 4 or 64 users are the maximum load - if your CPU has to
handle every Byte, and posibly has to route every byte until the top
level aplication rather than handle it in a driver (char mode vs.
block mode), even a powerfull CPU can be loaded with low productivity
tasks, instead of doing the 'real' job. The same is of course true for
any other I/O - if the machine has to handle every user entry serial
(i.e. waiting until the disk is finished, since ther is no detatchable
bus) than there is no room for multiple users.

After all it is more a question how well application structure and
machine structure kooperate (or not).

> > <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.

Well, but if your app needs to check every Byte at its time, these batches
use the gigantic amout of 1 Byte per transfer ...

> > <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".

Well, if they are block mode terminals - or if it is just output,
if this is done at driver level, direct mapped ports can still be
filled in time (keyword fifo/treshold)

> > 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. ;-)

OUTSB ?
(scnr :)

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

ISA isn't that bad.

> > < 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.

(should i mention the MicroChanel ... better not :)

Gruss
H.

--
Stimm gegen SPAM:     http://www.politik-digital.de/spam/de/
Vote against SPAM:    http://www.politik-digital.de/spam/en/
Votez contre le SPAM: http://www.politik-digital.de/spam/fr/
Ich denke, also bin ich, also gut
HRK
Received on Mon Oct 25 1999 - 13:37:14 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:34 BST