news@daver.bungi.com (09/22/90)
Hi George,
I am posting this message to the group since I assume others may find
it of interest.
I need a sanity check regarding SCSI psuedo DMA read / write operations.
As I understand it, psuedo DMA reads or writes cause the signal /nrdy
to be asserted until (a) the select SCSI device asserts its drqs
(DMA Request) line, and (b) two wait states have elasped since the
assertion of drgs. Furthermore, /nrdy may be asserted for an extended
period of time without interferring with DRAM refresh.
[ ] - Yes, give him a cigar.
[ ] - No, you dummy.
[ ] - Well, ......
The reason I ask is that off line I have been playing around with
a SCSI tape controller trying to get a feel as how best to structure
a device driver. Well this sucker from time to time introduces
substantial delays (at least relative to DRAM refresh periods ) between
assertions of the SCSI bus REQ signal. Assuming my above understanding
is correct, then psuedo DMA transfers will not cause DRAM refresh
interference. However, excessive DRQ hold-off could lead to
inefficient processor utilization.
By the way, the hold-off at least wrt tape reads, appears at the
very beginning of each 'datain' phase and during streaming breaks.
Change of subject directed to the Group:
Has any one thought about implementing SCSI disconnect / reconnect ??
Can anyone comment on the relative performance of systems with disconnect
versus those without ?? On the surface, it would seem the single threated
nature of Minix's FS could make implementation of disconnect a real pain...
Assuming there is a real performace win with disconnect, how should it
be implemented ?? Like the TTY suspend / revive ??
Best regards,
johnc
-- george@wombat.bungi.COM (George Scolaro) (09/22/90)
[In the message entitled "Sanity Check and 'Disconnect' Questions.." on Sep 21, 23:38, John Connin writes:] > > > Hi George, > > I am posting this message to the group since I assume others may find > it of interest. > > I need a sanity check regarding SCSI pseudo DMA read / write operations. > > As I understand it, pseudo DMA reads or writes cause the signal /nrdy > to be asserted until (a) the selected SCSI device asserts its drqs > (DMA Request) line, and (b) two wait states have elasped since the > assertion of drqs. Furthermore, /nrdy may be asserted for an extended > period of time without interferring with DRAM refresh. > > [X] - Yes, give him a cigar. > [ ] - No, you dummy. > [X] - Well, ...... An interrupt from the SCSI controller (which ever one is selected) will also de-assert /NRDY for the rest of the transfer. The idea, is that the driver will then get an interrupt and realize that the last packet was junked for some scsi error reason. Note also, that to use the pseudo-dma feature you must be very careful with the transfer code. Follow the scheme that Bruce commented in the monitor source. There is a fair bit of black magic to ensure maximum performance with the peculiar way the 532 handles the I-cache and I/O accesses (ie it has a major performance bug - which is documented in the monitor source). If the comments don't make sense, then drop us a line and we'll try and elucidate - if we can still remember all the details :-) > interference. However, excessive DRQ hold-off could lead to > inefficient processor utilization. Yep. > By the way, the hold-off at least wrt tape reads, appears at the > very beginning of each 'datain' phase and during streaming breaks. I would have hoped that the tape would only interrupt (via scsi) when the data was 'really' ready to be read. Is this an embedded controller type with a reasonable local buffer or a 'dumb' external controller? Dave & I are about to start playing with a embedded scsi tape drive also. We should get it in the next few days. If you have some rough code worked out we'd appreciate it if you email it to us, or any ideas you have. > johnc best regards, -- George Scolaro george@wombat.bungi.com [37 20 51 N / 122 03 07 W]
news@daver.bungi.com (09/23/90)
> > [In the message entitled "Sanity Check and 'Disconnect' Questions.." on Sep 21, 23:38, John Connin writes:] > > > > I need a sanity check regarding SCSI pseudo DMA read / write operations. > > > > As I understand it, pseudo DMA reads or writes cause the signal /nrdy > > to be asserted until (a) the selected SCSI device asserts its drqs > > (DMA Request) line, and (b) two wait states have elasped since the > > assertion of drqs. Furthermore, /nrdy may be asserted for an extended > > period of time without interferring with DRAM refresh. > > > > [X] - Yes, give him a cigar. > > [ ] - No, you dummy. > > [X] - Well, ...... > > An interrupt from the SCSI controller (which ever one is selected) will also > de-assert /NRDY for the rest of the transfer. The idea, is that the driver > will then get an interrupt and realize that the last packet was junked for > some scsi error reason. I saw the 'scsii' input in the wait PAL equations but didn't fully appreciate the design intent. Thanks for the clarification. > Note also, that to use the pseudo-dma feature you must be very careful with > the transfer code. Follow the scheme that Bruce commented in the monitor > source. There is a fair bit of black magic to ensure maximum performance > with the peculiar way the 532 handles the I-cache and I/O accesses (ie it > has a major performance bug - which is documented in the monitor source). Guess I had better take a peek at the monitor source code !! [ stuff deleted ] > > By the way, the hold-off at least wrt tape reads, appears at the > > very beginning of each 'datain' phase and during streaming breaks. > > I would have hoped that the tape would only interrupt (via scsi) when the > data was 'really' ready to be read. Is this an embedded controller type with > a reasonable local buffer or a 'dumb' external controller? First, take anything I say at this point with a grain of salt. I am still feeling my way around this sucker. The controller is a surplus Adaptec ACB-3530ga SCSI to QIC-36 streaming tape controller circa 1986. It has buffered write capability, but apparently no buffering on reads. At this point I have not taken a close look at the write characteristics. As I see it, interrupts (or lack thereof) is a function of how you have the host adapter SCSI controller programmed (eg. DP8490, AIC6250), and inturn, if generated, are generally the result of some change on the SCSI BUS. The pause that I am referring to occurs after the read command is issued and the bus phase has switched to DATA_IN, but before any data has been transferred: phase action -------- ----------- command issue read command, say for 2 512 byte blocks data_in pause (1) burst of 1024 bytes 1. If this occurs during a streaming break, then the pause is substaintially longer. Once the transfer begins, there appears to be no delays in the data stream. Now, I was about to say that I didn't see away to cause an interrupt at the point the controller is to ready send data unless the entire transfer is interrupt driven -- 1024 interrupts per block (something I was wanting to avoid). However, it just occured to me that the transfer code could initially be set for interrupt driven, and then upon receipt of the first byte be reprogrammed to DMA transfer mode for the remaining 1023 bytes. > Dave & I are about to start playing with a embedded scsi tape drive also. > We should get it in the next few days. If you have some rough code worked > out we'd appreciate it if you email it to us, or any ideas you have. Great.. Sorry, I don't have any code as yet -- I am still struggling with the device level code (NCR 53C90A). I will let you know when I have something. Best regards, johnc --