Re: [Discuss-gnuradio] Problem with RX OFDM through the network

[Andy Walls]

On Fri, 2016-02-19 at 12:01 -0500, address@hidden
wrote:

> Date: Fri, 19 Feb 2016 14:14:34 -0200
> From: Maicon Kist 
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Problem with RX OFDM through the
>         network

> Hello,
> 
> I?m having similar problems executing the original rx_ofdm.grc file
> (in?gnuradio/examples/digital/ofdm), which is: the quantity of numbers
> generated by the Random Source is way higher than the quantity
> received in the Tag Debug at the end of the flowgraph.
> 
> Is it possible to limit the quantity of items in the blocks
> output/input queue? This way I could ?force the flograph to have at
> max 1 item in the output/input queue of each block.


You don't want to do that.  The overhead is terrible and it likely won't
help find the problem.

First, make sure you're using the latest gnuradio (3.7.9.1?) release.
The gr-zmq blocks in any prior gnuradio release are broken, in they can
drop arbitrary numbers of samples due to improper message payload
handling; plus they chew a lot of CPU doing unneeded copies.

Switching to PUSH/PULL from REQ/REP was the right thing to do.

The random number source block isn't being favored by the scheduler,
it's just using a CPU intensive algorithm to produce samples, so it
needs more CPU time to do so.

Under certain circumstances ZeroMQ is allowed to drop messages.  If your
flowgraph blocks downstream aren't keeping up, ZeroMQ will drop whole
zeromq messages full of samples.  The default ZeroMQ high watermark is
1000 messages in later versions of ZeroMQ.  In very old versions it was
infinite, causing a paging thrash to/from disk, if you didn't keep up.


I'd start simple.  Use the lastest gnuradio with the fixed gr-zeromq
blocks.  Just put in 1 PUSH/PULL pair; not the 4 or 6 pairs you have
now.

Regards,
Andy

> Best Regards,
> 
> On February 18, 2016 at 10:58:26, Maicon Kist (address@hidden)
> wrote:
> 
> Well, Im trying to figure out why the quantity of numbers received is
> way smaller than the quantity generated.
> 
> So, I did something more simples:
> - I modified the ?rx_ofdm.grc file
> (in?gnuradio/examples/digital/ofdm). I simple added a ?Tag Debug?
> right before the second block in the chain (Stream to Tagged Stream).?
> - Even in this example the quantity of numbers generated is 10x the
> quantity of numbers recoved in the end of the flowgraph.
> 
> It seems to me that the scheduler prioritizes the ?Random Source?,
> calling it several times more than the other blocks in the flowgraph.
> Is there a way to fix this?
> 
> Best Regards.
> 
> On February 18, 2016 at 09:09:32, Maicon Kist (address@hidden)
> wrote:
> 
> Hello
> 
> I manage to solve the problem ?of
> gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at
> item 2112
> gr::log :INFO: header_payload_demux0 - Parser returned #f
> by replacing all ZMQ REP/REQ by ZMQ PUSH/PULL blocks.?
> 
> Now, my only problem is that the Random Source Generator is generating
> (d?) way more numbers that are being received in the final part of the
> flowgraph (Tag Debug).
> 
> ?Any hints about this too ?