discuss-gnuradio
[Top][All Lists]
Advanced

[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> &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
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]