Some other possibilities also come to mind: 1) perhaps you're supposed to take the report, combine the bytes, the speed, and the frame-rate to get the milliseconds, and then know that the bits on your high-speed device are faster than the bits on a full speed device.
2) XHCI can have multiple root ports for different legacy speeds (on the physical USB 2 bus) [and some XHCI controllers found in the wild actually work that way]. If this particular XHCI for the "problem" port is of that kind, you may be getting data about the full speed root port instead of the (desired) high-speed root port. There are two buses bonded in a USB 3 cable: a legacy bus (low/full/high speed) and a SuperSpeed bus. They operate concurrently over different wires. Bandwidth on the SuperSpeed bus is not relevant to how a device will work at high speed on the same port. (On the other hand, low/full/high speed devices share the same physical wires, so they share bandwidth.) If you remember EHCI/OHCI and EHCI/UHCI combinations, one approach to handling legacy speeds is to use a companion controller; the XHCI architecture allows something like this, by allowing the designer to have three "root ports" for one USB 3 bus. One root port handles SuperSpeed; one root port handles high speed; one root port handles full/low speed. The full/low speed port is only active when a full or low speed device is plugged into the root port. If a high-speed hub is interposed, "transaction translators" are used, and all XHCI traffic flows over the high-speed root port. Some vendors, to make the XHCI simpler, omit the full-speed root port and instead implement an embedded high-speed hub. So bear in mind that there may be embedded hubs in your system that are not externally visible. With all this, there's substantial room for confusion about which XHCI ports/buses go with which physical connectors on the system. Not sure whether this is helpful or randomizing. --Terry > -----Original Message----- > From: [email protected] [mailto:usb- > [email protected]] On Behalf Of Barry Twycross > Sent: Tuesday, April 14, 2015 17:33 > To: B.J. Buchalter; [email protected] > Subject: Re: Question about SS isoch bandwidth > > Has the device actually enumerated at SuperSpeed when this happens? > > Remember SuperSpeed is super flaky and a kinked cable can cause it to fall > back to a lower speed. I’d expect a fall back to high speed not full > though. > > Looking in the open source I do have (an interesting thing to do in any > case), I see it thinks the device is SuperSpeed on a low speed port. Which > makes no sense. It looks like a bug. > > On Apr 14, 2015, at 5:20 PM, B.J. Buchalter <[email protected]> wrote: > > > Hi Folks, > > > > I am seeing something strange on a test machine, and I am not sure if I > am doing something wrong, or if I have found a bug in OS X. > > > > I have a SS device that supports Isoch. I am using the > GetBandwidthAvailable() call from IOUSBLib to see how much bandwidth is > available for the device. > > > > I am running on MacBookPro10,1 and the machine is running 10.8.5. > > > > If I plug the device into the USB port on the left hand side of the > machine, the GetBandwidthAvailable() call returns 144 bytes per isoch > period (e.g. 1.1 MB/s or so). > > > > If I plug the device into the USB port on the right hand side of the > machine, the GetBandwidthAvailable() call returns 56240 bytes per isoch > period (e.g. 449 MB/s or so). > > > > If I run USB Prober and logging, I get: > > > > Left hand side of the machine: > > Apr 14 20:12:10.740 [2] > AppleUSBXHCI::GetBandwidthAvailableForRootHubPort - port(5) > portSpeed (0) deviceSpeed(3) - bandwidthAvailableInBlocks (1156) - > returning (144) > > > > Right hand side of the machine: > > Apr 14 19:57:06.825 [2] > AppleUSBXHCI::GetBandwidthAvailableForRootHubPort - port(6) > portSpeed (3) deviceSpeed(3) - bandwidthAvailableInBlocks (3515) - > returning (56240) > > > > It seems like the AppleUSBXHCI driver thinks that the root-hub port > speed is FS for the left hand port, vs. SS for the right hand port. > > > > Is this an OS bug (fixable by going to a newer OS), a HW bug, or > something I am doing wrong? > > > > I have not tried to start streaming on the EPs yet, but it seems like > the overall behavior of the GetBandwidthAvailable() is a bit weird on that > port, because when I set the alternate for the interface that actually has > the isoch ports, it succeeds. The Isoch EPs are configured to be 1024 > bytes per packet, with a polling interval of 1ms (8 micro frames). This > means that each EP should be consuming 1MB/s or so, but when that alt is > selected, the result from GetBandwidthAvailable() only goes down to 112 > (896,000 bytes/second). > > > > Does this mean that the bandwidth will actually be available on the port, > and that the GetBandwidthAvailable() call is returning incorrect data for > that port, or is the bandwidth more limited than one would expect on that > port? > > > > Thanks! > > _______________________________________________ > > Do not post admin requests to the list. They will be ignored. > > Usb mailing list ([email protected]) > > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/usb/barry%40nestlabs.com > > > > This email sent to [email protected] > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Usb mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/usb/tmm%40mcci.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
