On Thu, Aug 14, 2025 at 06:11:59PM +0300, ValdikSS wrote: > 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. Yes, but I can't imagine why delays would cause a NOTREADY, OFFLINE, or UNDERFLOW error. > 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. 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... Alan Stern
