Re: [Discuss-gnuradio] FreeBSD - more

[Eric Blossom]

On Wed, Oct 12, 2005 at 11:55:41AM -0500, LRK wrote:
> 
> I'm still in way over my head here but some progress:
> 
> 
> usrp_wfm_rcv(_nogui).py runs with either the  Basic Rx or TV Rx board.
> 
> Since most of the FM stations are 4 to 6 miles away, it is easy to get
> strong signals.
> 
> I get uO errors which I think means the USRP is reporting errors sending
> bytes in thru the USB path. I get more when running Gnome or xdm than
> with the nogui version.
> 
> Disabling the ethernet interface seems to have some small effect on the
> overruns while running the wfm code and listening to FM but they still do
> hit occasionally and can be heard in the audio.
> 
> I am running the "GENERIC" kernel at the moment so there are probably a
> few other things turned on that need not be.

You might try telling the kernel to use some kind of high-priority /
real-time scheduling for our code.  nice --20 <program> would be
a start.  Do you have a sched_setscheduler system call?  Also check
for setpriority.  [We run as multiple threads, so you'll need to "fix"
them all.  Setting the priority for the toplevel python process will
probably work, assuming that later threads inherit their scheduling
attributes from the parent]

Generally speaking, you're hosed if you're using the "generic" fast
usb implementation ;-)

> The data sheet for my I82801DB chip says it should do 480MB/s using USB 2.0
> but that probably really is 60 MBytes/s meaning it should do better than 
> the obvious 4MB/s limit I see.

That's a great host controller.  Same as in the laptop that I used for
the original development.  The USRP sustains 32MB/sec through it under
GNU/Linux.

> Some of the scripts in the usrp/host/apps use #!/bin/bash and others use
> #!/usr/local/bin/bash instead of #!/usr/bin/env bash  as done elsewhere.

Thanks.  I've changed all refs to /bin/bash to /bin/sh.

> Progress but as always clues are welcome.

Do NetBSD and FreeBSD use the same USB implementation?

Getting good, reliable throughput requires finding a way to ensure
that the EHCI host controller endpoint queue is never empty.  The USRP
has very little buffer space internally (about 300us at 32MB/sec).
Thus, you need to keep a steady stream of data flowing to/from it.  In
practice this requires ensuring that there are always pending USB read
and write requests.  The standard libusb usb_bulk_{read,write}
implementions all appear to make a single request, then block waiting
for it to complete.  This is not good!

Under GNU/Linux, we work around this by submitting multiple
asynchronous USB requests from user-space using the usbfs driver.
Under OS/X, a user space solution is also possible using IOKit.  Not
sure about NetBSD/FreeBSD.  It may require writing a kernel driver to
handle the USRP.  Poking around in the existing libusb implementation
and the corresponding driver code is probably a good place to start
investigating. 

The high level part of the solution is to implement a fusb_*bsd class
that "does the right thing" somehow under Net/Free BSD.  It would be
great if NetBSD and FreeBSD used the same USB implementation, then we
could get by with a single solution for both.

Calling all BSD hackers...

Eric