23 Feb
2003
23 Feb
'03
5:20 p.m.
Hi Gene,
That's just amazing. I never knew the demand for
those things was that
high. I wish the guy that was doing the IDE controllers had entered
production. :)
I think a lot of people, "personal users" too, are getting tired of struggling
with RD-5x drive unreliability, and/or want the larger storage capacities
they could obtain with SCSI
Best Regards
At 11:00 PM 2/23/03 -0800, you wrote:
I took a look
at the CTP dealer listing index, and the current listed
prices
for UC08's run from a low of $300 to a high
of $750 Out of the 12 listed
that have prices showing, the average is $511.25
There was a UC07 recently on eBay in the UK that sold for GBP 252.00
(currently approx. US $397.91 )
EMULEX UCO7 Q-BUS SCSI CONTROLLER FOR DEC
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=1247&item=23…
That's just amazing. I never knew the demand for those things was that
high. I wish the guy that was doing the IDE controllers had entered
production. :)
g. 
24 Feb
24 Feb
12:53 a.m.
That's
just amazing. I never knew the demand for those things was that
high. I wish the guy that was doing the IDE controllers had entered
production. :)
I think a lot of people, "personal users" too, are getting tired of struggling
with RD-5x drive unreliability, and/or want the larger storage capacities
they could obtain with SCSI 
3:49 a.m.
On Mon, 24 Feb 2003, Gene Buckle wrote:
Well I've got a KDA-50 board set so I'm not
_totally_ out in the cold, but
it sure would be nice to use a drive that a) wasn't 150lbs (RA81) and b)
wasn't 3 feet long (RA92). Neither of which fit in the BA123(? nice
roll-around chassis, card cage is on the right side) enclosures that my 2
MicroVAXen use.
If your OS supports it, and VMS and *BSD do, I've found that remote
filesystems outperform local RD5x storage by a very comfy margin. I
haven't had the pleasure of running SDI disks, so I dunno how they'd
match up.
I do know that my MVIII uses a hack of a lot less power booting off a
remote disk than it did spinning up 3 MFM drives. I can only assume
that the RAxx use even more juice.
Doc
4:19 a.m.
New subject: DEC disk drive power consumption (was Re: QBUS SCSI card...)
--- Doc Shipley <doc(a)mdrconsult.com> wrote:
I do know that my MVIII uses a hack of a lot less
power booting off a
remote disk than it did spinning up 3 MFM drives. I can only assume
that the RAxx use even more juice.
Dunno about anything as new as an RA9x, but the RA81 draws 30A surge
current (which is why they have that daisy-chain power sequencer port),
and 8A steady-state. That's a big honkin' motor in there, plus several
square feet of controllers.
I have several. I keep them powered off as much as possible. For my
8200, I've been using an MBA SDI<->ESDI box with 1 x 1.2GB ESDI disks.
Much better MB/KW ratio.
-ethan
8:02 a.m.
If your OS supports it, and VMS and *BSD do,
I've found that remote
filesystems outperform local RD5x storage by a very comfy margin. I
haven't had the pleasure of running SDI disks, so I dunno how they'd
match up.
I do know that my MVIII uses a hack of a lot less power booting off a
remote disk than it did spinning up 3 MFM drives. I can only assume
that the RAxx use even more juice.
By a remote disk, I assume you're talking about a 3.5" SCSI disk sitting in
a remote VMS or *BSD box? In such a configuration you still should (if
possible) have a local swap disk.
Zane
8:28 a.m.
On Mon, 24 Feb 2003, Zane H. Healy wrote:
By a remote disk, I assume you're talking about a
3.5" SCSI disk sitting in
a remote VMS or *BSD box? In such a configuration you still should (if
possible) have a local swap disk.
I know that's the standard wisdom, but the read/write speeds of all
the MFM disks I've tried on my RQDX3s are significantly slower than
network reads and writes.
I did some not-horribly-scientific testing on my MVIII around that.
Local disk-to-disk transfers (in NetBSD) are *much* slower than NFS-NFS
operations, even when the NFS fs were on 2 different machines, and
memory-intensive operations (starting an X desktop with fvwm for remote
display) were about 15% faster *without* local swap.
I recognize the possibility that the NetBSD drivers may have a lot to
do with that, but my VMS skills are not up to setting up that kind of
benchmarks.
This was all on a KA-650 CPU, 13MB RAM, RQDX3 w/RD54, and a DEQNA
ethernet board. I used a 16MB swap file on the NFS server.
Doc
11:26 a.m.
Doc wrote:
On Mon, 24 Feb 2003, Zane H. Healy wrote:
That's interesting. I'd really not taken the slowness of the MFM disks into
account. It also makes a certain sense. Besides come to think of it, that
"standard wisdom" is generally applied to VAXstation 3100 or 4000 class
systems. Though I've been known to recommend booting a VAX 6000 class
system off of a VAXstation 4000/vlc.
By a remote disk, I assume you're talking
about a 3.5" SCSI disk sitting in
a remote VMS or *BSD box? In such a configuration you still should (if
possible) have a local swap disk.
I know that's the standard wisdom, but the read/write speeds of all
the MFM disks I've tried on my RQDX3s are significantly slower than
network reads and writes. I did some not-horribly-scientific testing on my
MVIII around that.
Local disk-to-disk transfers (in NetBSD) are *much* slower than NFS-NFS
operations, even when the NFS fs were on 2 different machines, and
memory-intensive operations (starting an X desktop with fvwm for remote
display) were about 15% faster *without* local swap.
I recognize the possibility that the NetBSD drivers may have a lot to
do with that, but my VMS skills are not up to setting up that kind of
benchmarks.
This was all on a KA-650 CPU, 13MB RAM, RQDX3 w/RD54, and a DEQNA
ethernet board. I used a 16MB swap file on the NFS server.
You're making me wish I could give this a try under VMS. I wonder where on
earth I've got my pair of RD54's stashed. I know where everything else is
that would be required to temporarily switch a PDP-11 over to a MicroVAX II.
It would make for some interesting testing, and I've been wanting to us a
MicroVAX II to practice my system tuning skills (improvements are more
noticable on a MVII).
Zane
12:15 p.m.
On Mon, 24 Feb 2003, Zane H. Healy wrote:
Doc wrote:
Now that I agree with - my 3100s do a *lot* better with local swap,
and a little better with a local system disk.
On Mon, 24 Feb 2003, Zane H. Healy wrote:
That's interesting. I'd really not taken the slowness of the MFM disks into
account. It also makes a certain sense. Besides come to think of it, that
"standard wisdom" is generally applied to VAXstation 3100 or 4000 class
systems. Though I've been known to recommend booting a VAX 6000 class
system off of a VAXstation 4000/vlc. By a remote disk, I assume you're talking
about a 3.5" SCSI disk sitting in
a remote VMS or *BSD box? In such a configuration you still should (if
possible) have a local swap disk.
I know that's the standard wisdom, but the read/write speeds of all
the MFM disks I've tried on my RQDX3s are significantly slower than
network reads and writes. You're making me wish I could give this a try
under VMS. I wonder where on
earth I've got my pair of RD54's stashed. I know where everything else is
that would be required to temporarily switch a PDP-11 over to a MicroVAX II.
It would make for some interesting testing, and I've been wanting to us a
MicroVAX II to practice my system tuning skills (improvements are more
noticable on a MVII).
I'd be quite interested to know what you find. I'm not willing to
discount inefficient drivers on the NetBSD side, but just the published
transfer rates for the MFM disks, let alone seek times, suggest that on
a decently configured network, local storage will be slower than NFS.
Doc
2:02 p.m.
You're
making me wish I could give this a try under VMS. I wonder where on
earth I've got my pair of RD54's stashed. I know where everything else is
that would be required to temporarily switch a PDP-11 over to a MicroVAX II.
It would make for some interesting testing, and I've been wanting to us a
MicroVAX II to practice my system tuning skills (improvements are more
noticable on a MVII).
I'd be quite interested to know what you find. I'm not willing to
discount inefficient drivers on the NetBSD side, but just the published
transfer rates for the MFM disks, let alone seek times, suggest that on
a decently configured network, local storage will be slower than NFS.
2:18 p.m.
On Mon, 24 Feb 2003, Zane H. Healy wrote:
Unfortunatly this is something that will have to wait
for me to actually
find the time to do it :^( I'm really curious as to how much of a
difference in performance it would be possible to obtain with VMS. With VMS
you're dealing with ODS2, DECnet and the Clustering software, on Unix you've
got ffs (or whatever the filesystem BSD is using), TCP/IP and NFS. On the
downside, Unix tends to beat VMS at disk IO, still we're talking more the
difference between a RQDX3/RD54 combo vs. a nice fast more modern server
with SCSI (or IDE) disks.
I'd say it's more the difference between the throughput of the DEQNA
and the throughput of the RQDX3/RD54 than it is between the difference
between MFM & modern SCSI. My fileserver will spew data a good bit
faster than the DEQNA can process it. The Qbus ethernet is the
bottleneck.
No hurry, anyhow. It's mostly academic to me - the whine of the MFM
drives makes SWMBO nuts. The choice to go network-based storage had the
unexpected speed boost, but peace in the castle was/is the overriding
factor....
Doc
2:59 p.m.
New subject: DEQNA
My fileserver will spew data a good bit
faster than the DEQNA can process it.
You might be able to open that bottleneck up with a DELQA-M
M7516-YM, especially if you can get it running in Turbo Mode.
At 10:14 PM 2/24/03 -0600, you wrote:
On Mon, 24 Feb 2003, Zane H. Healy wrote:
Unfortunatly this is something that will have to
wait for me to actually
find the time to do it :^( I'm really curious as to how much of a
difference in performance it would be possible to obtain with
VMS. With VMS
you're dealing with ODS2, DECnet and the
Clustering software, on Unix
you've
got ffs (or whatever the filesystem BSD is
using), TCP/IP and NFS. On the
downside, Unix tends to beat VMS at disk IO, still we're talking more the
difference between a RQDX3/RD54 combo vs. a nice fast more modern server
with SCSI (or IDE) disks.
I'd say it's more the difference between the throughput of the DEQNA
and the throughput of the RQDX3/RD54 than it is between the difference
between MFM & modern SCSI. My fileserver will spew data a good bit
faster than the DEQNA can process it. The Qbus ethernet is the
bottleneck.
No hurry, anyhow. It's mostly academic to me - the whine of the MFM
drives makes SWMBO nuts. The choice to go network-based storage had the
unexpected speed boost, but peace in the castle was/is the overriding
factor....
Doc
3:13 p.m.
New subject: DEQNA
On Mon, 24 Feb 2003, Mail List wrote:
Have one. Haven't gotten around to installing it. I've been busy
inventorying and getting ready to sell a truckload of DEC7000 hardware
and some AlphaServers, and that's eating a lot of my hobby time.
Raw performance isn't really the issue with any of my Qbus gear. My
MV3100-80 will run rings around the MVIII, at anything I want it to do.
It's just not as much fun.
Doc
My fileserver
will spew data a good bit
faster than the DEQNA can process it.
You might be able to open that bottleneck up with a DELQA-M
M7516-YM, especially if you can get it running in Turbo Mode.
3:28 p.m.
I'd say it's more the difference between the
throughput of the DEQNA
and the throughput of the RQDX3/RD54 than it is between the difference
between MFM & modern SCSI. My fileserver will spew data a good bit
faster than the DEQNA can process it. The Qbus ethernet is the
bottleneck.
I'm pretty sure you're right about the DEQNA being the bottleneck. Have you
clocked the throughput on the DEQNA? I'm guessing it's about 1Mbyte/Sec max
(in reality I'd guess it's FAR lower). IIRC, the Q-Bus can only handle
3Mbyte/Sec. I think all the memory ops go over the ribbon cables (isn't
the q-bus limited to powering the RAM, it's been a 2-3 years since I looked
at a Q-Bus VAX and my memory stinks at times) so you should have a mostly
free pipe between the DEQNA and the CPU.
It would be interesting to have a Q-Bus FDDI adapter (DEFQA) and see how much
more performance you could get using it, since it will saturate the Q-Bus.
I think I'll have to look into seeing what it would take to set up such a
test.
No hurry, anyhow. It's mostly academic to me -
the whine of the MFM
drives makes SWMBO nuts. The choice to go network-based storage had the
unexpected speed boost, but peace in the castle was/is the overriding
factor....
My wife doesn't know how lucky she is that I had my PDP-11/73 in the BA123
in basically it's current condition when we got married. She never had to
experience it without all the panels and MFM or ESDI disks :^)
Zane
5:14 p.m.
On Mon, 24 Feb 2003, Zane H. Healy wrote:
Given that it's 10Mb/s ethernet, seeing something like 1MB/s would
definitely be an upper limit. I do know that, at least with NetBSD/vax,
the port maintainer worked hard to get the DEQNA and DELQA (running in
DEQNA mode) to operate as efficiently as he could. It's been a while
since I got to play with my Qbus systems, so I don't recall the actual
throughput being seen. From a list mail of his:
-> On Fri, 10 May 2002, Anders Magnusson wrote:
->
-> > You can look at the original DEC driver that were in NetBSD, it
-> > have some of the compensation code for bad DEQNA's. Note that the
-> > DEC driver is quite slow; it could almost reach 200k/s (in both
-> > directions). The new one I wrote peeks about 500k/s.
I was seeing something close to 500KB/s on my systems, too.
I'd say
it's more the difference between the throughput of the DEQNA
and the throughput of the RQDX3/RD54 than it is between the difference
between MFM & modern SCSI. My fileserver will spew data a good bit
faster than the DEQNA can process it. The Qbus ethernet is the
bottleneck.
I'm pretty sure you're right about the DEQNA being the bottleneck.
Have you clocked the throughput on the DEQNA? I'm guessing it's about
1Mbyte/Sec max (in reality I'd guess it's FAR lower). IIRC, the Q-Bus can only handle 3Mbyte/Sec. I think
all the memory
ops go over the ribbon cables (isn't the q-bus limited to powering the
RAM, it's been a 2-3 years since I looked at a Q-Bus VAX and my memory
stinks at times) so you should have a mostly free pipe between the
DEQNA and the CPU.
Another thing to keep in mind, IIRC, is the position of the modules
along the Qbus chain.
It would be interesting to have a Q-Bus FDDI adapter
(DEFQA) and see
how much more performance you could get using it, since it will
saturate the Q-Bus. I think I'll have to look into seeing what it
would take to set up such a test.
Ouch. I bet that'd be pretty painful for something like a MicroVAX-II
class machine; still, I'd love to see it done!
-brian.
25 Feb
25 Feb
5:01 a.m.
Brian Chase wrote:
Good point, I believe you're right.
Does the FDDI controller load down the host systems CPU, or does it handle
the load onboard? It doesn't really matter, after a little research, I
don't think I'll be testing this unless I happen upon a really cheap FDDI
controller, it looks like they're more than I can afford to spend on a
something that would be to simply satisfy my curiousity.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh(a)aracnet.com (primary) | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
On Mon, 24 Feb 2003, Zane H. Healy wrote:
-> On Fri, 10 May 2002, Anders Magnusson wrote:
->
-> > You can look at the original DEC driver that were in NetBSD, it
-> > have some of the compensation code for bad DEQNA's. Note that the
-> > DEC driver is quite slow; it could almost reach 200k/s (in both
-> > directions). The new one I wrote peeks about 500k/s.
I was seeing something close to 500KB/s on my systems, too.
Truth be told, that's actually a bit better than I was hoping for.
IIRC, the Q-Bus can only handle 3Mbyte/Sec. I
think all the memory
ops go over the ribbon cables (isn't the q-bus limited to powering the
RAM, it's been a 2-3 years since I looked at a Q-Bus VAX and my memory
stinks at times) so you should have a mostly free pipe between the
DEQNA and the CPU.
Another thing to keep in mind, IIRC, is the position of the modules
along the Qbus chain. It would be
interesting to have a Q-Bus FDDI adapter (DEFQA) and see
how much more performance you could get using it, since it will
saturate the Q-Bus. I think I'll have to look into seeing what it
would take to set up such a test.
Ouch. I bet that'd be pretty painful for something like a MicroVAX-II
class machine; still, I'd love to see it done!
5:36 a.m.
On Tue, 25 Feb 2003, Zane H. Healy wrote:
Does the FDDI controller load down the host systems
CPU, or does it handle
the load onboard? It doesn't really matter, after a little research, I
don't think I'll be testing this unless I happen upon a really cheap FDDI
controller, it looks like they're more than I can afford to spend on a
something that would be to simply satisfy my curiousity.
I'd imagine that if you saturate the Qbus with traffic over the FDDI
module, you'll probably cause some pain for any other peripherals which
also rely on the Qbus. I think most of the Qbus gear tends to be very
good about offloading I/O processing to the boards themselves, but I'd
still expect the CPU to take a hit for things like assembling and
disassembling the TCP/IP packets (calculating checksums and moving bits
around kernel and user buffer areas.) If you're running diskless off
NFS, I'd expecting more CPU requirements associated with all the
filesystem overhead. Still, I'd imagine it'd be quite a lot faster
than locally attached MFM disks.
I can't claim to be much of an expert on the internals of the NetBSD
kernel, or on the capabilities of the DEFQA, but I wouldn't be surprised
if the CPU on something like a MicroVAX-II ended up being the weakest
link in pushing data over FDDI. It'd be interesting to gather some
empirical data for something like MicroVAX-II, MicroVAX 3600, and
various VAX 4000 models.
-brian.
6:42 p.m.
On 2003.02.25 20:24 Brian Chase wrote:
It'd be interesting to gather some empirical data
for something
like MicroVAX-II, MicroVAX 3600, and various VAX 4000 models.
Well. I have a MV II,
a MV 3900, a VAX 4000-400 and a DEFQA. The DEFQA
is based on the same PDQ engine as the DEF[TEP]A. The later are already
suported by NetBSD. It would be quite easy to write a QBus attachment
for NetBSD to make the DEFQA usable. Unfortunately I have no docs about
the DEFQA... (Hint! ;-) )
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
24 Feb
24 Feb
7:54 a.m.
Well I've got a KDA-50 board set so I'm not
_totally_ out in the cold, but
it sure would be nice to use a drive that a) wasn't 150lbs (RA81) and b)
wasn't 3 feet long (RA92). Neither of which fit in the BA123(? nice
roll-around chassis, card cage is on the right side) enclosures that my 2
MicroVAXen use.
That's what rack's are for :^) I've got a MicroVAX III in storage that I
built to read RL01's and RL02's. It uses 4 RA7x's in enclosures the size of
a RA9x enclosure (I've got two of those as well). The MV3 lives in a 3rd
party rack mount and the whole thing sits in the bottom of an old PDP-11 rack
that I bought empty.
Thankfully I don't have any RA8x drives!
Zane
5:21 a.m.
New subject: SCSI cards
I just wish I could find the SCSI controller that a German company made for the DEC
Rainbow. it'd be nice to pull the 20 meg HD out and drop a 500 meg SCSI in it's
place :)
25 Feb
25 Feb
3:13 p.m.
New subject: SCSI cards
I just wish I could find the SCSI controller that a
German company made
for the DEC Rainbow. it'd be nice to pull the 20 meg HD out and drop a
500 meg SCSI in it's place :)
Wow! Is this documented? That *does* sound cool. Though I'm not sure just
how long it'd take to defragment... :-)
How did it work with the OS's, which were limited to disk sizes nothing
like 500 Meg?
- Mark
24 Feb
24 Feb
5:28 a.m.
On Mon, 24 Feb 2003, Mail List wrote:
There's also the people who need to use them in production environments,
but can't afford to buy one new. (Yes, they are still very much in
production, for those who don't know...)
Peace... Sridhar
That's
just amazing. I never knew the demand for those things was
that high. I wish the guy that was doing the IDE controllers had
entered production. :)
I think a lot of people, "personal users" too, are getting tired of
struggling with RD-5x drive unreliability, and/or want the larger
storage capacities they could obtain with SCSI
7924
days inactive
7926
days old
21 comments
10 participants
participants (10)
-
doc＠mdrconsult.com -
erd_6502＠yahoo.com -
geneb＠deltasoft.com -
geoffr＠zipcon.com -
healyzh＠aracnet.com -
jkunz＠unixag-kl.fh-kl.de -
mail.list＠analog-and-digital-solutions.com -
mtapley＠swri.edu -
vance＠neurotica.com -
vaxzilla＠jarai.org