On Mon, Sep 28, 2009 at 6:09 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> Where did you arrive at that "480e6" constant? Is that from the USB >> Spec? I saw you refer to it in another email. > > USB 2.0 Specification, section 1.1: > > "USB 2.0 addresses this need by adding a third transfer rate of 480 Mb/s to > the 12 Mb/s and 1.5 Mb/s originally defined for USB." > > Section 4.2.1: > > "The USB high-speed signaling bit rate is 480 Mb/s." Ah, scientific notation. For some reason, my brain saw "480e6" and read it as 0x480e6. Too much looking at hex dumps, I guess. :-) >> > You also have to take the USB overhead into account, so the actual value >> > will be a bit larger than that. 57% seems plausible. >> >> It was my understanding that the whole reason for the 80% max >> utilization was to account for overhead. > > Section 5.6.4: > > "The USB requires that no more than 90% of any frame be allocated for periodic > (isochronous and interrupt) transfers for full-speed endpoints. High-speed > endpoints can allocate at most 80% of a microframe for periodic transfers." > > 80% is to make sure there's still room for non-periodic transfers (control and > bulk). I'm pretty sure it doesn't take the overhead into account. Yeah, I had seen that section, and indeed it was what I was hoping to get a definitive answer on. >> And is it really plausible that there is a 14% overhead? That sounds like >> quite a bit. If it had been off 2-3%, that might have seemed reasonable, >> but 14% seems like a bit much. > > (57% - 51.2%) / 57% = 10.18% overhead. That's indeed significant, but not > completely implausible. I agree it's not *completely* implausible, although it does seem quite high compared to other protocols I have worked with. That's why I'm asking. >> I guess I'm just wondering how much of what you are saying is idle >> speculation based on your experience with Linux's USB implementation, >> and how much is actually based on the spec. > > There's always some interpretation of the spec involved, but I'm pretty sure > the information is accurate :-) Except for the overhead calculation, I haven't > double-checked how much bandwidth the overhead consumes. Even without any > overhead, we would still be at 51.2%, so two streams wouldn't be allowed. Well, on the bridge I am working with, I have some smaller alternates available. I figured I would start by posing the bandwidth question with as simple an example as possible (since 3072 is the maximum packet size permitted by the protocol). Anybody else want to chime in whether this is a normal amount of overhead? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
