On Sat, 9 Feb 2008, David Brownell wrote:
> On Friday 08 February 2008, Alan Stern wrote:
> >
> > > There's currently an issue with isoc transfers made by em28xx driver[1]
> > > and
> > > ehcd_hci. If I try to start isoc transfers on more than one hardware, the
> > > second hardware fails at usb_submit_urb() with -ENOSPC.
> >
> > ENOSPC means that you are attempting to use more bandwidth than the bus
> > allows. A high-speed isochronous transfer of length 3072 requires 41%
> > of the total bandwidth (according to Table 5-5 in the USB 2.0 spec),
> > and periodic transfers (isochronous and interrupt) on a high-speed bus
> > are limited to no more than 80% of the total bandwidth.
> >
> > Performing transfers to two devices would require 82% of the bandwidth;
> > hence it isn't allowed.
>
> Well, the USB 2.0 spec is internally inconsistent on that point.
>
> And when I've asked the USB-IF for resolution on that, or maybe
> issuance of an erratum, they've been silent. (Greg, maybe you
> can do something about that now? The issue's been reported for
> quite a few years now.)
>
> See table 5.5, at the bottom (section 5.6). Somehow it thinks
> that twice 41% is below the 80% limit (listed in section 5.6.4,
> paragraph 2). Similarly, table 5.8, at the bottom (section 5.7)
> which again repeats the 80% limit (para 1 of section 5.7.4).
> The 80% limit is referenced section 5.10 too.
Wow, I never noticed that. Although thinking back, I probably did see
other mistakes in those tables...
> Somebody at USB-IF was refusing to do some basic math, or has
> been ignoring this obvious spec bug. Either both those tables
> are wrong, or the three references to an 80% limit are wrong.
> There are no other resolutions to this bug.
I'm inclined to believe that the USB-IF meant the 80% limit to apply as
stated and the tables are wrong. As a simple example, let's consider a
high-speed Isochronous transfer of 3072 bytes. This actually goes on
the wire as three transactions, each of length 1024. According to the
bus-transaction-time formulas in section 5.11.3, each transaction
uses (in nanoseconds):
(38 * 8 * 2.083) + (2.083 * Floor(3.167 + BitStuffTime(Data_bc))) +
Host_Delay
Here Data_bc is 1024 and Host_Delay is unknown, assumed to be 0. The
BitStuffTime formula is: (1.1667*8*Data_bc). Doing the calculation
yields a total of 3 * 20546.7 ns = 61640.1 ns = 49.3% of a uframe --
not 41%. Even the single-transaction 1024-byte case comes out to 16.4%,
not 14% as the table says.
If you subtract out the overhead due to the SOF packet, it's even
worse. So clearly the tables are wrong.
> I'd be tempted to accept a patch teaching EHCI that the limit
> is really 82%, or whatever ... but I also think it's overdue
> for the USB-IF to correct their spec.
Indeed.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
