Rickard,
Thanks for the data. Unfortunately, I have no idea what to make of
this. There isn't that much difference between the last release
(3.5.2.1) and what you get using the build-gnuradio script. That just
grabs the latest master version from our git repo, and we haven't done
all that much since the release. That really doesn't make a lot of
sense.
How's your git? If you're comfortable doing so, can you check out the
v3.5.2.1 tag on git and try that one instead of the tarball release?
Thanks,
Tom
Thanks for your info. My current take on this interrupt issue:
The problem may not be gnuradio or uhd's "fault", I now suspect. Instead
somehow the network connection and its settings might cause the interrupts. However, I am
no linux guru so I am learning at the same time as I am doing.
First, I've updated Ubuntu, from release 10.10 to 11.04, but then nothing
worked (just got a completely blank screen without any gui), so fast-forward
upgraded to 11.10 and then both laptops came right back on track. I then also
updated the gnuradio+uhd to latest (3.6.0) version using the excellent
build-gnuradio script (as before), which itself went just fine (also as before).
Unfortunately, the exact same problem with interrupts (total halt) in the
receiver at high sample rates persists. Note, as before, this happens (only?)
with very high rates over the Ethernet (about 400 mbit/s or more, the higher
rate the sooner it halts, typically just a few secs) although the computer
display no overruns or other errors.
Then by jacking around with the MTU setting (100,500, 1500,5000, etc), increasing the
default too low (and initially also gnuradio complaining) buffer settings
(net.core.rmem_max, net.core.wmem_max), disabling the Ubuntu network manager (via the
menu) and removing the automatic network configuration when USRPN210 connects and instead
setting up the network connection manually with "sudo ifconfig eth1
192.168.10.1" , I *sometimes* can get the Ethernet connection into a state to work
with the N210 at high sampling rates without any interruptions at all !
In that case, a beautiful continuous flow of samples to the crunching computer (like a fft-plot), at highest
possible rate 50 MSPS, 8 bit/samples over the wire. This *can* happen with a MTU above 1500 (or more),
buffers increased to recommended settings by UHD, and when this works the Ubuntu system manager tells me that
some 834 Mbit/samples flows through the Ethernet cable, and about 50% load on the CPU-cores, very nice. Then
it also works for repeated runs, not just one "lucky" one, and for a prolonged period of time (more
than an hour). In the working network state I can also easily provoke nice expected overruns, strings of
'ooooooooooo':hs, which isn't possible when the Ethernet connection is in the "wrong" and
"interrupted" state - since then it just halts/stops without further info.
However, finding this working network state is not just a matter of setting the
particular network parameters as I hoped it to be... I suspect some other
things are happening behind the scenes, maybe some other settings etc (I do not
yet have full knowledge of ethernets full functionality and behavior, there may
be more influencing parameters ?) which prevent me finding the working network
state in a consistent manner. Quite weird.
I have USRP-N210 rev2 (says sticker on the back) but now noticed that when I burned the
latest fw and fpga images with the net burner tool it prints "Hardware type:
n210_r3" although I selected the fpga version image for rev2 corresponding to my
version. Could this be related to my issue? Haven't noticed that inconsistent message
earlier, though.
If some of this rings any bells, please give me some further advise.
Sorry for long post.
Thanks,
Rickard