Duplicated SOF

[nstjean]

I am doing a test between a PC and an embedded device, and I have a duplicated Start-Of-Frame “issue”, or, maybe is it a normal USB behavior.

A PC is sending a 200 bytes packet to a phytec device thru a usb cable. When the device receives the packet, it sends back a copy to the PC with few updated values. This sequence is repeated 10 000 times. The total time elapsed from first sent packet to last received packet is between 2.8 seconds to 4.9-5.0 seconds.

These values are close to:

(1 ms / 8 ) x 2 x 10 000 = 2.5 seconds (single SOF)

And

2.5 seconds x 2 = 5.0 seconds (when SOF are duplicated, with no data between duplicated SOF).

When sniffing the USB with a Ellisys USB Explorer, sometimes, the SOF packet is duplicated:

[SOF][SOF][TOKEN PING][ACK][TOKEN OUT][DATA0][[NACK]
[SOF][SOF][TOKEN IN][DATA0][ACK]
[SOF][SOF][TOKEN PING][ACK][TOKEN OUT][DATA1][[NACK]
[SOF][SOF][TOKEN IN][DATA1][ACK]
[…]

With duplicated SOF, total test time is about 4.9 seconds.

Some other times that "appear to be random”, there is one single SOF, and then, the total test time is about 2.8 seconds.


My question is:

Is there a way to always (or, most of the time) have one SOF per packet transfer?

[Barry Twycross]

First SOFs are irrelevant. Stop worrying about them.

Next, turn on NAKs (or stop hiding them). Are there NAKs in the empty frames. If there are NAKs, the problem is the device firmware. If there are no NAKs the problem is the host.

If the problem is the host, what's the host? What type of USB controller is it running? Under what OS? What driver is doing the data transfer on the PC? What endpoint type is the transfer to?

[nstjean]

Thanks Barry.

There is no NAK in the empty frame.

So, the host is a PC with Windows 8, running a C++ test application. The application uses winusb library. Endpoint is in bulk mode.

The device side runs on Linux.

[Barry Twycross]

I just reread your question. You've basically created a worst case scenario for USB.

To get maximum performance out of USB, you need to minimize the time that the bus is idle. To do that you have to rely on the hardware to keep the bus busy. To do that you need to use large transfers, and/or multiple overlapped transfers so that the hardware always has another packet to send.

Your app has none of that. To make life worse, the packet is not a multiple of maxpacket size, so any packet sent terminates the transfer. You can not make multiple packets at once. USB also has a habit of not signaling a transfer completion until an end of frame (EOF). That is coincident with when the SOF is sent on the bus, but the SOF is not your problem. The SOF is going to be sent anyway, its just marking the EOF.

USB does have large latency if you need to do round trips like this. If the data you send to the device depends on the data the device has sent you, there may be nothing you can do. The issue goes something like this:

1. Host application launches packet on USB. This may not appear on bus until the next frame. [SOF]
2. Device hardware receives packet. Hardware may not tell device application until end of frame [SOF]
3. Device processes packet and send back modified packet.  This may not appear on bus until the next frame. [SOF]
4. Host hardware receives packet, but does not tell host application until end of frame [SOF]
5. Host application processes data, goto 1

If the data sent to the device does not depend on the data in the last packet received, you can speed this up by using multiple overlapping transactions. Have you application launch a set of packets all at once on the USB. (I'd guess about five is a good number.) When you get a packet back, process it and launch another one. That way you'll always have multiple packets in flight and the round trip latency will not matter so much.

This requires you refactor your host application to be asynchronous.

You might be able to get away with making the packet size 512 bytes instead (assuming a high speed device). Then launch one transfer with n*packets, then read the return packets one at a time.

[nstjean]

Thanks for this detailed explanation.

I had figured that the 1/8 msec was a limitation to how I was doing this test. But, reading this 5 steps worst scenario, I understand why the round trip is between 3 and 5 seconds.

Thanks again,
Normand