> -----Original Message-----
> > 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).
>
Thanks.
> > 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.
>
Our design's USB topology is as follows:
FS device #1 -| |
FS device #2 -| |
|-- HS Hub #1--|-------|
FS device #3 -| | |
FS device #4 -| | |
| | -- HS Hub #3 -- | --------| USB 2.0 HS Port on USB Host
FS device #5 -| | |
FS device #6 -| | |
|-- HS Hub #2 --|-------|
FS device #7 -| |
FS device #8 -| |
All of the hubs support Multi-TT. Based on this topology, I would assume Hub #1 and Hub #2 perform the FS splitting, and the EHCI controller on the USB host performs the FS un-splitting. Hub #3 would only be passing high speed traffic between Hubs 1/2 and the PC. Is this correct?
Does this hub topology and Multi-TT support mean that mean each USB device could be able to support up to 15 64-byte interrupt endpoints?
If that is true, then would the high speed 63 interrupt transfers (@ 64-byte) limit become the bottleneck?
> > 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.
USB high-speed interrupt transfers can still be sent over all of the 8 micro-frames?
>
> > 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?
The PC has XHCI, EHCI and OHCI enabled. Test setup #1 is connected to a USB 2.0 port and the lsusb output shows the FS devices on the USB 1.1 bus. I think this means the OHCI driver is in use, but I'm not certain.
>
> > 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.
>
That makes sense. When FS and HS devices are mixed on a USB 2.0 hub (and USB 2.0 port on a PC), how is the interrupt transfer limitation calculated?
Does a FS interrupt endpoint (@ 64 bytes) count as 1 of the HS 63 transfer limit? Or does the scheduler handle multiplexing the FS transfers over the available 252 (4 micro-frames with 63 transfers available)?
Thank you for your help. I'm trying to get a better understanding of the USB limitations, so our design does not fail as the system expands.
-Nate
--
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
