Re: Calling work function slower in v3.8 than v3.7

2021-04-08 Thread Jeff S
Volker,

This appears to have solved my problem.  Thanks much for the information!

Jeff


From: Discuss-gnuradio  
on behalf of Volker Schroer 
Sent: Thursday, April 8, 2021 3:30 AM
To: discuss-gnuradio@gnu.org
Subject: Re: Calling work function slower in v3.8 than v3.7

I found this piece of code, that may help.
It's taken from
https://github.com/dl1ksv/gr-iio/blob/gr3.9/lib/device_sink_impl.cc
which is a fork of analogdevicesinc/gr-iio


lines 163 ff

 /*
  * The private constructor
  */
 device_source_impl::device_source_impl(struct iio_context *ctx,
bool destroy_ctx, const std::string ,
const std::vector ,
const std::string _phy,
const std::vector ,
unsigned int buffer_size, unsigned int decimation)
   : gr::sync_block("device_source",
   gr::io_signature::make(0, 0, 0),
   gr::io_signature::make(1, -1, sizeof(short))),
 port_id(pmt::mp("msg")),
 timeout(100),
 ctx(ctx), buf(NULL),
 buffer_size(buffer_size),
 decimation(decimation),
 destroy_ctx(destroy_ctx)


and lines 336

if (!fast_enough) {
message_port_pub(port_id, pmt::mp("timeout"));
/* GNU Radio won't call our block anytime soon if the
 * work() function returns 0; it can take up to 500ms
 * before it gets called again. To avoid that, we make
 * this block send itself a dummy message on its input
 * system message port, so that the scheduler calls us
 * again promptly. */
pmt::pmt_t payload = pmt::from_long(0);
pmt::pmt_t msg = pmt::cons(pmt::mp("done"), payload);
post(pmt::mp("system"), msg);
return 0;


-- Volker



Am 07.04.21 um 21:34 schrieb Jeff S:
> I am having an issue with a custom OOT module which is acting as a burst 
> source.  It receives an asynchronous message in one thread, and then puts 
> data into the stream using another thread.  This worked fine using GR v3.7, 
> but with v3.8, not so much.
>
> I believe my problem may have to do with how the scheduler operates now, in 
> that in v3.7, the ::work() function was called very quickly ( at a rate of < 
> 1 ms per call), no mater what data is being sent into the stream.  With 
> version 3.8, when no data is being sent into the stream, I am getting a 
> fairly constant 250 ms calls to ::work().  This causes a significant delay 
> for when data is received to when it can get transmitted (when I'm looking 
> for a <= 4 ms response).
>
> I've search a bit in the archives, but haven't found quite what I'm looking 
> for.  Is there a way to signal the scheduler asynchronously to make a call to 
> ::work(), or to make the scheduler call work at a faster rate?
>
> Thanks.
> Jeff
>





Re: Calling work function slower in v3.8 than v3.7

2021-04-08 Thread Volker Schroer

I found this piece of code, that may help.
It's taken from
https://github.com/dl1ksv/gr-iio/blob/gr3.9/lib/device_sink_impl.cc
which is a fork of analogdevicesinc/gr-iio


lines 163 ff

/*
 * The private constructor
 */
device_source_impl::device_source_impl(struct iio_context *ctx,
bool destroy_ctx, const std::string ,
const std::vector ,
const std::string _phy,
const std::vector ,
unsigned int buffer_size, unsigned int decimation)
  : gr::sync_block("device_source",
  gr::io_signature::make(0, 0, 0),
  gr::io_signature::make(1, -1, sizeof(short))),
port_id(pmt::mp("msg")),
timeout(100),
ctx(ctx), buf(NULL),
buffer_size(buffer_size),
decimation(decimation),
destroy_ctx(destroy_ctx)


and lines 336

if (!fast_enough) {
message_port_pub(port_id, pmt::mp("timeout"));
/* GNU Radio won't call our block anytime soon if the
 * work() function returns 0; it can take up to 500ms
 * before it gets called again. To avoid that, we make
 * this block send itself a dummy message on its input
 * system message port, so that the scheduler calls us
 * again promptly. */
pmt::pmt_t payload = pmt::from_long(0);
pmt::pmt_t msg = pmt::cons(pmt::mp("done"), payload);
post(pmt::mp("system"), msg);
return 0;


-- Volker



Am 07.04.21 um 21:34 schrieb Jeff S:

I am having an issue with a custom OOT module which is acting as a burst 
source.  It receives an asynchronous message in one thread, and then puts data 
into the stream using another thread.  This worked fine using GR v3.7, but with 
v3.8, not so much.

I believe my problem may have to do with how the scheduler operates now, in that in 
v3.7, the ::work() function was called very quickly ( at a rate of < 1 ms per 
call), no mater what data is being sent into the stream.  With version 3.8, when no 
data is being sent into the stream, I am getting a fairly constant 250 ms calls to 
::work().  This causes a significant delay for when data is received to when it can 
get transmitted (when I'm looking for a <= 4 ms response).

I've search a bit in the archives, but haven't found quite what I'm looking 
for.  Is there a way to signal the scheduler asynchronously to make a call to 
::work(), or to make the scheduler call work at a faster rate?

Thanks.
Jeff






Calling work function slower in v3.8 than v3.7

2021-04-07 Thread Jeff S
I am having an issue with a custom OOT module which is acting as a burst 
source.  It receives an asynchronous message in one thread, and then puts data 
into the stream using another thread.  This worked fine using GR v3.7, but with 
v3.8, not so much.

I believe my problem may have to do with how the scheduler operates now, in 
that in v3.7, the ::work() function was called very quickly ( at a rate of < 1 
ms per call), no mater what data is being sent into the stream.  With version 
3.8, when no data is being sent into the stream, I am getting a fairly constant 
250 ms calls to ::work().  This causes a significant delay for when data is 
received to when it can get transmitted (when I'm looking for a <= 4 ms 
response).

I've search a bit in the archives, but haven't found quite what I'm looking 
for.  Is there a way to signal the scheduler asynchronously to make a call to 
::work(), or to make the scheduler call work at a faster rate?

Thanks.
Jeff