1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

USB short packets and physical data packet length

Discussion in 'Embedded' started by brad, Jul 4, 2008.

  1. brad

    brad Guest

    On the USB physical bus, are endpoint data packets always exactly
    wMaxPacketSize in length and zero padded when the requested data
    size is smaller than wMaxPacketSize or are the data packets physically
    the size of the requested data size? I can't seem to find how
    zero length and short packets are physically handled. Is a
    short packet only logically short or physicall short also?

    In other words, if we define a bulk endpoint as 512-bytes, is it
    wastefull of bandwidth if the endpoint is also used for transfers
    that are all alwyas very much smaller than this maximum packet size?

    Is it more bandwidth efficient to simply define a second endpoint with a
    smaller wMaxPacketSize?

    I'm very new to USB and this is on a Phillips LPC2888 which handles
    most of the low level USB protocol with its onboard USB controller
    but the question is for USB in general.


    Thanks.
     
    brad, Jul 4, 2008
    #1
    1. Advertisements

  2. IIUC, USB transfers are organised as transactions in a microframe. The USB
    host arbiter will allocate timeslots for transactions based on the pipe
    type, maximum packet size of each pipe and the availability of data.

    So yes, IIUC a pipe with max=512 will always occupy a timeslot equivalent
    to a packet of 512 bytes, regardless of the number of bytes in the packet
    (not being familiar with the physical line protocol, I'm not sure you can
    say that it's "padded" at all, but this is completely irrelevant from a
    software POV).

    The corollary is that a smaller *max* packet size will free up more of the
    microframe for other transfers.

    That's my understanding - happy to be corrected.

    Regards,
     
    Mark McDougall, Jul 4, 2008
    #2
    1. Advertisements

  3. Hi Mark,
    This is only true for (rarely used) Isochronous endpoints and Interrupt
    endpoints, but not for Bulk or Control. Even for Isochronous and Interrupt
    endpoints, the bandwidth is only reserved in each [micro]frame but made
    available for other Bulk/Control transfers if no transfer is required in
    this particular [micro]frame. USB never wastes a "timeslot" doing nothing
    when Bulk or Control transfers are pending.
    No. As long as no transactions are requested from the host, a Bulk endpoint
    consume no resources on the bus. When the host does request a
    transaction, only the number of bytes to be transferred appear on the bus
    (plus the protocol overhead, of course), which can be any value between 0
    and 512 bytes.
    A small max packet size will decrease efficiency due to the added protocol
    overhead associated with each packet.

    Peter
     
    Peter Petersen, Jul 4, 2008
    #3
  4. brad

    bcohen Guest


    For Bulk endpoints, how often does the host controller poll the target's
    IN endpoints to see if a completely new IN transfer is waiting to begin?
    According to _USB Complete Thrid Edition_, the bInterval for bulk endpionts
    indicates the endpoint's maximum NAK rate. Is the miminum latency for
    new IN transfers one micro-frame?

    Thanks.
     
    bcohen, Jul 4, 2008
    #4
  5. Yes, but what is the size of the reserved slot? I understand that if no
    packet is waiting, there is no slot reserved as these transfes are "on
    demand" and dynamically allocated, but I'd be very surprised if the USB
    arbiter worked on actual packet sizes and not max paxket lengths???
    Yes, but again, what timeslot is allocated within the frame? I don't see
    why an endpoint would have to specify a maximum packet size if the host is
    looking at *actual* packet sizes for each microframe???
    My argument was that small packet size would be more bandwidth efficient
    over a large packet size where the actual number of bytes was *always*
    smaller. Of course my argument assumes the validity of my earlier points.

    Regards,
     
    Mark McDougall, Jul 4, 2008
    #5
  6. Further on this point, how would it work for incoming packets? USB devices
    are polled for data ready - you're implying that each device would have to
    somehow send the size of each and every packet back to the host during
    this polling so it could calculate how many devices to receive from in the
    next frame?!?

    Convince me so.

    Regards,
     
    Mark McDougall, Jul 4, 2008
    #6
  7. brad

    bcohen Guest


    Answering my own post.. After furter reading it seem that a Bulk endpoint
    is polled by the host controller at a rate based on the bInterval
    descriptor field. The device's IN (tx) endpoint should NAK if it is not
    ready to send the next data for an existing transaction or to indicate that
    no new tranasction is ready to begin. It seems reasonable that although a
    poll/NAK is relatively lightweight, it can still waste a lot of bandwidth if the
    polling interval is much greater than is required by the application. It also
    seems that USB is a truely brain damaged protocol.
     
    bcohen, Jul 5, 2008
    #7
  8. Mark
    Actually there is none. When a USB driver on the host requests to handle a
    particular interface of a newly attached USB device, the USB host stack sums
    up the combined Isochronous bandwidth of all currently configured devices
    plus the new one. If the result is more than the bus can handle, the driver
    is denied access to the device. During actual transfers, no reservation
    takes place. Data is simply transferred when requested by host driver. The
    bus is never overloaded as Isochronous and Interrupt endpoints are processed
    at most once per [micro]frame. There is no limit on how many times Bulk and
    Control endpoints can be processed in each [micro]frame.
    The max packet size is used to calculate the max Isochronous bandwidth a
    device might require. It is used to decide if the device can be used at all.

    The max packet size is also required to tell both the host driver and the
    device device how much buffer space they need to coummnuicate with this
    device.
    No timeslots are allocated. When a packet is to be transferred, it is
    transferred. For IN transactions, the host controller does not know in
    advance how long this will take, and it does not need to. Once the
    transaction is done, it moves on to the next one.

    Peter
     
    Peter Petersen, Jul 5, 2008
    #8
  9. For Bulk endpoints, how often does the host controller poll the
    As fast as it can. It will loop though all currently open Bulk/Control
    pipes/endpoints and poll each one in turn.
    bInterval for Bulk endpoints is ignored by most USB host stack
    implementations. USB host controllers do not know about this value.
    No, it is much smaller and depends on how fast the USB host controller can
    read transfer descriptors over the PCI bus. Good controllers will cache such
    descriptors. For example, I have a fast USB flash disk from which I can read
    about 35MB per second. That's about 8.5 IN packets from a Bulk endpoint
    per microframe. The USB Spec says that - in theory - up to 13 packets can be
    transferred per microframe at 512 bytes per packet (bandwidth: 66MB/s). If
    your packets size is only 16 bytes, for example, you could transfer 105
    packets for a bandwidth of 16MB/s (USB 2.0 Spec, section 5.8.4).

    Peter
     
    Peter Petersen, Jul 5, 2008
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.