I am coming across problems when using USRP2s with certain decimation
factors, and these problems are somewhat counterintuitive.
For instance, either using our own code while simply waiting for samples
to cross a threshold (so very little computation), I find that I am
getting SSS, indicating out-of-sequence packets.
This was for a decimation factor of 20. However, when I tried a
decimation factor of 10, which should have increased both the Ethernet
and the computational requirements, I no longer observed out-of-sequence
packets.
I tried the same sort of thing with usrp2_fft.py, trying decimations of
10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets
within about 10 - 20 seconds, but with decimation factor 10 I saw no
out-of-sequence packets even after a few minutes.
On Tue, May 11, 2010 at 09:24:18AM +0930, Ian H. wrote:
decimation factor of 10, which should have increased both the Ethernet
Thanks
Ian.
What GNU Radio version are you using? git? tarball?
What kind of hardware are you running on?
How much RAM is in the machine?
What OS and distribution are you running?
What kernel version are you using?
What else is running on the machine?
What USRP firmware are you using?
decimation factor of 10, which should have increased both the Ethernet
and the computational requirements, I no longer observed out-of-sequence
packets.
I tried the same sort of thing with usrp2_fft.py, trying decimations of
10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets
within about 10 – 20 seconds, but with decimation factor 10 I saw no
out-of-sequence packets even after a few minutes.
Can anybody suggest what might be going on here?
I don’t know what exactly is happening here, as I have not seen this
behavior, but I just want to clarify a little terminology. The S you
are seeing indicates sequence number errors. While getting packets out
of sequence would give this error, that isn’t that is happening. The
sequence number errors really indicate that you are dropping packets
because you can’t keep up.
Typically, if you can’t keep up at a slow decimation, going to a faster
one would make things worse, not better. The only thing I can think of
to explain what you are seeing is that you might be doing a lot more
processing at the lower rate. For example, at the lower sample rate,
you might be making your filter transition bands very narrow, resulting
in very long filters.
I’ve run into that problem (in a different context–not with USRP2). If
you make your filter transition bandwidth
some fraction of the overall bandwidth of the filter, you can end up
with longish filters and lower bandwidths.
I was used to using an expression like (filter_bandwidth/10) for the
transition bands, but that ends up with
quite long filters.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
I understand it is indicating dropped packets, hence causing later ones
to show up out-of-sequence. Re the processing, this occurs even with the
usrp2_fft.py script as well. I don’t think that does more processing for
higher values of decimation factor, though please correct me if I am
wrong here. Also, I am not doing any special filtering with my code,
simply capturing raw complex samples, and comparing their magnitude to a
threshold. Of course, once the threshold is crossed I do more
computations, but these S’s appear even while I am still listening. On
the other hand, when I reduce the decimation factor, then I don’t have
this problem until I do my other processing, which then leads to lost
packets due to excessive computational load. As such, I haven’t found a
value of decimation factor that I can use.
Not sure if this sheds any more light on the issue, but I have found
that if I shut down the PC and turn it on again, before retrying the
same tests, the problem disappears. However, as I have encountered it
before as well I am still puzzled as to why this should ever occur.
I am coming across problems when using USRP2s with certain decimation
factors, and these problems are somewhat counterintuitive.
For instance, either using our own code while simply waiting for samples
to cross a threshold (so very little computation), I find that I am
getting SSS, indicating out-of-sequence packets.
This was for a decimation factor of 20. However, when I tried a
decimation factor of 10, which should have increased both the Ethernet
and the computational requirements, I no longer observed out-of-sequence
packets.
I tried the same sort of thing with usrp2_fft.py, trying decimations of
10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets
within about 10 - 20 seconds, but with decimation factor 10 I saw no
out-of-sequence packets even after a few minutes.
I checked the power management preferences and couldn’t see anything
about CPU throttling, though I did verify it would never go to sleep
after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s
calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling
(I know I am using 9.10, not 9.04, but I imagine it should be the same).
After rebooting (only once), I haven’t yet seen the problem again.
Unfortunately, given the seemingly random nature of the problem, I guess
it is a wait-and-see matter as to whether it ever does resurface.
It seems this has not fixed the problem. Does anyone have any other
suggestions as to the possible cause? Note, I also found power cycling
the USRP2 can sometimes avoid the same problem.
On Tue, May 11, 2010 at 10:45:05AM +0930, Ian H. wrote:
Not sure if this sheds any more light on the issue, but I have found
that if I shut down the PC and turn it on again, before retrying the
same tests, the problem disappears. However, as I have encountered it
before as well I am still puzzled as to why this should ever occur.
Ian.
CPU throttling. Check power management configuration.
On Wed, May 12, 2010 at 04:34:36PM +0930, Ian H. wrote:
Hi Eric
It seems this has not fixed the problem. Does anyone have any other
suggestions as to the possible cause? Note, I also found power cycling
the USRP2 can sometimes avoid the same problem.
Ian.
Ian,
I still suspect something in your host setup.
Is the USRP2 connected directly to the host or does it go through a
switch? If there’s a switch in the path, please remove it.
Note that the cpu throttling / clock scaling hypothesis would explain
why it works better under higher load than lower load. Are you sure
that your cpu isn’t being throttled?
When you’re seeing the problem, try:
$ grep ‘cpu MHz’ /proc/cpuinfo
and see if all cores are running at full speed.
E.g.,
Idling laptop (throttled back from 1.83GHz):
[eb@cyan ~]$ grep ‘cpu MHz’ /proc/cpuinfo
cpu MHz : 1000.000
cpu MHz : 1000.000
Server with cpu scaling disabled:
[eb@octo swig]$ grep ‘cpu MHz’ /proc/cpuinfo
cpu MHz : 2999.488
cpu MHz : 2999.488
cpu MHz : 2999.488
cpu MHz : 2999.488
cpu MHz : 2999.488
cpu MHz : 2999.488
cpu MHz : 2999.488
cpu MHz : 2999.488
I tried what you suggested, and can confirm that the CPUs are not being
throttled. I have then discovered that for some reason I can only get
the problem to occur on one of my two host PCs. I am trying to install
the new Ubuntu (actually, the 64-bit version thereof) for the time
being, after formatting the hard drive, and am hoping it will work on
this PC afterwards.
Cheers
Ian.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.