0
\$\begingroup\$

I am doing measurements related USB delay with USB-UART converter chip(CP2102 Silicon laboratories chip). I am sending array of data, when 0xee is received the microcontroller will echo the byte. I am taking time stamps between instant i start sending the data to until I receive the 0xee. To find out the processing time at CP2102 chip I have measured chip ack delay(It is the time between point packet to the instant ack packet received from the chip). USB-UART chip is bulk device with two end points(IN and OUT)max packet size of 64 bytes, USB2.0 full speed usb(12Mbps) is used. I am taking 500 samples for each data size(1 byte sent 500 times and measurements are taken, similarly 2 bytes until 127 bytes).

I have plotted three graphs one for total_delay, chip_ack_delay and total_delay_without_uart_delay_chip_ack_delay = total_delay - chip_ack_delay - 86.6*data_size This delay should represent processing delay and USB polling delay at the host computer. I am using Linux PC with Ubuntu 16.04, UART baudrate is 115200(hence 86.6 microseconds per byte). It is understandable that chip ack delay increases as packet size becomes more than 64 bytes since it has to wait for two transactions. I am not able to interpret second plot It is showing host side polling and processing delay decreases as packet size becomes more than 64 bytes, Can someone explain how to interpret this? Or Am I missing something here?

By the way, I measured chip ack delay using USBmon log. In the graph x-axis is data size, y-axis is MATLAB boxplot shows the range of values of delay measured for particular data size.

enter image description here

\$\endgroup\$
  • \$\begingroup\$ To understand timing, you need to realize that you are dealing with the following chain: host app -> host driver -> USB protocol -> UART conversion -> UART transmission > MCU UART driver > MCU app searching for EE marker -> MCU UART transmission -> UART-to-USB conversion -> USB protocol -> USB host driver -> host application. There could be many quirks in interaction/synchronization between all these boundaries along this pipeline. \$\endgroup\$ – Ale..chenski Nov 13 '17 at 19:03
  • \$\begingroup\$ Also, you need to learn a bit more about USB protocol, aka SIE - serial interface engine. What do you mean "point packet" and "instant ack packet received from the chip"? Instant ACK packet comes in less than 1.7 us from the chip, otherwise the host will detect "transaction error". \$\endgroup\$ – Ale..chenski Nov 13 '17 at 19:15
  • \$\begingroup\$ @Al I have exact setup as you explained. I subtract the delay related to UART transaction that is 86.6 micro seconds/byte and chip ack delay. MCU app is very simple, I have written logic inside uart interrupt handler, As soon as byte is received I compare with 0xee if it matches i echo the byte. Regarding the time instant, I take time stamp before writing data to serial port, again I will take time stamp after receiving echo. I subtract the old time stamp from the new one. Regarding USB stack delay, I understand that stack and driver add some delay but that should be some constant. \$\endgroup\$ – yadhu Nov 13 '17 at 22:41
  • \$\begingroup\$ Does ack has to come within 1.7us? I am not sure USBmon is showing lot of delay before the ack is received. I can attach a USBmon, If you would like to have a look. \$\endgroup\$ – yadhu Nov 14 '17 at 11:21
  • \$\begingroup\$ I am talking about USB protocol ACK at USB packet level. I don't know which "ack" do you mean, that's why I suggested to be more accurate in terminology when your question title says "USB delays", and you throw in some unknown terms like "point packets". \$\endgroup\$ – Ale..chenski Nov 14 '17 at 16:09
1
\$\begingroup\$

The datasheet of the CP210x mentions large-ish FIFOs on both transmit and receive side.

I strongly suspect that they also optimize usb (and host cpu) utilisation by "collecting" uart data in larger USB packets.

This would mean that data is hold back until there are either 64 byte in the FIFO or the receiver was not active for a few bit times.

Note that bulk 64 byte packets are special: They don't finish a transaction in the host (unless a buffer was too small).

You can actuall see a "high dip" for the 64 byte transactions, as these could be executed as one 64 byte packet followed by a zero byte packet.

Side note: It might be worthwhile to re-check timings with an USB 2.0 high speed hub between the PC host and the CP210x. This configuration could use the 0.25ms 0.125ms mircoframe timing available in high speed.

\$\endgroup\$
  • \$\begingroup\$ I don't have any hardware sniffer, I am measuring all the timings in software. Do you mean the host controller waits for next bytes for some time before sending a USB packet if it is less than 64 bytes? \$\endgroup\$ – yadhu Nov 13 '17 at 15:59
  • 1
    \$\begingroup\$ Microframe timing in HS mode is 0.125 ms not 0.25. \$\endgroup\$ – Ale..chenski Nov 13 '17 at 18:53
  • \$\begingroup\$ I don't think any of the CP210x chips support High speed mode, Data sheet specifies only full speed. USB frame width in full speed is 1ms, I am not sure whether the frame width plays role for the case of bulk end points. \$\endgroup\$ – yadhu Nov 13 '17 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.