Re: Problem with porting an OOT module to 3.8 (sampling speed)

[wk]

> Hi Wojciech,
>
> On 02.10.20 15:51, Wojciech Kazubski wrote:
> > I suppose that in 3.8 the source block has to signal required sample rate to
> > GR runtime. Is this correct?
>
> No, that's not correct. The runtime doesn't care about required rates at
> all. It just makes blocks produce items as fast as they can.
>
> > How to fix the code?
>
> Good question! Unless you're doing something *very* specific in your
> code, I'd honestly blame this on a bug that was introduced during
> porting – but I might be wrong.
>
> Two very common tools to investigate this are rather simple:
>
> 1. htop (a `top`-alike program with a bit better visualization), with
> thread names enabled – that way you can see which block occupies the CPU
> the most, because all blocks run in their own thread
> 2. `perf` (especially, `perf top -a`), which allows you to sample in
> which function your CPU cores are most often. That way, you can identify
> functions that might be the blockers there.
>
> Best regards,
> Marcus

I thik that the problem is not related to CPU load by my blck. The
total CPU load is very low, less than 5%. I made some debugging by
addin some test messages printed each time data is  written to or read
from the internal buffer. Data is written to the buffer by libusb and
read by calling a "work" function (in bloccks of 4096 samples at a
time).

In 3.7 I see great number of messages indicatig tha data ie read from
the buffer. Part (about half) of the messages show 0 bytes read, due to
lack of new data from usb. By this, data rate is reduced from  ~30Msps
to 16.368Msps.

In contrast in 3.8 the work function is called only about 4 times a
second, giving 16ksps. This is some 2000 times less than in 3.7.

--
Best regards
Wojciech