Receiving stuck with STREAM_MODE_NUM_SAMPS_AND_DONE mode

[youkozlov]

Issue Description

There is a simple program based on uhd examples to test STREAM_MODE_NUM_SAMPS_AND_DONE(STREAM_MODE_NUM_SAMPS_AND_MORE) mode. Essence of the algorithm - periodic request some portion of samples from USRP and receiving that requested part. Algorithm has fixed requests period and amount of requested samples. But every execution after 524281 iteration(about 4 minutes) I see LL in stdout console. Is it expected behavior? Are there some restriction with STREAM_MODE_NUM_SAMPS_AND_DONE mode? We tried to use dpdk mode, link second usrp interface and achived +/- same rusults. Example is executed at isolated CPU core with performance tuning according recommendation from usrp manuals(mtu=9000, huge recv/send buffers and etc). Ethernet irqs is binded to isolated cores. I'm not sure if the problem is with PC performance.
master clock rate = 122.88e6
rate = 122.88e6
request period = 122880 samples
number of requested samples = 61440

Setup Details

version: UHD-4.1
fpga: https://files.ettus.com/binaries/cache/n3xx/meta-ettus-v4.1.0.5/
commit: 6bd0be9
usrp: n310
pc: linux ubuntu 20.04 with low latency kernel, 24 core amd 3,8g, eth 2x10g

Expected Behavior

stable execution

Actual Behaviour

test_discont_receiving.zip

stuck after 524281 iteration

Steps to reproduce the problem

taskset -c 1 ./test_discont_receiving --args="master_clock_rate=122880000.000000" --nsamps=50000000000 --rate=122880000 --channels="0,1" --samplStep=122880 --samplsToSend=61440

Additional Information