On Sat, 2005-10-01 at 01:01 +0100, Matthew Toseland wrote: > On Fri, Sep 30, 2005 at 03:06:50PM -0500, Justin Chapweske wrote: > > You understand the problem space well. One thing to think about on the > > stripe-wise retrievil/parallel decoding is to compare your decoding rate > > with your receive rate. So, if you're using K=128 that means that > > decoding can begin at around 127/128 = 99.2% completion. If you're able > > to decode an entire block in the time that it takes to receive a new > > packet/symbol at your estimated reception rate of 256 Kbps, then you > > should be able to parallelize most of the decoding. If you're finding > > that the decoding can't keep up with the reception, then you can > > introduce some slight preferencing into the system to retrieve "super > > blocks" of data. So you split the blocks into two (or more) groups and > > prioritize the first group first, then the second group second. In this > > manner, with two superblocks or groups, you'll be able to start decoding > > the first half at 50% completion. > > I'm not sure what you mean here... If I'm able to decode a segment in > the time it takes to fetch the next segment, then I don't need to block.
Sure. What I'm focusing on is assuming "stripe-wise" retrieval where the packet reception tends to fill each block at the same rate, you won't have enough data to start decoding *any* blocks until you are significantly far into the reception. At the end of the day, the only thing that makes FEC codes tricky is that there are a lot of possible variables to tweak which can have compound effects with other variables. Enough experimentation and tweaking should be able to produce the desired results, especially at the low bit rates you're dealing with. -Justin
