scott@stl.stc.co.uk (Mike Scott) (05/12/87)
I have been trying to set up a dma link between 2 Qbus machines (uVAX-VMS and LSI-11/23). This will have to have a sustained data of around 60kbit/sec for several hours. The available DEC boards seem to have problems. Does anyone have any experience with these boards, can anyone tell me what I'm doing wrong (?), or suggest alternative boards? 1. DRV11WA. The hardware book says ok to use as interprocessor link. BUT must start receiver off first. And there's no way to do this without having a working interprocessor link... DEC's solution is for the transmitter to poll its csr to see if the receiver is ready, then to initiate the DMA transfer: but then, why bother with a dma board in the first place?- such a procedure has to be either slow or inefficient. The VMS drivers book says no support for link applications, which isn't very helpful: XADRIVER certainly (even in VMS 4.6) doesn't support the polling DEC are now suggesting, not that I'd care to use that idea. 2. DRQ11CA. Not quite as bad, except that the last transfer can go wrong on output. The board initiates an interrupt before the handshake sequence on the last transfer is complete, so there's a race between the external device reading the last word, and the host starting a new transfer and overwriting it. Not such a problem as for the DRV11WA provided both ends are dma, since bus latency delays are generally short enough that you can afford to wait a little to be sure the last transfer is done. 3. DEQNA The hardware is DMA, but VMS operation involves moving the data between system and user buffers (I think?) and is not efficient enough for my application. My experience anyway is that the DEQNA is not reliable enough- a test program using qio level calls to the DEQNA driver fell over regularly and frequently with an unexplained timeout error status. ---- DEC have not been helpful with these problems. #1 has their comments in it. #2 went round and round their system (in the context of the UNIBUS board, the DRU11CA) before they said "there is no problem" (I gave up eventually!). #3 has been in the DEC system since early March without useful response. ---- Regards, Mike Scott scott@stl.stc.co.uk <or> ...seismo!mcvax!ukc!stl!scott -- Regards Mike Scott ( scott@stl.stc.co.uk +44-279-29531 x3133)
ted@blia.BLI.COM (Ted Marshall) (05/15/87)
In article <540@acer.stl.stc.co.uk>, scott@stl.stc.co.uk (Mike Scott) writes: > 3. DEQNA The hardware is DMA, but VMS operation involves moving the data > between system and user buffers (I think?) and is not efficient enough for my > application. My experience anyway is that the DEQNA is not reliable enough- a > test program using qio level calls to the DEQNA driver fell over regularly and > frequently with an unexplained timeout error status. The timeout error is due to a design problem in the deqna. The latest rev of the card fixes this. I believe that DEC will exchange an old card for the new (for a small charge if not under DEC maint.). On VMS, you need at least version 4.4 to get a change to the driver that completes the fix. However, I expect that you are right that the driver is too slow for your needs. It is designed for use by multiple processes, receiving different protocol types. This requires receiving into system buffers and then copying into the user buffers. I suspect that this is not what you need. Note also that for any of these devices, you need to use some sort of protocol for retransmitting bad or lost packets. Even on a well installed Ethernet with only the two stations, there is a non-zero chance of losing a packet. This applies to just about any kind of inter-process link. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer. "My hovercraft is full of eels" *fnord*