25 Feb
2003
25 Feb
'03
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!