UDA50A V.S. The UniBus !

[clark.wbst at PARC-MAXC.ARPA]

I recently received a UDA50A and a couple of RA60s, and they do not get
along well with our ethernet controller at all.  The disks are on a 730
with a DMR
based DECNET going to a 750.  Below is what I have observed, been told,
etc.  If anyone can shed any light, or has any stabs in the dark, I
would much appreciate hearing from you !!!

[The ethernet controller is one made by xerox years ago.  It is your
basic
simple, dumb, no buffering DMA device.]

If I ever figure out what is going on, I'll let you all know!

Behavior:

	1) DECNET response to single characters seems to be slower.  Obviously
	   this is hard to quantify.  It does just as well on large file
transfers.

	2) The ethernet controller seems to be able to bounce packets off of an
	   Echo server (730 sends "echome", Echo Server sends "Iamecho")
	   reasonably well, but not as well as without the UDA50.

	   The 730 is SLOW on echoing other peoples echo requests (730 receives
	   EchoMe, sends out Iamecho).  The other end DOES receive ALL of
	   the Iamecho packets, but too slow - after the timeout. So the client
	   complains that the packet was not echoed, then it sends out another,
	   then you get the first packet and it complains it is out of order
then
	   it says that it never got packet 2 back, then it send packet 3, then
it
	   gets packet 2 and complains it is out of order... This all does bad
things
	   to the protocols when you are trying to do real communication.  I am
	   assuming that it is delays in getting the bus...If it were delays in
	   getting the bus for data transfers, it loose things on receiving. It
could
	   obviously be late on transmitting. So, it must be delays on
interrupting.
	   There is not evidence on the bus control lines to support either of
	   these. The bus is mostly idle, with activity from the ethernet if it
is
	   in, the DMR, and the DMF.

	3) By the way, all this acts the same even if the RA60s are not even
	   spun up!!!

DEC's response:

	1) The UDA50A hogs the bus. That is why it was put at the end, after
	   everyone else. It polls a table in memory continuously. DECNET can
	   be expected to run slightly slower.

My findings:

	1) The UDA50 is not doing ANYTHING on the bus. None of the grant
	   lines ever get down to the UDA50, indicating that it never requested
	   the bus. The fact that Bus Busy is not active indicates that it does
not
	   already have the bus. In any case it would have to re-request it
after
	   someone else used it. The possibility exists that they are doing
	   something funny. None of the control lines are doing anything funny,
	   or indeed much of anything at all, especially when you unplug the
	   cables to the DMF and DMR; yet the ethernet behaves the same.

	2) This all leads me to a conclusion that counterdicts what DEC said;
that
	   it does not poll a table and hog the bus, and that it must be a
software
	   problem keeping the ethernet software from running. I asked Joe
Sofia
	   of DEC to come out and show me the UDA polling so that I could
	   understand the poblem. He replied that he would be glad to, but
since
	   the problem was with a forgien device, he would have to charge us
for
	   the call.


HELP !!!!

clark.wbst at parc-maxc
ucbvax!clark.wbst at parc-maxc
siesmo!rochester!rocksvax!clark