From: SMTP%"leichterlrw.com" 15-FEB-1995 15:42:56.28
Subj: Re: MicroVAX-II
[MicroVAX II vs. MicroVAX 2000 comparisons...]
I remember a DEC engineer saying at DECUS, that the uVAX II had a 10
Mbyte/s memory bus, the CPU could use about 6.6 Mbyte/s, and the Q-bus
about 3.3 Mbyte/s, so it was a nicely balanced system.
The uVAX II is ~90% the speed of a 780,
Just to emphasize a point you make at the end: "90%" is an overall average.
Since the uVAX II emulated some instructions, anything using those would be
*much* slower. Many other hardware-implemented instructions were indeed about
10% slower on the uVAX - but some were faster, sometimes significantly so.
In particular, CALLS/CALLG were sped up considerably.
however, its memory is faster.
The 780 has a cache to work around this, whereas the uVAX II hasn't
got one.
Yup. The 780 is *full* of caches to make up for memory access time problems.
The uVAX II manages to run at full speed with only an 8-byte instruction
buffer, as I recall. The analysis, and its rather surprising result, appears
in a Digital Technical Journal that talks about the design of the chip and
the systems built around it.
Consequently for some applications, such as MSCP serving,
the uVAX II was potentially better.
Yes, *if* you put "real" disks on it. A 780 would probably regain the lead
when you had *many* disks, since it could support multiple controllers and
memory adapters.
I believe Jerry is right in saying that the uVAX 2000's disk
controller is non-DMA, and therefore processor cycles are used up by
disk transfers. I think you'll find that quite a few of the non-Q-bus
systems have non-DMA disk and/or network devices, eg VAX 3400, and I
suspect quite a few of the low-end AXPs. This isn't necessarilly a
bad thing (the 3400 DSSI interface is faster than a KFQSA), but, as
stated, can lead to CPU cycles being consumed.
Before people re-read their Intro to Computer Architecture books, analyze the
-2000's disk interface, and complain: In the traditional view, there are two
kinds of I/O, programmed and DMA. In programmed I/O, the unit of transfer
between the CPU and the I/O device is at most a few bytes at a time, often
just one. Those few bytes cross through an interface that looks to the CPU
like a register. The CPU has to repeatedly load or read the register to
transfer data.
In traditional DMA, in contrast, the CPU gives the device the address of a
large buffer, a count, and says "Go". The device operates on its own and
only comes back to the CPU when the transfer is done.
DMA and programmed I/O are nice conceptualizations, but in the real world,
there is a much broader spectrum of actual design alternatives. In the 730,
for example, from the point of view of a program running on the CPU, the IDC
(Integrated Disk Controller) implemented DMA. However, to actually manage the
transfers to and form memory, the IDC would "borrow" some of the CPU's cir-
cuitry (probably mainly the memory mapping apparatus). The only code the
CPU ever ran was that in the software - but while the IDC was borrowing part
of the CPU, code execution might stall. DMA? Programmed I/O?
In the case of the -2000's disk controller, the programming interface is, I
believe, again DMA-like. However, the CPU is somehow used by the controller
as part of the transfer process. I don't know whether, again, it's somehow a
matter of borrowing part of the circuitry, or whether the CPU actually
executes instructions hidden in a ROM somewhere.
Then there are fast frame buffers and network devices. A common design for
these today uses a block of fast, perhaps dual-ported, memory shared between
the CPU and the device. The device can access only this special memory; the
CPU copies data between "normal" memory and the special memory - which is
usually mapped into the CPU's overall address space - to do I/O. DMA to the
special memory - and what to the main memory?
Lest anyone think the books just haven't caught up with recent inovations:
Back in the late 1960's, the IBM 1130 had a printer with an unusual interface.
This was an 80-column drum printer: A spinning drum contained 80 rings, each
containing all printable characters. To print at a given column, you had to
wait for the right character to appear under the head for that column, then
trigger the head.
The printer was closely coupled to the CPU. 80 bytes of memory at a fixed
location corresponded to the 80 columns. As each row of characters became
aligned with the heads, the printer interrupted the CPU. The CPU had to
mark the memory locations in which it wanted the head to fire, and tell the
printer to proceed. DMA? Programmed I/O?
More reasons to beware of inappropriate benchmarks.
Even more, reasons to beware of attempts to quantify anything with a single
number, whether derived from a benchmark, clock speed, or whatever!
-- Jerry
From: SMTP%"leichterlrw.com" 15-FEB-1995 17:59:06.30
Subj: Re: MicroVAX-II
[MicroVAX II vs. MicroVAX 2000 comparisons...]
I remember a DEC engineer saying at DECUS, that the uVAX II had a 10
Mbyte/s memory bus, the CPU could use about 6.6 Mbyte/s, and the Q-bus
about 3.3 Mbyte/s, so it was a nicely balanced system.
The uVAX II is ~90% the speed of a 780,
Just to emphasize a point you make at the end: "90%" is an overall average.
Since the uVAX II emulated some instructions, anything using those would be
*much* slower. Many other hardware-implemented instructions were indeed about
10% slower on the uVAX - but some were faster, sometimes significantly so.
In particular, CALLS/CALLG were sped up considerably.
however, its memory is faster.
The 780 has a cache to work around this, whereas the uVAX II hasn't
got one.
Yup. The 780 is *full* of caches to make up for memory access time problems.
The uVAX II manages to run at full speed with only an 8-byte instruction
buffer, as I recall. The analysis, and its rather surprising result, appears
in a Digital Technical Journal that talks about the design of the chip and
the systems built around it.
Consequently for some applications, such as MSCP serving,
the uVAX II was potentially better.
Yes, *if* you put "real" disks on it. A 780 would probably regain the lead
when you had *many* disks, since it could support multiple controllers and
memory adapters.
I believe Jerry is right in saying that the uVAX 2000's disk
controller is non-DMA, and therefore processor cycles are used up by
disk transfers. I think you'll find that quite a few of the non-Q-bus
systems have non-DMA disk and/or network devices, eg VAX 3400, and I
suspect quite a few of the low-end AXPs. This isn't necessarilly a
bad thing (the 3400 DSSI interface is faster than a KFQSA), but, as
stated, can lead to CPU cycles being consumed.
Before people re-read their Intro to Computer Architecture books, analyze the
-2000's disk interface, and complain: In the traditional view, there are two
kinds of I/O, programmed and DMA. In programmed I/O, the unit of transfer
between the CPU and the I/O device is at most a few bytes at a time, often
just one. Those few bytes cross through an interface that looks to the CPU
like a register. The CPU has to repeatedly load or read the register to
transfer data.
In traditional DMA, in contrast, the CPU gives the device the address of a
large buffer, a count, and says "Go". The device operates on its own and
only comes back to the CPU when the transfer is done.
DMA and programmed I/O are nice conceptualizations, but in the real world,
there is a much broader spectrum of actual design alternatives. In the 730,
for example, from the point of view of a program running on the CPU, the IDC
(Integrated Disk Controller) implemented DMA. However, to actually manage the
transfers to and form memory, the IDC would "borrow" some of the CPU's cir-
cuitry (probably mainly the memory mapping apparatus). The only code the
CPU ever ran was that in the software - but while the IDC was borrowing part
of the CPU, code execution might stall. DMA? Programmed I/O?
In the case of the -2000's disk controller, the programming interface is, I
believe, again DMA-like. However, the CPU is somehow used by the controller
as part of the transfer process. I don't know whether, again, it's somehow a
matter of borrowing part of the circuitry, or whether the CPU actually
executes instructions hidden in a ROM somewhere.
Then there are fast frame buffers and network devices. A common design for
these today uses a block of fast, perhaps dual-ported, memory shared between
the CPU and the device. The device can access only this special memory; the
CPU copies data between "normal" memory and the special memory - which is
usually mapped into the CPU's overall address space - to do I/O. DMA to the
special memory - and what to the main memory?
Lest anyone think the books just haven't caught up with recent inovations:
Back in the late 1960's, the IBM 1130 had a printer with an unusual interface.
This was an 80-column drum printer: A spinning drum contained 80 rings, each
containing all printable characters. To print at a given column, you had to
wait for the right character to appear under the head for that column, then
trigger the head.
The printer was closely coupled to the CPU. 80 bytes of memory at a fixed
location corresponded to the 80 columns. As each row of characters became
aligned with the heads, the printer interrupted the CPU. The CPU had to
mark the memory locations in which it wanted the head to fire, and tell the
printer to proceed. DMA? Programmed I/O?
More reasons to beware of inappropriate benchmarks.
Even more, reasons to beware of attempts to quantify anything with a single
number, whether derived from a benchmark, clock speed, or whatever!
-- Jerry
From: SMTP%"Info-VAX-RequestMvb.Saic.Com" 15-FEB-1995 18:26:38.56
Subj: Re: MicroVAX-II
> I'd always heard it was the other way: the VAXstation/MicroVAX-2000
> was slightly faster than the -II. Both machines use the same CPU, but
> the lack of the QBUS overhead in the 2000 gave it a slight advantage.
> The difference was quite small - only a few percent.
>
> It's a non-trivial comparison. Both systems used the same CPU chip, and both
> systems used private paths to memory (PMI on the -II, don't know what, if
> anything, it was called on a 2000). The memory paths in both cases should
> have had no trouble keeping up with the CPU demand, so memory should not
> be the bottleneck. On CPU-bound operations, there should be no difference
> at all.
I remember a DEC engineer saying at DECUS, that the uVAX II had a 10 Mbyte/s
memory bus, the CPU could use about 6.6 Mbyte/s, and the Q-bus about 3.3
Mbyte/s, so it was a nicely balanced system.
The uVAX II is ~90% the speed of a 780, however, its memory is faster. The
780 has a cache to work around this, whereas the uVAX II hasn't got one.
Consequently for some applications, such as MSCP serving, the uVAX II was
potentially better.
I believe Jerry is right in saying that the uVAX 2000's disk controller is
non-DMA, and therefore processor cycles are used up by disk transfers. I
think you'll find that quite a few of the non-Q-bus systems have non-DMA
disk and/or network devices, eg VAX 3400, and I suspect quite a few of the
low-end AXPs. This isn't necessarilly a bad thing (the 3400 DSSI interface
is faster than a KFQSA), but, as stated, can lead to CPU cycles being
consumed.
More reasons to beware of inappropriate benchmarks.
Mark Iline systemmeng.ucl.ac.uk
Dept Mech Eng, University College, London. UK
From: SMTP%"seanobanioaol.com (SeanOBanio)" 15-FEB-1995 20:38:49.50
Subj: Re: MicroVAX-II
Jerry Leichter lrw.com> said, in part, about I/O
>As I recall - and this is from a *long* time ago - one way the price on
the
>2000's was kept down was to "borrow" the CPU to do some of the work
You are correct about the 730, but not the MV2000. The real problem, as I
see it, is that the 2000 has no scatter/gather map for DMA. The only DMA
device is the LANCE-based Ethernet adapter (DESVA?): all other I/O
requires a MOVCx instruction to get the data into memory. After that, the
II and the 2000 should be the same, since they both use 50-ns micro-cycle
timing (the same as the CPU) and require 4 cycles to complete a transfere
between the CPU and memory.
About the 14MB memory limit, Clearpoint (remeber them?) had a 16MB card
that had a PAL chip to disable the 2MB memory on the mother board.
To bad Digital doesn't support the NCR SCSI chip as a SCSI port: this
would be a cheap way to get around the RD54 two disk limit on the MFM
control chip. I use Priam 519 disks, which are plug compatable with the
Maxtor disks that the RD54 was based on. The onboard formater had no
problem. But you can only connect two MFM drives, no mater what you do.
Sean O'Banion
Professional OpenVMS System Manager, Pleasanton, CA
Actualy, I do know everything...I'm just not paid enough to reveal all!
From: SMTP%"Info-VAX-RequestMvb.Saic.Com" 16-FEB-1995 07:32:52.50
Subj: Re: MicroVAX-II
In article <9502151513.AA28129uu3.psi.com>, Jerry Leichter lrw.com> writes:
> In the case of the -2000's disk controller, the programming interface is, I
> believe, again DMA-like. However, the CPU is somehow used by the controller
> as part of the transfer process. I don't know whether, again, it's somehow a
> matter of borrowing part of the circuitry, or whether the CPU actually
> executes instructions hidden in a ROM somewhere.
The -2000's disk controller can DMA into a small static RAM buffer. The CPU
has to move the data between that buffer and main memory.
In contrast, the Ethernet interface on the -2000 is quite nice: the Lance
chip has access to the entire 16MB memory space of the machine.
--
----------------+------------------------------------------------------
Roger Ivie | Never underestimate the bandwidth of a
iviecc.usu.edu | truckload of tapes