Ofdm reception affected by python threading?

Hi,

I’m using two USRP2 with XCVR2450s, a week old gnuradio git master and
Ubuntu 9.10.

A few months ago while using the OFDM code I observed that I tend to
receive (or send?) packets in groups, although I was sending them
individually.

Now, I finally isolated the problem. I added a few simple print lines:

“Message inserted in HAVE_HEADER” - whenever a message is enqueued in
STATE_HAVE_SYNC of ofdm_frame_sink.cc

and

“Message picked up from the queue” - in queue_watcher_thread in
ofdm.py, every time the message is fetched from the queue.

The output that I expected was:

Message inserted in HAVE_HEADER
Message picked up from the queue
Message inserted in HAVE_HEADER
Message picked up from the queue

However, I’m getting rather inconsistent output (this is a sample,
check the attachment for the first few seconds of the output):

Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message picked up from the queue
Message picked up from the queue
Message picked up from the queue
Message picked up from the queue
Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message picked up from the queue
Message picked up from the queue
Message picked up from the queue
Message picked up from the queue
Message picked up from the queue

So, it is definitely the receiver that has problems. It looks as if
“msg = self.rcvd_pktq.delete_head()” in queue_watcher_thread in
ofdm.py is not checked frequently enough. Could it be that Python does
not switch threads fast enough? Note, I do have real time scheduling
enabled.
Any ideas on how to get around this?

Thanks,

Veljko

On Fri, May 21, 2010 at 02:15:15PM -0700, Veljko P. wrote:

Message inserted in HAVE_HEADER
Message inserted in HAVE_HEADER
Message picked up from the queue
Any ideas on how to get around this?
Is your machine out of CPU cycles?
If it’s not fast enough, it won’t keep up.

Eric

Hi Eric,

Thanks for the tip. I tried it out on a faster machine, and I observed
no such problems. The first machine that produces this problem has a
single core 2.8GHz CPU and the second one, which works fine, has a
dual core Intel Atom D510, both machines have 2GB of RAM each. I
should note that the faster machine also has a better GIgEthernet
card. Interestingly, I do not observe any other signs of CPU
throttling, such as dropped packets when I see the problem.

Cheers,

Veljko

2010/5/24 Eric B. [email protected]:

On Fri, May 28, 2010 at 04:10:12PM -0700, Veljko P. wrote:

Cheers,
Veljko

The message sink is usually configured to drop packets if the queue
length
exceeds a threshold. This sheds load.

Eric