Re: USB 1.1 Full Speed OHCI slow/high latency

[Alan Stern <stern@rowland.harvard.edu>]

On Fri, Aug 15, 2025 at 11:39:03AM +0300, ValdikSS wrote:
> On 14.08.2025 7:40 PM, Alan Stern wrote:
> > Either .pcap files or the usbmon text output for both of these tests
> > would be good.  But set the number of iterations to something very
> > small, like 10 or so.  No point posting a log containing thousands of
> > repetitions of the same information...
> 
> Here you are, check the attachment. It's a 30 times loop.
> 
> Also tried the speedtest.py on an old HP T510 thin client (x86, VIA chipset,
> UHCI), and the speeds are fine.
> 
> Avg delta: 0.990 ms
> Min: 0.870 ms
> Max: 1.984 ms
> 
> My guess it's OHCI to blame.

The OHCI pcap file shows that transfers take place at intervals of 2 ms, 
which is perhaps slower than expected.  (The EHCI transfers take place 
at intervals of 0.625 or 0.875 ms, which is reasonable.)

I think the reason the OHCI transfers need 2 ms rather than 1 ms is 
because of the way the driver unlinks empty Endpoint Descriptors.  Lines 
1165-1168 of drivers/usb/host/ohci-q.c do this:

	/* clean schedule:  unlink EDs that are no longer busy */
	if (list_empty(&ed->td_list)) {
		if (ed->state == ED_OPER)
			start_ed_unlink(ohci, ed);

As a result, each time a transfer finishes the ED is unlinked, and each 
time a new transfer starts the ED has to be linked again.  Presumably (I 
don't recall all the details about how OHCI works so this is just my 
guess) those steps each require 1 ms, accounting for the 2-ms time 
interval between transfers.

You could try deleting or commenting out the last two of those lines to 
see if it makes a difference.  (Note that this is not a permanent 
solution; without the call to start_ed_unlink(), the memory used by the 
ED will never be freed.  A better approach would be to unlink EDs after 
they have been idle for some minimum time rather than right away.)

Of course, what's going on when you try to print something may be 
different from this simple test.

Alan Stern