does ./benchmark_loopback.py work?
If this works then the generic vs simd is not an issue for you.
If the loopback does not work I would try an svn update and rebuild. Eric
fixed
the issue with the simd code last week.
The original poster (dev) had some issues with the _tx and _rx but I have
Just reconfigured and tested, looks like benchmark_loopback is working
fine now on all my systems. Thanks everyone!
Dev
Eric Blossom wrote:
On Tue, Oct 02, 2007 at 03:42:43PM -0700, Tim Meehan wrote:
The update seems to work. I re-ran configure and verified that the SSE code
was being used.
Eric,
See reply embedded
On 10/1/07, Eric Blossom [EMAIL PROTECTED] wrote:
On Mon, Oct 01, 2007 at 06:07:51PM -0700, Tim Meehan wrote:
Eric,
The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When the
malloc16Allign is replaced with a regular malloc in the QA code, make
On Tue, Oct 02, 2007 at 04:10:07AM -0700, Tim Meehan wrote:
Eric,
See reply embedded
Thanks.
On 10/1/07, Eric Blossom [EMAIL PROTECTED] wrote:
On Mon, Oct 01, 2007 at 06:07:51PM -0700, Tim Meehan wrote:
Eric,
The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When
On 10/2/07, Eric Blossom [EMAIL PROTECTED] wrote:
snip
Yes I do see the 0RCR or R case. For example when I change the QA
code
to use stack allocation for the input (uncommenting a piece of code
that
was originally there, lines 110 and 111 in the QA code from trunk) the
check
On Tue, Oct 02, 2007 at 08:52:06AM -0700, Tim Meehan wrote:
In the production code, I.e., where you are seeing problems (was it
around gri_mmse_fir_interpolator?), do you see the alignment
problem occur?
In the production code the input is declared in gr_mpsk_receiver_cc.h line
300
Tim,
I've checked a trial fix into the trunk as of r6575.
Can you please update and let me know if it fixes your problem?
Thanks,
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
The update seems to work. I re-ran configure and verified that the SSE code
was being used. make check passes and the original code Dev had a problem
with benchmark_loopback.py works correctly.
Tim
On 10/2/07, Eric Blossom [EMAIL PROTECTED] wrote:
Tim,
I've checked a trial fix into the
On Tue, Oct 02, 2007 at 03:42:43PM -0700, Tim Meehan wrote:
The update seems to work. I re-ran configure and verified that the SSE code
was being used. make check passes and the original code Dev had a problem
with benchmark_loopback.py works correctly.
Tim
Thanks!
Eric
Tim,
I reconfigured both my 32 bit laptop and desktop to use the generic,
and they both work now with benchmark_loopback. Unforunately, I still am
unable to communicate between any USRPs with the benchmark_tx and _rx
scripts. Thanks for all your work on this. When I have some free time
I'll
Hi!
Does make check pass on your system when you set it to use SIMD? It would
be interesting to know if this error is not found with the standard tests.
Dominik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
Just tried this on my laptop which seems to be using whatever
non-functioning code Tim mentioned. Make check passed successfully.
Dev
Dominik Auras wrote:
Hi!
Does make check pass on your system when you set it to use SIMD? It would
be interesting to know if this error is not found with the
Make check does pass, and there appears to be QA code (qa_gr_fir_ccf.cc). I
am not sure that
if the QA code actually gets called by a top level make check If you
would like me to look
into it I can but I suspect whoever wrote the QA code originally could do it
a lot faster than me:-)
On
On Mon, Oct 01, 2007 at 03:40:40PM -0400, Tim Meehan wrote:
Make check does pass, and there appears to be QA code (qa_gr_fir_ccf.cc). I
am not sure that
if the QA code actually gets called by a top level make check If you
would like me to look
into it I can but I suspect whoever wrote the
Eric,
The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When the
malloc16Allign is replaced with a regular malloc in the QA code, make check
fails.
I believe that there is an additional requirement that the data passed to
the low-level SSE code have the real sample start on the 0th or
On Mon, Oct 01, 2007 at 06:07:51PM -0700, Tim Meehan wrote:
Eric,
The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When the
malloc16Allign is replaced with a regular malloc in the QA code, make check
fails.
I believe that there is an additional requirement that the data
Dev, Johnathan and All,
After re-reading Dev's emails about 64 vs 32 bit and realizing that
gr_mpsk_receiver_cc.cc has not changed in some time, I took another look at
this.
On my build gr_fir_ccf-filter() was not functioning properly. This is
called be the gri_mmse_fir_interpolator from
Dev, Johnathan, and all
After spending some time looking through gr_mpsk_receiver_cc.cc I am not
sure how this
ever worked. Below is a patch that works for me. There are two minor
changes
1) I did not understand how the delay line for the interpolator could work
as coded so I changed it to
Running benchmark_loopback.py with gmsk (-m gmsk) seems to work
correctly for all my systems. Unfortunately, the same doesn't seem to be
true of the benchmark_rx and benchmark_tx, which use gmsk by default.
Changing them to any of the other modulation options didn't yield any
results either.
I have some additional hints.
When I run with 2 samples per symbol (the default)
./benchmark_loopback.py -s 20 -M 0.004 -S 2
ok = False pktno = 19 n_rcvd =1 n_right =0
ok = False pktno =7 n_rcvd =2 n_right =0
ok = False pktno = 180 n_rcvd =3 n_right =0
I've been looking into this problem further. I apologize in advance for
the long post. To make things easier, I'll represent the three computers
I'm using as follows:
32deb - 32bit Debian desktop
32red - 32bit Fedora laptop
64red - 64bit Fedora desktop
benchmark_loopback.py:
Were either of you able to resolve this? Any hints on where I might try to
find the problem? I spent some time digging around pkt.py.
I get similar results running svn 6504 under Debian testing (Lenny). This
was a fresh install on a clean machine. I do not see the same problems on a
similar
Tim Meehan wrote:
ok = False pktno = 14 n_rcvd =1 n_right =0
ok = False pktno = 189 n_rcvd =2 n_right =0
ok = False pktno = 98 n_rcvd =3 n_right =0
ok = False pktno = 134 n_rcvd =4 n_right =0
ok = False pktno = 156 n_rcvd =5 n_right
I suspect that the pktno from below is just garbage from false syncs.
I placed some prints in pkt.py
send_pkt places a message on the queue 667 times.
in class queue_watcher_thread
under run
msg = self.rcvd_pktq.delete_head() occurs 27 times
Tim
On 9/22/07, Johnathan Corgan [EMAIL
Hi all,
I have three computers running with gnuradio, all updated to the latest
svn, all sudo make uninstalled and make distcleaned first. I'm
running into a strange problem. When running benchmark_loopback.py in
the digital examples folder on my desktop (running Debian) and on my
laptop
Dev Ramudit wrote:
I've cleaned out and reinstalled gnuradio from all three computers
repeatedly, but I end up with the same result every time. Any suggestions?
Can you check the version of Python and location of GNU Radio on each:
$ python
Python 2.5.1 (r251:54863, May 2 2007, 16:27:44)
Johnathan Corgan wrote:
Dev Ramudit wrote:
I've cleaned out and reinstalled gnuradio from all three computers
repeatedly, but I end up with the same result every time. Any suggestions?
Can you check the version of Python and location of GNU Radio on each:
$ python
Python 2.5.1
Dev Ramudit wrote:
Hope that helps, thanks!
It helps in the sense that it confirms a correct installation :)
The failure symptoms are odd. The system shows receiving five packets,
which indicates that modulator/demodulator and framer/deframer are
probably working correctly.
The packet number
Johnathan Corgan wrote:
Dev Ramudit wrote:
Hope that helps, thanks!
It helps in the sense that it confirms a correct installation :)
The failure symptoms are odd. The system shows receiving five packets,
which indicates that modulator/demodulator and framer/deframer are
probably working
29 matches
Mail list logo
