USB short packets and physical data packet length

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.

Reply to
brad
Loading thread data ...

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, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

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

Reply to
Peter Petersen

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.

Reply to
bcohen

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, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

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, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

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.

Reply to
bcohen

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

Reply to
Peter Petersen

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

Reply to
Peter Petersen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.