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
[EMAIL PROTECTED]
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
