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.
Best Answer
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.25ms0.125ms mircoframe timing available in high speed.