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
