This message is from the T13 list server.
In general I agree that error handling is not an area that normally needs optimization, however, even though error handling is often lovingly referred to as "exception handling" which makes it sound like it is something we don't normally need to worry about. The reality is that in the ever growing AV streaming modes that everyone is moving toward, the proper and timely handling of errors has become ever more critical. I know I love when I listen to a song or watch a video with little or no hesitiation even in a bouncy SUV or while jogging with my new MP3 player with a 20G hard drive. >From the clarification I saw from someone elses post, its sounds like there is >an issue with certain bridge controllers that is resulting in a hang condition >(NOT GOOD) on the interface and that needs to be resolved. I just hesitate to >agree with a method that sounds terribly similar to something we had in days >of old that lead to a bunch of programming of soft timers to insure things >were in proper states since some hardware asserted signals at slightly >different times. Also, as the speed of the devices (hosts, bridges, etc) >monitoring these status signals increases, the likelyhood of finding timing >glitches also increases. Example: is it is virtually impossible to clear DRQ >at exactly the same time that ERR is set. Hence there will always be some >sort of overlap where the state is undefined (DRQ -> 0 whiles ERR -> 1). That >is the window I am concerned about. Like I said, it sounds like something that we dealt with with many years ago. gary > From: Jeff Garzik <[EMAIL PROTECTED]> > Date: 2004/11/15 Mon PM 03:59:36 EST > To: Pat LaVarre <[EMAIL PROTECTED]> > CC: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, Thomas Colligan <[EMAIL PROTECTED]>, > Hale Landis <[EMAIL PROTECTED]> > Subject: Re: [t13] e04155r0 - DRQ=0 When ERR=1 Feature > > This message is from the T13 list server. > > > 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 > > > gary laatsch [EMAIL PROTECTED]
