[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Calling work function slower in v3.8 than v3.7
From: |
Jeff S |
Subject: |
Re: Calling work function slower in v3.8 than v3.7 |
Date: |
Thu, 8 Apr 2021 17:08:36 +0000 |
Volker,
This appears to have solved my problem. Thanks much for the information!
Jeff
________________________________________
From: Discuss-gnuradio <discuss-gnuradio-bounces+e070832=hotmail.com@gnu.org>
on behalf of Volker Schroer <dl1ksv@gmx.de>
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 &device,
const std::vector<std::string> &channels,
const std::string &device_phy,
const std::vector<std::string> ¶ms,
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
>