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.

b...@example.com wrote:

> 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?

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, <http://www.vl.com.au>;
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Hi Mark,

> 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.

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.

> So yes, IIUC a pipe with max=512 will always occupy a timeslot
> equivalent to a packet of 512 bytes

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.

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

A small max packet size will decrease efficiency due to the added protocol
overhead associated with each packet.

Peter

In article <6...@mid.uni-berlin.de>, Peter Petersen wrote:
> 
> 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.
>


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.

Peter Petersen wrote:

> 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.

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???

> 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.

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???

> A small max packet size will decrease efficiency due to the added
> protocol overhead associated with each packet.

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, <http://www.vl.com.au>;
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall wrote:

> but I'd be very surprised if the USB 
> arbiter worked on actual packet sizes and not max paxket lengths???

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, <http://www.vl.com.au>;
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

In article <s...@localhost.localdomain>, b...@scan.nospam.echo.com wrote:
> 
> 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.


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.

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.
>
> Yes, but what is the size of the reserved slot?

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.

> 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???

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.

> 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???

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

>> 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?

As fast as it can. It will loop though all currently open Bulk/Control
pipes/endpoints and poll each one in turn.

> According to _USB Complete Thrid Edition_, the
>> bInterval for bulk endpionts indicates the endpoint's maximum NAK
>> rate.

bInterval for Bulk endpoints is ignored by most USB host stack
implementations. USB host controllers do not know about this value.

> Is the miminum latency for new IN transfers one micro-frame?

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