Re: USB 1.1 Full Speed OHCI slow/high latency

[ValdikSS <iam@valdikss.org.ru>]

On 14.08.2025 5:24 PM, Alan Stern wrote:
> On Thu, Aug 14, 2025 at 04:56:40AM +0300, ValdikSS wrote:
>> I have an old USB 1.1 Full Speed printer (Canon LBP1120) which can't print
>> large documents due to insufficient USB 1.1 transfer speed/high latency on
>> Linux.
>> I believe this may be Linux OHCI bug or deficiency.
>>
>> If I connect the printer to USB 2.0 port (uses "companion" OHCI controller),
>> the printing engine reports data underflow using its proprietary command
>> protocol, and the full-page picture fails to print (only 1/3 is printed).
> 
> Why on earth would a printer protocol have speed/latency requirements?
> That's just bad design.  It's not like printers are under any severe
> time constraints -- they won't blow up if they have to wait an extra ten
> seconds for the computer to send the contents of a page.

That's a very old printer from the lower-end segment, which have so 
little RAM that it requires page (not job) streaming from the PC.
AFAIK it has 512 KB of RAM, and the whole-page picture compressed to the 
printer language (CAPTv1) is around 1.5 MB.

The printer doesn't use regular usb EP stall feature to tell the host 
that it shouldn't send any more data. Instead, it uses bi-directional 
protocol where the host polls the printer status every time during the 
printing process, and checks whether printer says it can accept the data.

So it's constant:
1. Hey printer, tell me your BasicStatus
2. Here it is, 6 bytes of data
3. Hey printer, tell me your ExtendedStatus
4. Here it is, first BasicStatus again, then ExtendedStatus 16 bytes in 
the next USB transfer
5. So you're ready to accept the data? Here you are, your <=6144 raster.
6. Hey printer, tell me your BasicStatus...

You can imagine how inefficient is that for USB 1.1.

And a single USB transfer raster data is limited to 6144 bytes in the 
"driver" (CUPS filter) for some reason. This doesn't seem to be a 
printer hardware limitation: I've patched this limit to 16128 and it 
seems to work as a workaround for this issue (more data in a single USB 
transfer).

This is an official proprietary x86 Canon driver. I'm running it on ARM 
via both qemu and box86 (and the interpretation performance is not an 
issue here, I checked that. It works fine on much lower-end SBC which 
has MUSB stack with EHCI only).


> The timing information in the usbmon traces will contain helpful clues
> about what's going on, especially if the OHCI trace is compared to the
> EHCI trace.  (Incidentally, you shouldn't use usbmon0; you should the
> bus number that the printer is attached to.)

The "success" response on OUT raster data takes about 2-2.5x longer with 
OHCI than via the hub. And I can't say it's too slow either, everything 
seems to be more or less fine regarding the timings, but the printer 
doesn't like it, reporting NOT_READY | OFFLINE in BasicStatus and 
UNDERFLOW in Engine ExtendedStatus.

I'm not very versed in USB though.
I can upload .pcaps if that's useful.


> 
>> Here's a speed comparison using simple Python script with asks the printer
>> status 10000 times.
>>
>> Direct connection, OHCI:
>>
>> # python3 speedtest.py
>> Opening printer at /dev/usb/lp0...
>> Testing 10000/10000...
>> Avg delta: 1.916 ms
>> Min: 1.443 ms
>> Max: 2.891 ms
>>
>> Connection via the USB 2.0 hub, EHCI:
>>
>> # python3 speedtest.py
>> Opening printer at /dev/usb/lp0...
>> Testing 10000/10000...
>> Avg delta: 0.696 ms
>> Min: 0.590 ms
>> Max: 1.072 ms
> 
> Without knowing what these numbers refer to, it's hard to say anything
> useful.  About all I can glean is that EHCI is faster than OHCI, which
> we already know.

The speedtest.py requests BasicStatus and reads the response in a loop.

> 
>> The printer is from year 2002, with USB 1.1 full speed, and was designed to
>> work via USB 1.1 controllers.
>> Any ideas what could be wrong?
> 
> No.  Have you tried using the printer on a computer with a different
> (non-Linux) operating system?

I think I have a PC on LGA775 which may have OHCI support. I'll try the 
speedtest.py under Windows XP or 7.

> 
> Alan Stern