Re: [Discuss-gnuradio] FreeBSD - more

[LRK]

On Wed, Oct 12, 2005 at 07:26:56PM -0700, Eric Blossom wrote:
> > 
> > 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.
> 
> 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]

I can run the FM receiver as root and set the "nice -20" but it does not
eliminate the overruns completely. Running as a user, I can't set negative
values for nice.

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

If you mean the fusb_generic.cc code, indeed it is being used. I've
always been told unix will not run real-time but I don't give up easily.
I did a lot of fancy stuff back when computers were small but there is
a lot more to dig thru now to just figure out which parts do what.

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

The non-gui FM receiver code uses about 30% of the computer time so there
is no obvious explanation for the 4 MB apparent limit. I probably just
don't quite understand the tests, how they work, or what I should try.

 
> > Progress but as always clues are welcome.
> 
> Do NetBSD and FreeBSD use the same USB implementation?

At least very similar. Berndt sent me a patch for the ugen.c code and it
looks similar at that point although the line numbers don't match. The
patch also did not seem to affect my problems.

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

Since I'm only receiving, there shouldn't be much in the way of writes.
Reads, of course, should be double-buffered somehow but I haven't been
into the DMA stuff in i386 hardware enough to know how it is done (or
maybe not done).

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

I can munch the libusb and usrp code fairly easily but haven't figured 
out the best way to munch the ugen code yet.
 

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

The code likely would be easy to adapt to both. I suspect the "right"
way would be a USRP specific driver but that may take me a while to work
out.


> Calling all BSD hackers...

Does seem to be a shortage of those here. :)


-- 
LRK
address@hidden