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 jmur...@comsonics.com On Mon, May 11, 2015 at 4:49 PM, Murphy, John <jmur...@comsonics.com> 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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
