clark.wbst@PARC-MAXC.ARPA (12/08/83)
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@parc-maxc ucbvax!clark.wbst@parc-maxc siesmo!rochester!rocksvax!clark
mogul%shasta@sri-unix.UUCP (12/09/83)
From: Jeff Mogul <mogul@shasta> The Xerox 3mb ethernet interface is a notorious Unibus-killer. There are some "ECOs" floating around that improve it; we always used to put it at the tail end of the Unibus, just to be safe. An un-ECOed 3mb interface on a 750's Unibus before an RK07 is guaranteed to give you a trashed disk; with the ECOs, it seems to work OK, but we don't have any UDA50s. Sorry, I don't know what the changes are supposed to be. -Jeff