This message is from the T13 list server.
> From: Hale Landis [mailto:[EMAIL PROTECTED]] > I just wanted to add here that I will stop posting > my replys ... here I'll miss the support & help I get offline & online, though certainly I'll be pleased if I start feeling heard as much offline as I do online. I'd welcome an offline person-to-person reply to me if anyone does object to us continuing my education here? I haven't heard any complaints since imposing the flame limit of one post/ topic/ author/ day. > From: Elliott, Robert (Server Storage) [[EMAIL PROTECTED]] ... > The SCSI architecture model requires byte > granularity for data transfers by all SCSI > transport protocols (see sam3r04 section 5.4.3 > - Data transfer protocol services). Good to see this real need formally acknowledged. > > I don't see T13 doing anything to change the > > ATA/ATAPI parallel interface data transfer > > protocols. > > It's obviously survived without byte granularity so > far. I beg to differ. Atapi Pio has byte granularity on offer, for anyone who wants it. Only Dma is broken. > Other serial SCSI protocols all have ways to > indicate odd lengths (often with a "number of pad > bytes" field). Thanks for saying, I didn't know that. > From: Hale Landis [mailto:[EMAIL PROTECTED]] > Pat, do you think there can be more than one pad > byte in any PIO or DMA data transfer? I think Yes, but I'm not convinced I understand the question properly. 1) Of course there "can be". Ops can be designed to always includes lots of pad bytes no matter the transport, much like T13's Atapi Command Out always rounds up the Cdb Length to 12 or 16. But in context here, I think we mean to be discussing how many pad bytes does Ata/pi Pio/Dma data transport force the host & the device to add, beyond what they would agree to copy over a byte-wise synchronous connection, like the full handshake of classic so-called "asynchronous" 8-bit Scsi. 2) Agreed, whenever the host & the device do agree out-of-band in advance how many data bytes to copy which way, then Ata/pi Pio/Dma never forces them to add more than one pad byte. However, such an agreement by definition cannot be in place if the command in question is a new standard or an old proprietary command. 3) Furthermore, even with a nominal agreement, as Dma burst rates increase past SwDma, when the end of the bus clocking the data asks to copy more than the other end, we can end up with more than one pad byte. For example, I'm told many devices stop asking to copy read/write block data sometime near the first block in error. Any time that does happen, the device has stopped the host short. > ... Yours at least til Thursday, Pat LaVarre
