Sounds dangerous if you also happen to have very high throughput applications to run? Am I wrong?
On Fri, Oct 10, 2014 at 5:59 PM, Ed Criscuolo <edward.l.criscu...@nasa.gov> wrote: > Yep, that was me. I was getting to pipe-in with the same suggestion. > > @(^.^)@ Ed > > > > On 10/10/14 8:20 PM, Vanush Vaswani wrote: > >> I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The >> only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in >> flat_flowgraph.cc. >> This is regarded as a dodgy hack by all the GR developers here, but it >> worked for me (and I read the article on latency). I believe the guy >> who wrote GMSKSpacecraftGroundstation had the same problem, and found >> it in one of his old threads. >> >> On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob <dan.caja...@gmail.com> >> wrote: >> >>> Hey John, >>> >>> I am way out of my depth here, but while working on a custom python block >>> the other day, I saw some weird behavior in 3.7.5 that was similar. >>> Setting >>> the global max output had no effect, but setting the just-upstream >>> block(s) >>> min/max output buffer size(s) low fixed my apparent slowliness. >>> >>> Very Respectfully, >>> >>> Dan CaJacob >>> >>> On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury >>> <jmalsbury.perso...@gmail.com> wrote: >>> >>>> >>>> Default scheduler. >>>> >>>> tb.start(1024), with different values, etc, etc. >>>> >>>> Most of the downstream blocks are stock GNU Radio blocks - a delay block >>>> (max delay is 1 sample), logical operators, etc. I guess I'll add some >>>> printf debugging? >>>> >>>> -John >>>> >>>> >>>> >>>> >>>> On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller < >>>> marcus.muel...@ettus.com> >>>> wrote: >>>> >>>>> >>>>> Hi John, >>>>> On 10.10.2014 19:33, John Malsbury wrote: >>>>> >>>>> Toward the end of the receive chain, there are a multitude of blocks >>>>> that >>>>> are used for Viterbi node synchronization. I've found that the number >>>>> of >>>>> blocks in series (3-5), combined with the low datarates at this point >>>>> in >>>>> the flowgraph, lead to latencies on the order of 1-2 minutes. That is >>>>> to >>>>> say, once the node synchronization is accomplished, it takes 1-2 >>>>> minutes >>>>> to >>>>> flush these blocks and get the fresh, good data through. This is >>>>> measured >>>>> with function probes on the state of the sync process, and BERT >>>>> analysis >>>>> of >>>>> the demodulator output [through TCP/IP socket]. >>>>> >>>>> I see you found the hidden interplanetary signal delay simulator. >>>>> Congrats! Watch out for the red shift in downstream samples. >>>>> >>>>> No, seriously, that sounds like a lot. >>>>> You are using 3.6.4.1 with the default scheduler, tpb? >>>>> >>>>> - I've tried messing around with the output buffer size option in >>>>> the >>>>> flowgraph, but this seems l to have a negligible impact. >>>>> >>>>> That surprises me. How did you mess around? top_block->run(1024)? >>>>> Do your blocks really get called with smaller input item sizes? (do a >>>>> little printf-debugging) >>>>> >>>>> - I can write some custom blocks to reduce the overall block count, >>>>> but >>>>> I have demonstrated that this provides a linear improvement, rather >>>>> than >>>>> the two-order-magnitude improvement I need. >>>>> >>>>> Any general advice anyone can offer? It feels like the right solution >>>>> is >>>>> to force small buffer sizes on the relevant blocks... >>>>> >>>>> agreed. But still. That sounds *bad*. Are you sure none of the block >>>>> demands a large input/output multiple? >>>>> >>>>> >>>>> Greetings, >>>>> Marcus >>>>> >>>>> -John >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
