locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO


Dale Ghent
 

On Nov 24, 2020, at 2:44 PM, Bill Long <bill@outlook.com> wrote:

One more thing...

"What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself."

No, what I saying is that you cannot have a production environment be assumed to be clean of such actors. If they exist and can influence the environment in they way I suggested, that puts you in a compromised situation for updating critical components like firmware. Vectors are my point here, not the minutia of the protocol.
And such devices are replaced or repaired and life carries on. So what's the problem? It's the year 2020, not 2002. USB implementation is a well-known and well-learned practice among component manufacturers and such problems are very much the exception, not the rule. Certainly nothing to get all bent out of shape over the mere mention of USB on mailing list. And if a faulty device does happen? The world doesn't come crashing down; it's replaced. In the end, don't buy junk.

I cannot tell you how many times I've encountered people who complain about failed downloads from their ZWO camera when they're using that god awful flat USB cable that ZWO has chosen to include with their cameras. I cannot recall one instance where them replacing that cable with a quality one didn't fix their issue. The decision by ZWO to include this design was bad, to put it lightly, because it is a design that completely omits the RFI rejection qualities of a properly constructed cable. Was this the fault of USB itself? No. It was the fault of a vendor who either did not adequately test or appreciate the problems posed by the design they chose. These are the kinds of "problems with USB" that the typical person is going to encounter.

This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it.

Sure, but at least you have handshaking and retry logic in the TCP/IP stack (v4 or v6). You dont have that same level of session rety logic in USB at all. Thats my point. Lossy tech that is known to be faulty and easy to break is not something to build realiability on. Period.
I'm surprised you don't know this, but USB does have an error detection and recovery component to its protocol, and always has. This topic is covered in some detail by one Washington-based developer of a popular operating system, among other things:

https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/how-to-recover-from-usb-pipe-errors

and, specifically on the topics of STALL and CLEAR signaling:

https://techcommunity.microsoft.com/t5/microsoft-usb-blog/how-to-recover-from-usb-errors-part-1/ba-p/270707

As you might gather from the progression of the remediation steps, things get more drastic if the previous steps fail to return the session to a stable state. This is like TCP, which you pointed out, which has a retry process as part of its design (handshaking is not relevant to error recovery in TCP; it exists only to set up a session between two endpoints.) Failed retries eventually progress to harsher error states, culminating in the forced termination of the connection. Isochronous USB transfers would be analogous to UDP; which is why both are preferred for time-domain sensitive applications that cannot withstand the very expensive recovery methods that TCP imposes for missing or out of order packets (and out of order packets is not something that should never be encountered on a USB bus anyhow.)

The point is, USB is not "lossy". It is a stateful protocol, and like any stateful protocol it tries its best to deliver the data it is tasked with carrying.

/dale

Join main@ap-gto.groups.io to automatically receive all group messages.