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.
Responsible Changed From-To: freebsd-bugs->n_hibma This is a known problem and should be solvable.
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 Is this still a problem with modern versions of FreeBSD?
Responsible Changed From-To: n_hibma->freebsd-bugs With permission of assignee, reset assignment.
State Changed From-To: feedback->closed Fixed in 5.x.
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(-)
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(-)