On Tue, 12 Feb 2008, Mauro Carvalho Chehab wrote: > > 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.
Actually the situation isn't quite this bad. Going back to section 5.4.1, the text says that the table calculations assume that no bit-stuffing is required. Thus, they attempt to be "average" usage values rather than "worst-case" values. > 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 This by itself doesn't mean much. To make sense of it we would need to see the parameters for the two Isochronous endpoints in use. 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
