On Mon, 24 Feb 2003, Zane H. Healy wrote:
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).
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.
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.