[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Dickens
Subject: [Discuss-gnuradio] Various MacOS USR-related Issues (replies to multiple threads)
Date: 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/
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]