This message is from the T13 list server.
Amen! Thanks TC On 11/15/04 12:59 PM, "Jeff Garzik" <[EMAIL PROTECTED]> wrote: > Pat LaVarre wrote: >> Jeff G: >> >>>> In reading the proposal, it seems that there is a issue. Enough so >>>> the write >>>> a proposal. If the state does occur as the proposal describes, then >>>> the bad data is read >>>> to clear the DRQ. A performance issue and as you comment, issue a >>>> soft reset >>>> and re-issue the command. How long does a soft reset take >>>> (performance hit). >>> >>> >>> When you are getting into error states, you may assume that >>> performance has _already_ gone out the window. >>> >>> When writing error handling code, focus on _correctness_ not >>> performance IMO. >> >> >> In principle I agree ... except for when correctness and performance >> become available together, I also remember anecdotes like USB DVD/CD >> burners creating coasters because the host handling of unexpectedly >> short data was slow, and HDD appearing slower in one operating system >> than another, because one of the operating systems covered up >> non-repeating errors more rapidly ... >> >> Does your personal history of pain include no such episodes? > > Pardon the use of exclamation points, I normally abstain from the > practice, but: we are talking about error handling here! > > We don't need every ATA driver stack "optimizing" its error handling. > We need to encourage software authors to write software that handles > errors in the same, boring manner as everyone else. > > We're not talking about data transfer here. > Data transfer is the hot path, the part you optimize. > > Error handling is the 0.1% case that you _must_ get right. Performance > considerations do nothing but increase complexity. You get the > performance that correctness provides, and nothing more :) > > Jeff > >
