Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink

[Murphy, John]

I have 5 blocks in my flowgraph:
USRP Src -> PFB Decim by 2 -> Mult 32768 -> Cplx-iShort -> FileSink
I am running 14 MS/s x 2 x 32 bits from the USRP, 7 MS/s x 2 x 16 bits
to the disk.
Previously, even setting the USRP num_recv_frames=512 or 1024, it
would run for about a minute fine then print 1-4 "O"s then run for
another 45 seconds (all estimated) and print another 1-4 "O"s etc.
Changing the USRP to output iShorts at half the rate and connecting
directly to the FileSink made no difference in this behavior. Even
halving the rate actually made no real difference in this in the few
attempts I made at that. Doubling the rate on the other hand did cause
the expected breakage.

I just tried this change... on 4/5 blocks (all except the FileSink)
set the advanced tab "Min Buffer Size" to 2097152 instead of leaving
this at zero which accepts the defaults assigned by GNU Radio
(presumably the scheduler does this). Gut feel that it would be best
to distribute this rather than concentrate it all at one end or the
other of the chain. No idea if that is correct, or if it makes a
difference one way or the other at all, toss a coin. Likewise no idea
wether there is a better setting than num_recv_frames=1024 which is
what I stuck with.

Actually, I first tried to set all the Min Buffer Size to 2^31 (2 Gig)
instead of 2^21 (2 Meg) but that generated a runtime error when it
tried to allocate those on starting the flowgraph (even though it is
only 10 GB? on a machine with 16 GB that hardly uses it for anything
else).

So... when I tried this with 2097152's it ran for at least 4-5 minutes
without a single "O" and generated a file of 7,337,295,872 bytes on
disk (or 7,337,291,776 total, whatever). My belief, not yet tested, is
that I could have left it like and it would have continued along those
lines that until it ran out of disk space. Which is the desired
behavior (not running out of disk space, just not generating overrun
errors in the recorded data).

So I believe adjusting buffering does work for flawless recording of
USRP output to a disk within the rate the disk can handle, and that
"O"s are not just a fact of life one must live with. But I still have
no idea what all this is doing quantitatively or wether there is a
better or more efficient way to allocate this buffer usage.

And that is something that would be nice to know, so if you have more
blocks in your graph how would go about figuring out what to change
this to for that, etc? Must be something far better than trial and
error to apply here.

John Murphy
address@hidden


On Mon, May 11, 2015 at 4:49 PM, Murphy, John <address@hidden> wrote:
> So... I still do not see any long term or average throughput problem
> here. Although even if it had said 69 MBytes/sec I would still think
> that is enough to handle 56 MBytes/sec average rate under the right
> circumstances.
> So... do I now need to do some sort of buffer setup to handle the data
> flow during periods the system is too busy to write to the disk, or
> the disk is too busy to be written to?
> I already have the UHD USRP Source with num_recv_frames=1024 (have
> also tried 512). In this version of UHD (3.8.1) you have to enter this
> in the Device Arguments param space without quotes.
> I also see the advanced tab of all the blocks that has the minimum and
> maximum output buffer sizes.
> But... I know nothing about how any of these work, certainly not in a
> quantitative sense anyhow.