[Discuss-gnuradio] Various MacOS USR-related Issues (replies to multiple threads)

[Michael Dickens]

On Jan 14, 2006, at 7:34 PM, Eric Blossom wrote:
> On Mon, Jan 09, 2006 at 09:38:29PM -0500, Michael Dickens wrote:
> > Q: As USRP does not yet use the omnithread package (though it's
> > included in the config directory and just commented out of
> > configure.ac), and that package is part of the gnuradio-core library
> > which in theory the USRP should not depend upon, could we make
> > omnithread a separate library?  Or should I just go ahead and change
> > things to link using "-lgnuradio-core" (and thus "-I/usr/local/
> > include/gnuradio" too?
>
> No, we should not make usrp depend on gnuradio-core.
> The right answer is probably a separate package, but that doesn't help
> our already somewhat-out-of-control dependency chain.

I didn't think USRP should depend on GR-core either, but that's where  
the omni_threads are for now.  Until their location is sorted out, I  
will just include instructions for OSX users on how to compile my  
FUSB codes.  Hence at this time, I will concentrate on other changes  
(see below).

Moving to a MacOS X KEXT would take care of this issue, since I  
wouldn't need a CFRunLoop in a separate thread to get the job done; I  
would require no extra threads (OSX internals would do that for me).

On Jan 14, 2006, at 6:10 PM, Eric Blossom wrote:
> Hi Michael, sorry for the delay getting back to you.  Between an ISP
> outage and a cold, I'm a bit behind.

We heard about the ISP issue; hope it's behind you & you're feeling  
better to boot!

> The cheapo PCI USB card could be killing your throughput.  Which
> chipset does it use?  Regarding the dual G5, what's the best
> throughput *anyone* has achieved by any means?

My PCI card is "Iogear GIC251U"; no idea what the chipset is and  
Google doesn't provide an immediate answer.

I have no idea what the best throughput *anyone* has achieved on the  
native USB 2.0 chipset on the G5.

Scanning various Google hits, consistent themes are (1) built-in USB  
throughput on MacOS X isn't as good as under Windows; (2) drop-in USB  
2.0 PCI cards achieve roughly 50% better throughput than build-in.   
These seem to hold true with the 2 data points thus far; I am working  
on expanding out the "beta test" network to get a few more samples,  
but I doubt they'll be substantially different.

> This measurement is pretty easy to make on the USRP with a logic
> analyzer.  The signals of interest are the GPIF control signals RD and
> WR between the FX2 and FPGA.  These are asserted when a packet is
> burst between the FX2 and the FPGA.

I do most of my work from home, so I can't make these measurements  
easily.  When I'm physically in the lab next with some of my grad- 
student colleagues, I'll look into hooking up the logic analyzer per  
your thoughts.

> > IMHO what needs to happen is to route -all- USB calls through
> > FUSB, so that there is 1 place to deal with "everything USB".
>
> This refactoring would be OK by me.
> Please go ahead and do it and mail patch(es) to
> address@hidden with the changes.

I will work on this in the next few weeks, since I believe it's a  
good way to go for both the  GR project as well as for my programming  
in particular.

Once these changes are made, then I'll rewrite my current FUSB code  
to be "clean" with respect to LIBUSB (meaning, it won't use LIBUSB at  
all).

Once that's done, then I'll start investigating the Darwin "ports"  
and/or a KEXT. - MLD