USB Hub vs performance

[Axel]

Hi,

With help of Jan's book, I've developped a program for the PIC 16C765 Microchip device. This PIC is USB1.1 designed.
My device with the PIC is seen as an USB1.1 HID device and is working fine. To exchange data, only reports are used through Control Transfers and EndPoint 0. Then each transfer is done with 1 SETUP packet followed by 2 IN packets (8 + 4 data bytes).

My question is about the performance.
When I plug my device directly to an USB2.0 port of my computer (under Linux), i can perform around 350 requests (getreport) per second.
If i insert an USB2.0 hub between my device and the computer (host), i can perform around 1000 requests per second.

In both cases, my device is still USB1.1 and i don't understand how the data transfer can be faster when a USB2.0 hub is present.

If someone has any idea to explain....

[Jan Axelson]

A USB 2.0 hub that connects to a USB 2 host communicates with the host at high speed and performs any needed speed conversions between attached low/full speed devices and high speed.

To minimize the amount of bus bandwidth used, the host uses split transactions, where the host initiates a communication and returns later to receive the data or other response from the device. 

Using split transactions leaves more high-speed bus time for other devices (the host doesn't have to waste time communicating at low/full speed) and can also enable the host to initiate more transactions with the low/full-speed device.

Here is an explanation from USB Complete Fifth Edition:

For bulk and control transfers, in the start-split transaction, the USB 2.0 host sends
the start-split token packet (SSPLIT), followed by the usual low- or full-speed token
packet and any data packet destined for the device. The USB 2.0 hub that is nearest
the device and communicating upstream at high speed returns ACK or NAK. The host
is then free to use the bus for other transactions. The device knows nothing about
the transaction yet.

After returning ACK in a start-split transaction, the hub has two responsibilities. The
hub must complete the transaction with the device and also must continue to handle
any other bus traffic received from the host or other attached devices.

To complete the transaction, the hub converts the packet or packets received from
the host to the appropriate speed, sends them to the device and stores the data or
handshake returned by the device. Depending on the transaction, the device may
send data, a handshake, or nothing. For IN transactions, the hub sends a handshake
packet to the device. To the device, the transaction has proceeded at the expected
low or full speed and is now complete. The device has no knowledge that the transaction
is a split transaction. The host hasn’t yet received the device’s response.

While the hub is completing the transaction with the device, the host may initiate
other bus traffic that the device’s hub must handle as well. Separate hardware modules
within the hub handle the two functions. When the hub has had enough time to
complete the transaction with the device, the host begins a complete-split transaction
with the hub.

In a complete-split transaction, the host sends a complete-split token packet
(CSPLIT), followed by a low- or full-speed token packet to request the data or status
information the hub has received from the device. The hub sends the information.

The transfer is now complete at the host. The host doesn’t send an ACK to the hub. If
the hub doesn’t have the packet ready to send, the hub sends NYET, and the host
retries later. The device is unaware of the complete-split transaction

[Axel]

Thanks Jan for your explanation.
Between host and usb 2.0 hub, no problem to understand why it's faster.
But between 2.0 hub and 1.1 device, how the packet management (setup+in+in) can be faster ?
The transaction scheme between hub and device is the same than between device and host when directly connected... it should take the same number of 1.1 frames and the same amount of time, shouldn't it ?
I've done new measurements, it's 5 times faster : 5000 requests (getreport) to the 1.1 device take 15 seconds without hub and 3 seconds through the hub (the getreport function on the host's side is a blocking function. Result of the report must be received before function is called again)

[Jan Axelson]

Yes, the traffic between the device and hub is at low or full speed, but because of the split transactions, the host doesn't have to wait for the transactions at lower speeds, and that frees up high-speed bus bandwidth for other things, and as a result, the host might be able to reserve more bandwidth for transfers with the low/full-speed device.

For example, with direct connect to the host, you have:
Low/full-speed Setup stage to 1.1 device, wait for completion
Communicate with other devices as needed
Low/full-speed Data stage to 1.1 device, wait for completion
Communicate with other devices as needed
Low/full-speed Status stage to 1.1 device, wait for completion
Communicate with other devices as needed
repeat

With a hub, you have:
High-speed Setup stage to 1.1 device, start split
Communicate with other devices as needed
High-speed Setup stage to 1.1 device, complete split
Communicate with other devices as needed
High-speed Data stage to 1.1 device, start split
Communicate with other devices as needed
High-speed Data stage to 1.1 device, complete split
Communicate with other devices as needed
High-speed Status stage to 1.1 device, start split
Communicate with other devices as needed
High-speed Status stage to 1.1 device, complete split
Communicate with other devices as needed
repeat

With that said, there is no bandwidth guarantee for control transfers other than reserving 10% of each frame for all low- and full-speed endpoints and 20% of each microframe for all high-speed endpoints. So if a design requires guaranteed bandwidth, better to use interrupt transfers.