I was just assuming that NetBSD had support for high speed mode with good data 
throughput on a generic USB2 interface. 

Considering my knowledge on USB devices I don't believe to have the capability 
of writing a kernel driver from scratch without some guidance. I will have a 
go at it if someone is willing to show me the way!

I'm currently using the ugen device to communicate with the Universal Software 
Radio Peripheral (USRP) of the GnuRadio project. More info and data sheets 
can be found on the following URL:

http://comsec.com/wiki?UniversalSoftwareRadioPeripheral

I've ported GnuRadio and created several packages and hoped to improve on the 
data throughput before submitting it to wip or pkgsrc.

cheerio Berndt

On Mon, 14 Feb 2005 11:35 am, Lennart Augustsson wrote:
> The ugen driver isn't really made for good throughput.
> Maybe you want to rool your own driver.
>
>  -- Lennart
>
> Berndt Josef Wulf wrote:
> > On Mon, 14 Feb 2005 02:19 am, Jon Buller wrote:
> >>On 00 Jan 00 00:00:00,
> >>
> >>Berndt Josef Wulf wrote:
> >>>G'day,
> >>>
> >>>Where can I find benchtests performed for USB2 compliant controllers on
> >>>NetBSD-i386 that would give some indication on the expected maximum data
> >>>bandwidth? Currently, I'm only managing a maximum of 4MBytes/sec with a
> >>>Intel 82801DB USB EHCI Controller (rev. 0x01) connected to a Cypress
> >>>7C63013 device (FX2), which is a long way off from its theoratical
> >>>480Mbits/sec of a fullspeed USB2 interface.
> >>
> >>You meant high-speed USB interface, didn't you?  Full-speed is
> >>10Mbits/sec (or is it 12?)  High-speed is the fast one.  I (and
> >>everyone else I know) thinks the USB people were on crack when they
> >>thought up those names.  If you really are configuring it at full speed,
> >>there is some chance for improvement there (2x or 3x), but not 100x.
> >
> > The measured data bandwidth is 4MBytes/sec. This is only 10% of the
> > maximum bandwidth theoretically achievable. Linux developers report data
> > bandwidth of 32-40MBytes/sec under the same conditions.
> >
> > Is there generic support for asynchronous reading and writing?  That
> > is, multiple reads and writes outstanding, which notifies
> > their completion? (Signals, polling, etc).
> >
> > Is there a USB specific ioctl that allows submission of an USB "URB"
> > (USB Request Block) asynchronously?
> >
> > Is there a way of improving data throughput on this device or is this the
> > best we currently can do? Find below some kernel and userland messages on
> > system configuration and performance.
> >
> > ./program_and_start.sh
> > Using device /dev/ugen0 on bus /dev/usb3 vendor id 0xfffe product id
> > 0x0002 Read 102400000 bytes in 25 seconds and 1068 microseconds. Rate of
> > 4095825 bytes/second
> >
> >  ehci0 at pci0 dev 29 function 7: Intel 82801DB USB EHCI Controller (rev.
> > 0x01)
> >  ehci0: interrupting at irq 11
> >  ehci0: EHCI version 1.0
> >  ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2
> >  usb3 at ehci0: USB revision 2.0
> >  uhub3 at usb3
> >  uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> >  uhub3: single transaction translator
> >  uhub3: 6 ports with 6 removable, self powered
> >
> > usbdevs -v
> > [,,,]
> > Controller /dev/usb3:
> > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000),
> > Intel(0x8086), rev 1.00
> >  port 1 addr 2: high speed, self powered, config 1, USRP Rev 2(0x0002),
> > Free Software Folks(0xfffe), rev 1.02
> >  port 2 powered
> >  port 3 powered
> >  port 4 powered
> >  port 5 powered
> >  port 6 powered

-- 
Every man who says frankly and fully what he thinks is doing a public service.
[Leslie Stephen]