Re: GR standard UHD options parser module (was UHD default subdevice.)

On Thu, Dec 29, 2011 at 6:41 PM, Marcus D. Leech [email protected]
wrote:

for there setup, or they could just edit the default config file. Much

load the standard Gnu Radio options module, the Standard UHD options

I absolutely agree on this. We should definitely have a standard uhd
options parser that we can pull in to any program using a uhd device.
Excellent suggestion.

If we have/had one for GNU Radio before, I never used it or knew about
it.
Having recently just fixed most of the examples, I never ran across it,
either. We do have a preferred style and suggested options in our style
guide on the Wiki, though.

For this, we probably don’t have enough general use options to have a
default GR options parser module, though. We should definitely make a
UHD
one though.

Also, Python 2.7 has deprecated optparser in favor of argsparser (
http://docs.python.org/library/optparse.html). We should start trying to
make our programs compliant with this while still supporting Python 2.5.
It
seems awkward to have a check in every Python script if it’s 2.7 or
earlier, though, but we could easily do it in the UHD options module.

Tom

On 29/12/11 06:48 PM, Tom R. wrote:

For this, we probably don’t have enough general use options to have a
default GR options parser module, though. We should definitely make a
UHD one though.
That was my suspicion–that there just aren’t really any “general” Gnu
Radio options, except perhaps for scheduler
tweaks (TPB vs not-TPB is the only one I can think of).

Also, Python 2.7 has deprecated optparser in favor of argsparser
(http://docs.python.org/library/optparse.html). We should start trying
to make our programs compliant with this while still supporting Python
2.5. It seems awkward to have a check in every Python script if it’s
2.7 or earlier, though, but we could easily do it in the UHD options
module.

Oh, those silly Pythonians. Haven’t they ever read all those diatribes
about “better is the enemy of ‘good enough’”?

On Thu, Dec 29, 2011 at 07:01:19PM -0500, Marcus D. Leech wrote:

in our style guide on the Wiki, though.

For this, we probably don’t have enough general use options to have a
default GR options parser module, though. We should definitely make a
UHD one though.
That was my suspicion–that there just aren’t really any “general” Gnu
Radio options, except perhaps for scheduler
tweaks (TPB vs not-TPB is the only one I can think of).

I keep thinking this may be a reason for the lower interest in GnuRadio.
If someone writes a program to run on a USRP2 and daughterboard and I
want
to run it on my USRP1, the UHD part should take care of the differences
if the frequencies and such are compatible. The computer should be able
to tell what hardware is connected and use the appropriate parts or
default to the most likely.

I finally got programs to work with UHD and my USRP1 but only after much
searching and adding command-line info. I know I’m old school, but the
computer is supposed to work for the user as best it can rather than the
user having to work for the computer. This, of course, is about the
programming but I spend far too much time trying to get older programs
to work because of some update that breaks everything.

If I find some neat new block in GRC I spend way too much time trying to
figure out what parameters to enter rather than tweaking default params.
Of course the error messages are seldom useful either. The uhd_fft.py
finally worked on my 3 GHz 4-core machine after I figured out the
options
but just hung when I clicked on anything. Seem to be the frame rate
problem
which should have been fixed long ago.

It is hardly worth updating the hardware if the same problems will be
encountered. I’m afraid to update Ubuntu or GnuRadio at the moment since
my experiments will likely be stopped again. I have some programs I run
under FreeBSD, since that is my preferred OS, but I can’t update any of
them because GnuRadio won’t compile there at all since 3.2.2. Most of
the
problems are probably like the header files in the TCP sink code when
something was probably “updated” from an old version.

I use GnuRadio a lot to just get bits to feed to C programs where they
get processed because doing that in GnuRadio is much harder. Good thing
I’m not doing this for a living.


LRK
gr-user . ovillatx.sytes.net

Very true, all of it, GNUradio is quite the hodgepodge of different
APIs,
Languages, and Ideas.
And that’s not always a bad thing, it can allow great flexibility, but
sadly it is currently doing the opposite. With required versions of
SWIG,
Python 2.x/3.x and other helper programs it ONLY compiles reliably on
ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu as the small
differences in GTK versions break most of wxgui. I am also a die-hard
FreeBSD user forced into Ubuntu as no other operating system can compile
GNUradio since 3.2. OK sorry for the rant.

What we are here to fix in this thread is the program to hardware
incompatibility, as stated earlier many programs are created for one
device
configuration. UHD solves this though a unified interface to hardware
with
many settable parameters for anyone’s hardware. The problem comes about
when programers, not considering outside use of there work, do not
extend
control to the user and hard-code the parameters into there code. The
way I
believe it should be done is the programmer simple asks UHD for the
default
device, and UHD looks to a config file and finds what device,
sub-device,
and antenna to use. The programmer could of course overwrite this and
tell
UHD specifically what it wants for special cases. Now the lazy
programmer
just trying to get it working will not have to write out a long program
header reading command line arguments and setting up the device in code
but
simply ask for a device and he can set what device it will return in the
config file. This will motivate programmers to write more compatible
code
as it will be the easier route to simply ask for and setup a default
device.

For the Python world we do need a more standardized option parser set,
so
that every program will not need that long command reading header but a
simple call to a command parser.

Also I noticed a patch was submitted that fixed a problem with the new
uhd_rx_cfile.py, before it was setting the gain before it picked out the
sub-device, with the USRP1 being the only device with two sides this bug
will only effect USRP1 users. This is the kind of thing that can be
fixed
by giving UHD a set of parameters and then letting it turn them on in
order
( GAIN 45, WBX, 192.168.1.44, TX/RX, SIDE B, 250ks/s ).

in our style guide on the Wiki, though.
if the frequencies and such are compatible. The computer should be able
to tell what hardware is connected and use the appropriate parts or
default to the most likely.
The problem is that it’s very often the case that the “computer” can’t
really intuit
what your intent was when you’re dealing with new hardware. Sample
rates,
for example, aren’t always compatible between different USRP families
(oh, sure,
there are spot places where there are overlaps, but not in general).

So, you have a flow-graph that “knows” that the sample rate is
3.2Msps–what should
UHD do when you plug it into a USRP2-family device that doesn’t
support that
sample rate?

For the most part, I find that UHD flow-graphs (and I’ve written a lot
of them)
are compatible between hardware families, provided I pay attention
to
those cases where there are irreconcilable differences betweeen
hardware families.

And your comment about “low interest in Gnu Radio” is quite
perpendicular to most
peoples experience here. Look at CGRAN–there’s a lot of
applications that have been
written with Gnu Radio, and that’s the tip of the iceberg. There are
a lot of private
projects out there using Gnu Radio and UHD.

I finally got programs to work with UHD and my USRP1 but only after much
searching and adding command-line info. I know I’m old school, but the
computer is supposed to work for the user as best it can rather than the
user having to work for the computer. This, of course, is about the
programming but I spend far too much time trying to get older programs
to work because of some update that breaks everything.
The key message here is “as best it can”. In fact, UHD does pick
reasonable
defaults wherever it can. For example if you don’t specify a device
string with
UHD, it’ll look around trying to find something it can attach to.
But if there are
multiple devices, which one should it pick? I’m also old-school,
having been a
software developer and system architect for over thirty years. But
I’ve never
bought into the poorly-though-out notion that “the computer should
just know”.
Because in many (but, admittedly, not all) cases, it can’t pick a
reasonable default.
It’s neither psychic, nor artificially intelligent.

If I find some neat new block in GRC I spend way too much time trying to
figure out what parameters to enter rather than tweaking default params.
Of course the error messages are seldom useful either. The uhd_fft.py
finally worked on my 3 GHz 4-core machine after I figured out the options
but just hung when I clicked on anything. Seem to be the frame rate problem
which should have been fixed long ago.
It’s really hard for the software to know and predict how crappy the
frame-by-frame
performance will be on your particular platform, so again, how
should it pick
a default frame rate? Should the strategy be:

 o pick one that will please whoever is sitting in front of the

screen. Not too slow, because that
will just piss them off. Not too fast, because that will swamp
the OpenGL rendering engine
(maybe, depending on exact graphics hardware being used, OpenGL
version, memory bandwidth
CPU speed and type, etc, etc).

 o Pick one that is based on some hard-to-define heuristic based on

hardware configuration and
flow-graph parameters

 o Pick some reasonable middle-ground, like the current (AFAIR) 15

FPS, and let the user cope with
whatever computational consequences there are

The error messages from GRC come from within Python, for the most part.
So it is true that you need to
understand Python error messages in order to fix problems that arise
when you make mistakes in setting
parameters. It is also true that GRC isn’t that well documented, and
very little tutorial material exists for
it. The community is always invited to fix that class of problem,
and contribute the results. Gnu Radio isn’t
a commercial development. It’s a small handful of core people who do
this part-time.

You see, in modern software systems, the software sits on the shoulders
of dozens and dozens of somtimes-flawed
giants. It’s not really possible to control the flaws in any of
those giants. One might decide not to pick
those giants in the first place, but then the development slows way
down while you try to replicate
the functionality provided by those giants, instead of focussing on
the core features of your actual
“product”. So when you say “the frame rate problem should have been
fixed a long time ago”, you are either
being deliberately inflammatory, or you don’t understand how modern
software gets put together, and
where the boundaries of responsibility lie, for a project driven by
volunteers.

It is hardly worth updating the hardware if the same problems will be
encountered. I’m afraid to update Ubuntu or GnuRadio at the moment since
my experiments will likely be stopped again. I have some programs I run
under FreeBSD, since that is my preferred OS, but I can’t update any of
them because GnuRadio won’t compile there at all since 3.2.2. Most of the
problems are probably like the header files in the TCP sink code when
something was probably “updated” from an old version.
Have you thought (FSM forbid!) of figuring out why newer versions of
Gnu Radio
won’t build under FreeBsd, and then contributing those fixes back
to the
project? Most of the Gnu Radio developers are Linux people, and
while we strive
for portability, the fact is that most of the testing and development
happens on
Linux. If this were a commercial project, rather than one that was
community
driven, there’d be resources allocated to deal with portability
issues. We rely
on the interested community to provide those resources. If the
community
doesn’t step up, then nothing happens.

I use GnuRadio a lot to just get bits to feed to C programs where they
get processed because doing that in GnuRadio is much harder. Good thing
I’m not doing this for a living.

I do this as well. I’m under no delusion that Gnu Radio can solve all
randomly-selected
computational problems that have to do, tangentially or otherwise,
with radio.
It’s primarily a (still-emerging) DSP framework, with a little bit of
packetizing and relating “goo” thrown in.
There are certainly many classes of problems for which the DSP-based
focus
isn’t a particularly good fit. But, well, so what? The Unix “Shell”
isn’t a particularly good
fit for doing real-time high-speed data processing, but within its
problem domain, it’s
pretty darned good.

Gnu Radio is a flow-based DSP framework. So it isn’t very good at
algorithmic work, at least not at the
top-level–“algorithmic work” tends to get done inside the context of
blocks, so if you have to execute
an “algorithm” on data, it may require a new block to be constructed.
Adding new blocks isn’t, perhaps,
as easy as it could be, but it’s easier than it used to be. Again,
see some of the work on CGRAN. Also,
for non-performance-critical stuff, Josh B.'s Python-blocks work is
about to get folded into the main
codebase, and this allows much easier construction of new blocks,
complete with reasonably-seamless
integration into GRC.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Andrew D. [email protected] writes:

FreeBSD user forced into Ubuntu as no other operating system can compile
GNUradio since 3.2. OK sorry for the rant.

It does build here on debian unstable.

On 12/30/2011 12:16 PM, Andrew D. wrote:

Very true, all of it, GNUradio is quite the hodgepodge of different APIs,
Languages, and Ideas.
And that’s not always a bad thing, it can allow great flexibility, but
sadly it is currently doing the opposite. With required versions of SWIG,
Python 2.x/3.x and other helper programs it ONLY compiles reliably on
ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu as the small
differences in GTK versions break most of wxgui. I am also a die-hard
FreeBSD user forced into Ubuntu as no other operating system can compile
GNUradio since 3.2. OK sorry for the rant.

Not sure what you mean about swig. All the swigs since 1.3.31 seem to be
fine (that includes the recent 2.0.x).

Python 3.0 is just a no-go since the other dependencies dont yet support
it, let alone the gnuradio python code or build system usage of it.
http://gnuradio.org/redmine/issues/470

There is the issue that 2.6 and 2.7 have added features and some
deprecations that we just don’t have in 2.5. Anyway, I have had good
luck with 2.7 on all my systems.

And for the non linux OS crowd: GR builds fine on my msvc+windows7. I
think the OSX guys are doing fine as well.
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork

And please, tell us the errors you get on FreeBSD. They may be simple or
easily fixable. Let us know!

-Josh

It compiles and builds on Fedora 12-16, and Ubuntu 9.04 to 11.10, and
many other Linux variants. But the
build-gnuradio script only deals with Fedora and Ubuntu, because:

o The biggest swath of Linux-using population for Gnu Radio uses

Fedora and Ubuntu–biggest bang for the buck
o The author of that script (me) happens to be a user of Fedora
(primarily) and Ubuntu (secondarily), so
had familiarity with the “build recipes” for those two
distributions.

I’ve always said that I invite patches that give a matching “recipe” (as
embodied in the shell script) for other
Linux distributions. I’m not any kind of Fedora/Ubuntu purist
fanboy. That’s just what I happen to have been
familiar with when I wrote build-gnuradio.

And you don’t have to use build-gnuradio. There are “recipes” for a
number of Linux distributions up on the
website for those who want to go the manual route (and testing and
inevitable tweaking of those recipes
when they’re incorrect or out-of-date). I can’t maintain those
recipes myself–Fedora and Ubuntu are enough
work by themselves.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Very true, all of it, GNUradio is quite the hodgepodge of different
APIs, Languages, and Ideas.
And that’s not always a bad thing, it can allow great flexibility, but
sadly it is currently doing the opposite. With required versions of
SWIG, Python 2.x/3.x and other helper programs it ONLY compiles
reliably on ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu
as the small differences in GTK versions break most of wxgui. I am
also a die-hard FreeBSD user forced into Ubuntu as no other operating
system can compile GNUradio since 3.2. OK sorry for the rant.
See my earlier rant about “shoulders of giants”.

I think that what happens for some people is that Gnu Radio isn’t
written using their programming language/paradigm of choice.
To them it’s “obvious it should have been written in
{C,C++,Ruby,Java,Fortran,Pascal,Erlang,Cobol} and I can’t understand why
these Gnu Radio idiots picked Python/C++”. I admit that back in
2005, when I first started using Gnu Radio, I was resentful of
the choice of Python/C++. Two languages that I was ill-prepared for.
I spend most of my professional life coding in C, with
occasional excursions into C++. Gnu Radio forced me to learn enough
Python to get by. Now, I love it. I find that I’m much more
likely to write a “throw away” program in Python than C these days,
and I’ve been a C programmer since 1979! I taught my son
Python when he was 8. He still loves it at nearly-14, and even
taught Python to his class-mates when he was at a private school.

With the advent of GRC, you don’t even have to know Python or C++ to
accomplish a great deal of stuff. If the “plugging lego together”
paradigm isn’t “natural” or is too restricting, you can always
program in a soup of Python and C++. It’s all doable.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

“Marcus D. Leech” [email protected] writes:

And you don’t have to use build-gnuradio. There are “recipes” for a

Indeed, I didn’t even know about such a script. I built gnuradio just
like every other piece of software.

On Fri, Dec 30, 2011 at 03:35:03PM -0500, Marcus D. Leech wrote:

fanboy. That’s just what I happen to have been
familiar with when I wrote build-gnuradio.

I certainly appreciate the script and the efforts to make it work under
various conditions. I use it under Ubuntu and works well.

And you don’t have to use build-gnuradio. There are “recipes” for a
number of Linux distributions up on the
website for those who want to go the manual route (and testing and
inevitable tweaking of those recipes
when they’re incorrect or out-of-date). I can’t maintain those
recipes myself–Fedora and Ubuntu are enough
work by themselves.

Sure. I don’t use the script under FreeBSD mostly because I use
different
directories, both so I can install as a user (without sudo) and to keep
some projects running while I get the next version debugged.


LRK
gr-user . ovillatx.sytes.net

On Fri, Dec 30, 2011 at 03:45:12PM -0500, Marcus D. Leech wrote:

With the advent of GRC, you don’t even have to know Python or C++ to
accomplish a great deal of stuff. If the “plugging lego together”
paradigm isn’t “natural” or is too restricting, you can always
program in a soup of Python and C++. It’s all doable.

I have made good use of GRC under Ubuntu (it suddenly quit working under
FreeBSD) for some projects. Currently, I’m trying to get a QPSK receiver
running at 1.92 ksps or slower. Send me .grc file for the demodulator
part and tell me how to tweak the variables.


LRK
gr-user . ovillatx.sytes.net

On Fri, Dec 30, 2011 at 03:02:35PM -0500, Marcus D. Leech wrote:

I keep thinking this may be a reason for the lower interest in GnuRadio.
If someone writes a program to run on a USRP2 and daughterboard and I want
to run it on my USRP1, the UHD part should take care of the differences
if the frequencies and such are compatible. The computer should be able
to tell what hardware is connected and use the appropriate parts or
default to the most likely.

UHD do when you plug it into a USRP2-family device that doesn’t
support that
sample rate?

The obvious thing to do is either set the closest possible rate and
provide a warning or decide it is not at all close and error off. If
the user program can read the actual setting, it might well just use
that with a little math to make the program work.

My suggestion is not that these things can be perfect but that the user
should spend her time working on software defined radio development not
repeatedly fixing new bugs. My fisrt build of 3.5(?) on Ububtu resulted
in a situation where starting the program caused the USRP to vanish. If
I just moved it to the FreeBSD machine, it would not work there either.
Powering down, it would reload and work again. I think it was loading
the USRP with the wrong firmware but that went away and I never
identified
the problem.

As I said, I’m old school. We did not have all the memory and speed of
today and making programs bullet-proof was part of the job.


LRK
gr-user . ovillatx.sytes.net

I have made good use of GRC under Ubuntu (it suddenly quit working under
FreeBSD) for some projects. Currently, I’m trying to get a QPSK receiver
running at 1.92 ksps or slower. Send me .grc file for the demodulator
part and tell me how to tweak the variables.

I’m pretty sure someone can help you with the QPSK demodulator on this
list. I’m not the guy.
My DSP expertise is limited (mostly) to that which is required for
applications in scientific radio,
including radio astronomy, ionospheric monitoring, etc. Hardly any
cosmic objects modulate
themselves in QPSK, vanishingly few, in fact :slight_smile:

But the people who developed most of the DSP blocks in Gnu Radio are on
this list, and are happy
to help people use their work. It’s true that better per-block
documentation is still required, but
again, people in a community-oriented project like this work on what
they want to work on. That
may not include really-good documentation. Not all programmers are
also good documenters.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Well it’s not the language choice, it’s all the helper programs that are
version locked that annoy me most. Python is in a weird state of limbo
right now with the version 3 switchover. Many systems are defaulting to
python 3 and we should probably do the same. Python would work great if
I
was just putting together an FM radio by connecting blocks, but for any
more computational advanced program I would want to switch to C++.
GNUradio
is almost catered to Pyhton, this should not be the case, it should be
modular so I can call it from any scripting language or GRC. For just
connecting blocks Python has way too much overhead, a simpler scripting
environment would suffice. Then for more advance programs you almost
have
to switch to C++. Take usrp_spectrum_sence for example, this program has
it’s own block ( bin_statistics ) that has no use other than basically
being the heart of usrp_spectrum_sence, it just shows python isn’t up to
the task of real DSP work beyond just connecting real C++ code. Whats
needed is a common block connecting API that can be run directly from
GRC
without using python as an intermediary. Without the need for
python/swig
we eliminate a great deal of version locking and system incompatibility.

It’s not a problem with not having a script for FreeBSD, it simple
cannot
be made to compile reasonably in its current state for a lot of systems
do
to required versions of programs and such. I think i’m going to go try
to
install it again today and make a list of problems and solutions, my
goal
at some point is to put 3.3.0 or newer in the FreeBSD ports tree.

suffice. Then for more advance programs you almost have to switch to
C++. Take usrp_spectrum_sence for example, this program has it’s own
block ( bin_statistics ) that has no use other than basically being
the heart of usrp_spectrum_sence, it just shows python isn’t up to the
task of real DSP work beyond just connecting real C++ code. Whats
needed is a common block connecting API that can be run directly from
GRC without using python as an intermediary. Without the need for
python/swig we eliminate a great deal of version locking and system
incompatibility.
That horse has already left the barn, I’m afraid.

But you know that you can use C++ even for the “connecting the blocks”
part now? That has been true for quite some time (two years?).
Plus, GRC almost doesn’t know anything about Python. You could
probably tweak it to generate C++ blocks–in fact, a good student
project would be to take the current XML files that describe GRC
blocks, and make them generate C++ code as an “alternate coding
universe”
output for GRC.

Eliminating Python will eliminate the SWIG dependancies. But all the
other dependenices won’t go away. FFTW, Boost, Orc, and a bunch of
other stuff. Plus, many of the underlying C++ blocks are actually
generated using templates and a Python script.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

It’s not a problem with not having a script for FreeBSD, it simple
cannot be made to compile reasonably in its current state for a lot of
systems do to required versions of programs and such. I think i’m
going to go try to install it again today and make a list of problems
and solutions, my goal at some point is to put 3.3.0 or newer in the
FreeBSD ports tree.
It’ start with the GIT tree as of whenever you start the attempt–that
makes it easier to fold the results in, as far as I’m concerned.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

The obvious thing to do is either set the closest possible rate and
provide a warning or decide it is not at all close and error off. If
the user program can read the actual setting, it might well just use
that with a little math to make the program work.
UHD already does that. But the resulting program behaviour may be
wildly
not what you intended.

My suggestion is not that these things can be perfect but that the user
should spend her time working on software defined radio development not
repeatedly fixing new bugs. My fisrt build of 3.5(?) on Ububtu resulted
in a situation where starting the program caused the USRP to vanish. If
I just moved it to the FreeBSD machine, it would not work there either.
Powering down, it would reload and work again. I think it was loading
the USRP with the wrong firmware but that went away and I never identified
the problem.

I’m sorry that you had USRP problems after you upgraded to 3.5. Knowing
that
sooner, rather than later, may have resulted in fixes sooner as well.
For what
it’s worth, I have a flotilla in my personal lab of USRP hardware,
including USRP1
and USRP2. They both worked just fine with 3.5, with the exception
of a minor
glitch involving USRP1 and hardware interpolation that was only in
the master
branch of UHD, and which was fixed before Xmas.

The build-gnuradio script arranges for the UHD firmware to be in “the
right place”, which
is /usr/local/share/uhd/images. The USRP1 firmware/FPGA images
haven’t changed in a
very long time, so as long as they’re in the right place, they’re
compatible. Another issue
is that USB-2.0 is sometimes flaky when there are multiple devices on
the USB. That is an
issue I have found with hardware other than USRP1, including some USB
audio devices.
The bus can get into a “funny” state, and the only fix is to reboot
the host machine, or
sometimes, just power-cycle the devices on the bus. The
recommendation is to run
USRP1 (and now B100) on a dedicated USB-2.0 port, preferrably on a
dedicated
USB controller, which with most motherboards means a separate
PCI/PCI-e USB card
for either your other USB devices, or your USRP1/B100.

As I said, I’m old school. We did not have all the memory and speed of
today and making programs bullet-proof was part of the job.

I fully agree with “bullet proof”. But the pragmatic aspect of the
situation is that modern software
relies on mountains of other pieces of software to work properly
underneath it. It’s not efficient
or productive to have the “top layer” project fixing all the bugs in
the underlying layers, and sometimes,
there aren’t any reasonable work-arounds. And often, the subtlely of
those bugs (see the recent
Boost locking issues for example) may take years to finally nail
down, and at the end of the day,
the fix is in some dependency, not in Gnu Radio itself.

For example, the scheduling and various other algorithms in the Linux
kernel aren’t particularly well-tuned
for real-time data streaming with low-latency. Different versions of
the kernel will have different
emergent behaviours with respect to scheduling. Sometimes those
changes will have impact on
Gnu Radio throughput or latency, or both. Should Gnu Radio decide
“screw it, we’re writing our own
custom kernel that is tuned to Gnu Radio’s particular needs”? While
that might be the right answer for
some people, this is a community-developed project, that must
necessarily stand on the shoulders of
giants we don’t control or even influence particularly well.

In the old days, it was much more usually the case that large software
systems were integrated wholes.
Very little dependency on outside libraries, with the possible
exception of things like LIBC, or whatever
your “system API library” was called. You very typically had
complete control over the delivered
quality of your product. It’s very, very rare indeed these days to
have that luxury, with the possible exception
of certain classes of embedded systems (and many of those now run
Linux or *BSD).


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On Fri, Dec 30, 2011 at 12:41:48PM -0800, Josh B. wrote:

And please, tell us the errors you get on FreeBSD. They may be simple or
easily fixable. Let us know!

I am rebuilding today on my FreeBSD 8.2 machine, Using gmake.
Same hardware runs Ubuntu 11.04 :

gr_udp_sink.cc: In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const
char*, sh
ort unsigned int, int, bool)’:
gr_udp_sink.cc:112: error: ‘IPPROTO_UDP’ was not declared in this scope

gr_udp_source.cc has lines that are not in the sink. I think these were
there at one time but vanished. I fix this kind of thing with a patch
until
it is fixed in the source. ( I’ll do that and proceede.)

typedef void* optval_t;
+
+// ntohs() on FreeBSD may require both netinet/in.h and arpa/inet.h, in
order
+#if defined(HAVE_NETINET_IN_H)
+#include <netinet/in.h>
+#endif
+#if defined(HAVE_ARPA_INET_H)
+#include <arpa/inet.h>
+#endif
+
#elif defined(HAVE_WINDOWS_H)


LRK
gr-user . ovillatx.sytes.net

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs