This message is from the T13 list server.
> > I'd very much like to connect on this. > > In design, there's nothing like not thinking > > about a problem to make it then appear. > I think you are misunderstanding. Thank you again for offering me this hope. > The sender is NEVER allowed to send "garbage" bytes > for a command in which the command execution > is expected to be a success > (i.e. as soon as it does send any such bytes, > it must then follow up with ultimately > indicating the the command failed, > and thus is then usually retried). Superb. The major-vendor hard drives that reportedly do so (and include the extra garbage in their Crc) then are more or less clearly out of spec. Can anyone easily quote specific chapter & verse from the spec for me here, something I could forward to justify a special effort to overcome this incompatibility, yet more specific than "just buy Maxtor"? > The sender can always pause the transfer > whenever it wants. But it must pause > it when it runs out of user data to send, Or the sender may terminate and later restart any time it runs out temporarily, yes? For example, while recovering from a soft error as common as, or more common than, say, once per gigabyte? > The sender can always pause the transfer > whenever it wants. But it must pause > it when it runs out of user data to send, > or is informed by the receiver > that there is no space in the receiver > to hold the data. When the condition that generated > the pause is cleared, then data transfer can resume. > > A receiver can always force a pause whenever it wants. > But it must do so when it runs out of space > to store the data. > > Since timing conditions prevent > the ability to insure that pauses are "on the dime," > the receiver must, under some circumstances > (all specified in the protocol) > pause when it still has a few bytes of fifo space left. > > A lot of designs just always pause when there is some > space left to make sure that no over run occurs. So far so good. Sorry to say, I lost you after that. I don't see an answer to my core question: > > Help me get straight on the standard first? > > > > Should I believe the claim I hear: > > that Ansi UDma allows the sender (host when writing, > > device when reading) to clock zero, two, or four bytes > > of extra garbage past the terminating pause? Pending a free, fast, & good answer to that question, I'll go ahead and post separately to answer what you said specifically. I'm pleased to share I think you have pinpointed many of the areas where your experience, perhaps centered on Ata-connected non-removable media, differs from my experience, centered on "removable media, exchangeable heads, variable block sizes, and the use of commands not standardised before both the host & the device shipped". Thanks again in advance. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
