On Mon, 29 Jul 2013, Stoddard, Nate (GE Healthcare) wrote: > According to the USB 2.0 specification, 19 full speed interrupt > endpoints (@ 64 bytes) can be scheduled. I have a couple of > questions about this specification and the Linux kernel's > implementation: > > 1. Does this number take the USB requirement that "no more than 90% > of any frame be allocated for periodic full-speed transfers" into > account? No. You can tell because the table says that there would be 37 bytes remaining, which is less than 10% of the 1500 bytes total. The text also mentions that the tables do not include the overhead associated with bit stuffing. You'll get a more accurate picture from the formulas in section 5.11.3. They indicate that only 15 64-byte full-speed interrupt transfers should be possible during a frame (about 59 us per transfer). > 2. Does the full speed limitation apply if full speed devices are > connected to high speed hubs? It applies to the subset of devices attached to any particular Transaction Translator. Some high-speed hubs have a separate TT for each port, whereas others have only a single TT. > 2a. If the high speed limitation is used: Does the scheduler > multiplex each full speed device's split data packets over the 8 > available micro-frames? To some extent. Not all 8 microframes are available (the spec prohibits sending a Start Split packet during microframe 6), and the current ehci-hcd implementation is not capable of using all the ones that are available. However, it is capable of using at least 4 of the 8 microframes. > We performed some testing, but I don't want to make assumptions on > these results alone. > Setup #1: > Kernel 3.10.0 > Connect 6 USB devices (each with 2 IN and 1 OUT interrupt endpoints > @64 bytes) to USB 1.1 full speed hubs to a PC USB 2.0 port. The test > application can communicate with all 18 endpoints. When we connected > a 7th device, the test application is unable to open and access the > device. This makes sense because that would be 21 full speed > endpoints. This doesn't sound right. What sort of host controller were you using? > Setup #2: > Kernel 3.10.0 > Connect 7 USB devices (each with 2 IN and 1 OUT interrupt endpoints > @64 bytes) to USB 2.0 high speed hubs to a PC USB 2.0 port. The test > application can communicate with all 21 endpoints. This appears to > violate the full speed limitation; however, it wouldn't be violating > the high speed limitation of 63 endpoints per micro-frame. The limitation you are referring to (Table 5-8 in the spec) is for interrupt transfers to high-speed devices. It does not apply to interrupt transfers to full-speed devices. 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
