Linux USB
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: ValdikSS <iam@valdikss.org.ru>
Cc: linux-usb@vger.kernel.org
Subject: Re: USB 1.1 Full Speed OHCI slow/high latency
Date: Thu, 14 Aug 2025 08:01:42 +0200	[thread overview]
Message-ID: <2025081405-lily-useable-75c1@gregkh> (raw)
In-Reply-To: <3fe845b9-1328-4b40-8b02-61a879bea6df@valdikss.org.ru>

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).
> However if I connect it over USB 2.0 Hub (EHCI, hub does internal Full Speed
> conversion) the printer works fine.
> Same applies to USB 3.0 XHCI ports, via which the printer also works fine.
> 
> The issue is seen on Orange Pi Zero3 (Allwinner H618) and Radxa Rock S
> (Rockchip 3308) boards, with different USB controllers.
> 
> There's no USB-level errors (captured with tcpdump -i usbmon0), all URBs are
> success, but they are much slower in OHCI than with EHCI Full Speed via hub.
> 
> 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
> 
> 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?

Yes, the USB controllers on these devices just can't handle it, odds are
they were never really designed for this type of workload.

Stick with the hub solution, scheduling low speed transactions is a pain
for many host controllers and it seems that it's better done by the USB
3 controller than the older ones.

If you really want to dig into this, perhaps the output of usbmon when
the device is failing might provide some information as to what is going
on.

thanks,

greg k-h

  reply	other threads:[~2025-08-14  6:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-14  1:56 USB 1.1 Full Speed OHCI slow/high latency ValdikSS
2025-08-14  6:01 ` Greg KH [this message]
2025-08-14 14:24 ` Alan Stern
2025-08-14 15:11   ` ValdikSS
2025-08-14 16:40     ` Alan Stern
2025-08-15  8:39       ` ValdikSS
2025-08-15 14:52         ` Alan Stern
2025-08-15 15:53           ` ValdikSS
2025-08-15 17:07             ` Alan Stern
2025-08-15 18:13               ` ValdikSS
2025-08-16  2:04                 ` Alan Stern
2025-09-21 23:11                   ` ValdikSS
2025-09-22 14:16                     ` Alan Stern
2025-09-22 14:38                       ` ValdikSS
2025-09-22 14:43                         ` Alan Stern
2025-09-22 14:48                           ` [PATCH] usb: ohci: delay endpoint descriptor unlinking to reduce transfer latency ValdikSS
2025-10-01 19:27                             ` Alan Stern
2025-10-01 22:34                               ` [PATCH v2] " ValdikSS
2025-10-02 17:05                                 ` Alan Stern
2025-10-22 13:39                               ` [PATCH v2 RESEND] " ValdikSS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2025081405-lily-useable-75c1@gregkh \
    --to=greg@kroah.com \
    --cc=iam@valdikss.org.ru \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox