Bug 26002

Summary:	Poor read/write performance on uhci USB controllers
Product:	Base System	Reporter:	seagull <seagull>
Component:	misc	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	4.2-RELEASE
Hardware:	Any
OS:	Any

Description seagull 2001-03-22 16:30:01 UTC

I have sent this to the bsd-usb mailing list, as well.

I am using an x86-based FreeBSD system, 4.2-RELEASE, to develop a user-
level interface to a USB device, using /dev/ugen.  I have two systems,
both running 4.2-RELEASE: one (IBM 600E laptop) has a UHCI USB controller.
The desktop (home-brewed) has both an on-board UHCI controller, and a
PCI USB card w/ an OHCI controller.

When transferring data on the USB bulk data pipe, using the ugen device,
I get abysmal data trasnfer rates if I am going through a UHCI USB
device.  On the laptop, and the desktop system via the on-baord (UHCI)
USB port, I am transferring 999,424 bytes in roughly 17 seconds.  This is a
data transfer rate of about 59 kb/s, far less than the 1216 kb/s
tehoretical maximum for USB.

However, when I plug my USB device into the OHCI-controlled USB port,
the same file transfer completes in under 4 seconds.  That's more than
250kb/s (and may even be faster...I don't have accurate timing on this
4 second figure...but it's close).

I am suspecting a problem with the UHCI driver at this point.  In talking
to someone who is more USB-knowledgeable than I, it was suggested that
the UHCI driver might not be packing multiple 64-byte transfers (the
external device uses a 64-byte packet) into each frame.  A look at CATC
dumps of the same file transfer under the Windows-based driver software,
using a UHCI controller, shows that Windows is getting roughly 7 to 8
packets into a frame, and right around a 3 second file transfer.

The mathematics predict that, if FreeBSD is only sending one 64-byte packet
per frame, you'd see a data transfer that completed in 15.6 seconds 
(1 frame / ms, with 64 bytes / frame).  This number is too close to the
actual transfer rates I am seeing, so I have a hard time believing its
a coincidence.

Obviously, this is most noticeable on the bulk data pipe, when large
data transfers are involved.

I suspect that the OHCI driver doesn't have to worry about packing multiple
transfers in a frame, since the hardware probably does that for you.  But
since UHCI controllers have very simple hardware, and rely on the software
layer for the intelligence, my guess is that UHCI is defaulting to one
packet per frame because it's not being told otherwise.

Fix: 

Unknown.  Fix uhci driver to put multiple transfers in a frame?
How-To-Repeat: 
Do a large data transfer on a UHCI bus, and do the same transfer on an OHCI
bus.  Measure with a clock.

Comment 1 Nick Hibma freebsd_committer

2001-04-09 19:12:48 UTC

Responsible Changed
From-To: freebsd-bugs->n_hibma

This is a known problem and should be solvable.

Comment 2 johnm 2001-04-11 20:31:54 UTC

Just in case this helps...

I was finally able to locate a CATC USB protocol analyzer, and made
a trace of a file transfer under FreeBSD 4.3-RC2, on an IBM Thinkpad
600E with a UHCI controller.  I also have a trace made by another
individual of a file transfer, from the same USB device, done under
Windows.  I have posted the output from the CATC analysis software
on the Web at:

   http://www.aracnet.com/~seagull/BSD/

What this output shows is that the BSD USB stack is requesting multiple
data reads in a frame, but when it receives a NAK in response to a read
request, it idles out to the end of the frame, and doesn't retry a
transmission until the next frame.  Essentially, this means that the
BSD stack is demanding that data be available from the device every time
it is requested in the frame.  If that data is not available, then it
"gives
up" on the current frame, and waits for the next frame to start again,
even though the external device may be capable of sending data later in
that
frame.

If you look at the trace, it shows an SOF at packet 0, an IN token at 1,
DATA receivedd at 2 with an ACK at 3.  In packet 4, BSD requests more
data,
and the device responds in 5 with a NAK.  At this point, BSD is idle
until
the end of frame, and doesn't generate packet 6 (SOF) until that frame
starts.

Looking at the trace made under Windows, we see very different behavior
from the Win32 USB stack.  If a NAK is received, Windows tries again
after a brief delay. The IN-NAK-IN-NAK sequence repeats throughout the
frame, and it gets as many data packets as the device is capable of
sending
(roughly 8 or 9 packets) in that frame.  This more aggressive behavior
is
the correct behavior: the USB controller should be attempting to pull in
as much data as it can in a frame, up to the allowed bandwidth on the 
bus.

Under FreeBSD, then, bulk data reads using ugen and uhci are limited to
1 packet/frame.  Given 1 frame every ms, and a 64-byte packet, this
limits the bulk transfer to 64,000 bytes/second, which is very, very
low.

I hope this helps those who are working on the stack.  I am willing to
obtain further traces if needed (though I can't guarantee quick
turnaround times, since the CATC analyzers aren't mine to play with,
and are at my disposal only due to the kindness of others).

Cheers,
-+JLS

Comment 3 Mark Linimon freebsd_committer

2004-08-27 23:26:59 UTC

State Changed
From-To: open->feedback

Is this still a problem with modern versions of FreeBSD?

Comment 4 Mark Linimon freebsd_committer

2004-08-27 23:26:59 UTC

Responsible Changed
From-To: n_hibma->freebsd-bugs

With permission of assignee, reset assignment.

Comment 5 Mark Linimon freebsd_committer

2004-08-28 01:02:29 UTC

State Changed
From-To: feedback->closed

Fixed in 5.x.

Comment 6 commit-hook freebsd_committer

2021-11-26 07:08:52 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=927ad383075a183f711afb4b00d6c9539015ea41

commit 927ad383075a183f711afb4b00d6c9539015ea41
Author:     Barbara Guida <bar@FreeBSD.org>
AuthorDate: 2021-11-26 06:59:49 +0000
Commit:     Barbara Guida <bar@FreeBSD.org>
CommitDate: 2021-11-26 06:59:49 +0000

    net-p2p/amule: fix pkg-plist for AMULEGUI as well.

    While here, update WX from 2.8 to 3.0 because amulegui seems to not always work correctly with 2.8.

    PR:     26002
    Reported by:    echoxxzz@gmail.com

 net-p2p/amule/Makefile  | 10 ++++++++--
 net-p2p/amule/pkg-plist | 14 +++++++-------
 2 files changed, 15 insertions(+), 9 deletions(-)

Comment 7 commit-hook freebsd_committer

2021-12-01 08:07:40 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=27392cf64d50cd1898f83624a588bc5c1b5f27d0

commit 27392cf64d50cd1898f83624a588bc5c1b5f27d0
Author:     Barbara Guida <bar@FreeBSD.org>
AuthorDate: 2021-12-01 08:04:39 +0000
Commit:     Barbara Guida <bar@FreeBSD.org>
CommitDate: 2021-12-01 08:04:39 +0000

    net-p2p/amule: correct the inverted logic for DEBUG option.

    PR:     26002
    Reported by:    echoxxzz@gmail.com

 net-p2p/amule/Makefile | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)