Date: Thu, 22 Mar 2001 08:26:29 -0800 (PST) From: <seagull@aracnet.com> To: FreeBSD-gnats-submit@freebsd.org Subject: misc/26002: USB uhci driver - performance issue? Message-ID: <200103221626.IAA06936@shell1.aracnet.com>
next in thread | raw e-mail | index | archive | help
>Number: 26002 >Category: misc >Synopsis: Poor read/write performance on uhci USB controllers >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 22 08:30:01 PST 2001 >Closed-Date: >Last-Modified: >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: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103221626.IAA06936>