From: Norbert B. <nb...@bo...> - 2009-07-11 04:29:12
|
Michael Nahas <mik...@gm...> wrote: > I'd love to see LDPC included as an alternative recovery algorithm. It's > much faster to build recovery blocks and to do recovery. It's also really > easy to implement (if we don't support recovery of another layer of recovery > blocks alla Tornado Codes). However, LDPC is probabilistic and could > frustrate users. As soon as something causes a significant number of blocks to be lost, being able to recover successfully is a probabilitic property anyway. In the case of Reed-Solomon, it can be said that the question is whether the number of lost blocks is lower or equal to the number of recovery blocks, but whether that condition is fulfilled in any particular situation is still a matter of chance. Overall, the probability that "full data recovery is possible" is only insignificantly lower with LDPC than with Reed-Solomon. > I'm strongly in favor of putting descriptions for LDPC packets in the spec. > Whether they are manditory or optional for clients to support, I could go > either way. I think that most users would be pretty frustrated if they have taken the trouble of installing a PAR3 client, and they get some PAR3 data with one packet lost, but they can't recover the lost data because their PAR3 client client fails to support the particular ECC used in that PAR3 data. Greetings, Norbert |