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

[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 &device,
                    const std::vector<std::string> &channels,
                    const std::string &device_phy,
                    const std::vector<std::string> &params,
                    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