Linux USB
 help / color / mirror / Atom feed
From: ValdikSS <iam@valdikss.org.ru>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Subject: Re: USB 1.1 Full Speed OHCI slow/high latency
Date: Fri, 15 Aug 2025 11:39:03 +0300	[thread overview]
Message-ID: <2bf5c54e-7dac-4673-a696-e09eb8d459d5@valdikss.org.ru> (raw)
In-Reply-To: <d41d8488-9438-430a-88ab-f845df3655e1@rowland.harvard.edu>

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On 14.08.2025 7:40 PM, Alan Stern wrote:
> Yes, but I can't imagine why delays would cause a NOTREADY, OFFLINE, or
> UNDERFLOW error.

The laser printers roll the paper with the constant speed, they don't 
slow down when they have insufficient data.

If the host doesn't send the image data in time (and here it happens 
during the print of a single page just as it rolls, as it is too large 
to fit into the printer's RAM), the job is marked as failed due to 
underflow of print data.

It's similar to CnC device in that sense. Modern printers wait for the 
full page, but this printer is from the era when RAM was expensive and 
could not (reliably) fit the whole page.


> 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.

[-- Attachment #2: usb11-usb20-capture.zip --]
[-- Type: application/zip, Size: 3440 bytes --]

  reply	other threads:[~2025-08-15  8:39 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
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 [this message]
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=2bf5c54e-7dac-4673-a696-e09eb8d459d5@valdikss.org.ru \
    --to=iam@valdikss.org.ru \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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