[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Various MacOS USR-related Issues (replies to multiple
[Discuss-gnuradio] Various MacOS USR-related Issues (replies to multiple threads)
Sun, 15 Jan 2006 17:37:36 -0500
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/
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
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
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
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
Once that's done, then I'll start investigating the Darwin "ports"
and/or a KEXT. - MLD
|[Prev in Thread]
||[Next in Thread]|
- [Discuss-gnuradio] Various MacOS USR-related Issues (replies to multiple threads),
Michael Dickens <=