This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/14/01 05:37PM > ... As ... I keep on pointing out, > you're trying ... something that just is not needed. Again I find your remarks consistently helpful, thank you again for your patience. Maybe I've been having trouble distinguishing a claim that noone should care from a claim that people can't reproduce my results. Please feel free to include technically redundant language to help me make this distinction. > If the host is sending you more bytes > than you should have for the command, > then it is a bad host (as Hale would say). I wonder if this English is slippery in exactly the right spot? Let's try the example Scsi Cdb of x 2A 0 00:00:00:00 0 00:12 0 i.e. a write of the x12 blocks at Lba 0. If, out of band, the host and device have mutually agreed that each block contains x200 bytes, then yes only a Bad Host will move out more than x12 * x200 = x2400 bytes. But now let's suppose the Bad Media refuses to let the device move more than 3 blocks. And let's suppose our device, in Pio/SwDmw/MwDma modes, accordingly moves just 4 * x200 = x800 bytes and then stops the transfer. If we change to use merely standard Atapi UDma, now we see a difference. Rather than x800 of x2400 bytes moving out, when connected at UDma33, we see as many as x804 bytes move out. To eliminate this difference, a device (here the receiver of clocks) can try to pause at block boundaries ... but unless the host cooperates, for example with a turnaround delay at block boundaries, in UDma more than x800 bytes will move out. Here we see Change. And Change Is Bad, for interoperability - for plug 'n play beyond the latest Windows, beyond the installed base of Windows, out into the wild world of the Windows to come and the things that aren't Windows. > "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/14/01 05:37PM > Since our products don't suffer any of these problems, > I'll leave it to others to carry it on from there. Over Christmas I hope to work on vanity-publishing precisely how to demo how these issues arise with more and less direct Windows connections to an Ata hard drives. I agree an adequate workaround for not counting bytes accurately is to accompany any inaccurate count with an ERR and to agree out-of-band that the count of data moved with ERR doesn't matter. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
