From seagull@aracnet.com  Thu Mar 22 08:26:30 2001
Return-Path: <seagull@aracnet.com>
Received: from mail3.aracnet.com (mail3.aracnet.com [216.99.193.38])
	by hub.freebsd.org (Postfix) with ESMTP id 5D1FF37B71A
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 22 Mar 2001 08:26:30 -0800 (PST)
	(envelope-from seagull@aracnet.com)
Received: from shell1.aracnet.com (shell1.aracnet.com [216.99.193.21])
	by mail3.aracnet.com (8.11.0/8.11.0) with ESMTP id f2MGQTg26483
	for <FreeBSD-gnats-submit@freebsd.org.>; Thu, 22 Mar 2001 08:26:29 -0800
Received: by shell1.aracnet.com (8.9.3)  id IAA06936; Thu, 22 Mar 2001 08:26:29 -0800
Message-Id: <200103221626.IAA06936@shell1.aracnet.com>
Date: Thu, 22 Mar 2001 08:26:29 -0800 (PST)
From: <seagull@aracnet.com>
To: FreeBSD-gnats-submit@freebsd.org
Subject: USB uhci driver - performance issue?

>Number:         26002
>Category:       misc
>Synopsis:       Poor read/write performance on uhci USB controllers
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 22 08:30:01 PST 2001
>Closed-Date:    Sat Aug 28 00:02:45 GMT 2004
>Last-Modified:  Sat Aug 28 00:02:45 GMT 2004
>Originator:     John Mechalas
>Release:        FreeBSD 4.2-RELEASE i386
>Organization:
n/a
>Environment:

>Description:

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.

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

>Fix:

Unknown.  Fix uhci driver to put multiple transfers in a frame?

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->n_hibma 
Responsible-Changed-By: n_hibma 
Responsible-Changed-When: Mon Apr 9 11:12:48 PDT 2001 
Responsible-Changed-Why:  
This is a known problem and should be solvable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26002 

From: John P Mechalas <johnm@ichips.intel.com>
To: freebsd-gnats-submit@FreeBSD.org, seagull@aracnet.com
Cc:  
Subject: Re: misc/26002: Poor read/write performance on uhci USB controllers
Date: Wed, 11 Apr 2001 12:31:54 -0700

 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
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Fri Aug 27 22:26:59 GMT 2004 
State-Changed-Why:  
Is this still a problem with modern versions of FreeBSD? 


Responsible-Changed-From-To: n_hibma->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Aug 27 22:26:59 GMT 2004 
Responsible-Changed-Why:  
With permission of assignee, reset assignment. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26002 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Sat Aug 28 00:02:29 GMT 2004 
State-Changed-Why:  
Fixed in 5.x. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26002 
>Unformatted:
