On Tue, 12 Aug 2014, Alexei P wrote: > So, you say that protocol errors occur either to "noise", or "device crash". > If it is the "device crash", no amount of transaction retires will lead to > recovery. So it leaves the "noise". > > Under normal definition of "noise", in USB specifications, Section 4.5.1 > “Error Detection” indicates that “any glitches will very likely be transient > in nature”, and “be close to that of a backplane”. Standard communication > noise theory would suggest that if a link is incapable to recover in three > consecutive attempts, its probability of recovering must be close to zero. > That's why USB designers selected the number "3". Maybe the probability is close to 0, but it is nonzero enough of the time that people noticed and asked for this retry mechanism to be implemented. > When you say that "communication can be re-established", you are, in fact, > referring to some marginal cases, where a broken cable (or wrong > out-of-standard device/host termination, or unstable clock, or flaky power, > or internal hardware bug, or poor firmware implementation of USB protocol > engine in a device, etc.) cause flaky link behavior that results in > multitude of protocol errors. Therefore, by attempting the whopping 96 > retries, you hope to eventually receive right response. In result, the 32x3 > retry policy only hides the real problem behind XactErr in a particular > questionable link. It hides the real problem and permits the link to work, albeit in a degraded fashion. > So, this is not my "wrong initial assumption", it is a question of software > philosophy. Sooner or later the flaky marginal link will degrade into a > totally failing link. Maybe it will, maybe it won't. I don't have any evidence that it always will. > What would you suggest then? To increase the number of > re-tries to 255? To insert mdelay(50) between attempts? I think this > software philosophy is counter-productive. If the link fails totally, I do not suggest increasing the number of retries or adding delays. You may think the philosophy is counter-productive if you like. Don't argue about it with me; argue about it with the people who wanted the retry mechanism added in the first place. > I think that the USB host software should be able to identify bad flaky > links and provide a user (system administrator) with information about link > quality. With a general movement towards faster buses (and correspondingly > noisier links, USB3 and 3.1 and beyond), the host driver should be able to > provide statistics of retries, if any, and report it upon special request. > Just as it was long time before PC era, in DEC computers. > > What would you think about the idea of XactErr performance counters? It's a reasonable thing to do. Implementing it would require changes to quite a few host controller drivers. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
