So... there were actually several contributors to this long latency. Some of it was related to GNU Radio's inner workings, some were external. With all of the "external" things removed, there was still 1+ minute of latency at low bitrates.
I thought I would share my findings, for the sake of getting this experience publicly archived. (and maybe someone can build on these insights?) First, a little background on the application. The use case-here is that there is some moderately complex that isn't data-specific per-se. But the quality of the demodulated data is evaluated on a periodic basis to determine alignment through multiple, parallel FEC decoding chains. After alignment is detected, an appropriate chain is selected, and downstream delays are adjusted. Here are specific things that were observed: 1. We gave up on the stock selector block early on. It was misaligning samples, which effected a down-stream interleaving process. What are the general thoughts/feelings on how the selector block is currently implmeneted. 2. We tried several "clever" (ha) methods to select the desired stream. Most of them revolved around the concept of summering/xoring streams after multiplying or and'ing the streams according to which stream we wanted (operand = 1 if we wanted the stream, 0 if not). Through various methods we found that anything with a constant source, and const, etc, create this very long latencies. The behavior was this: After the streams were selected and the long latency expired the data would be valid, and latency would be quite good for such a low data rate. This seemed to indicate that somehting in the blocks used to select the stream was causing a delay - ie. inserting a lot of samples with the previous evaluated results where things would be misaligned. Either that, or the callbacks to set the new operands for stream selection were not "executing" right away. The specific offenders seem to be 1) constant source 2) and constant 3) mult_const. I haven't figured out why yet... The end solution was to do a dumb selector block that just copied the specified input to the output. Derp... -John On Fri, Oct 10, 2014 at 7:09 PM, John Malsbury <jmalsbury.perso...@gmail.com > wrote: > Is there something i can force on a per block basis in 3.6? Is there some > trickery in the forecast function I might use? > On Oct 10, 2014 6:40 PM, "Ed Criscuolo" <edward.l.criscu...@nasa.gov> > wrote: > >> On 10/10/14 9:15 PM, John Malsbury wrote: >> >>> Sounds dangerous if you also happen to have very high throughput >>> applications to run? Am I wrong? >>> >>> >> Yes, it was a fine line between getting it small enough for acceptable >> latency while still maintaining enough throughput to not overrun. >> Fortunately for our application we were able to strike that balance. >> >> Your mileage may vary. >> >> @(^.^)@ Ed >> >> >> _______________________________________________ >> 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
