On Sat, 9 Feb 2008 11:34:35 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote:
> 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. My tests here were receiving a video stream whose resolution is 720x480x30fps, 16 bits/pixel. That means a 20.736 MB/s (about 166 Mbps) stream rate (without USB oveheads). A cat /proc/bus/usb shows this: B: Alloc=480/800 us (60%), #Int= 0, #Iso= 2 > > > 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 > Cheers, Mauro - 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
