According to the docs, decoding cannot begin until we have a full segment. So the opportunities for progressive decoding are limited, but we can use 4MB segments and decode one segment while fetching the next. This should provide significantly improved performance relative to what we do now, at a higher CPU cost. Small files *should* decode in a very few seconds even on slow CPUs with the pure java code.
On Tue, Sep 20, 2005 at 11:53:50PM +0100, Matthew Toseland wrote: > Only that it's slow (which can hopefully be significantly improved on by > using FECFile for progressive decoding rather than doing it all at once > at the end), and requires segments of 128*32k = 4MB. BTW is there a > significant decoding speed gain from using less redundancy? > > On Tue, Sep 20, 2005 at 06:50:43PM -0400, Ken Snider wrote: > > Matthew Toseland wrote: > > >Any ideas for splitfile FEC algorithms apart from the onion code we use > > >now (vandermonde codes)? > > > > Is there an issue with the Onion code? I ask only because I used to work > > for openCOLA back in the day when they developed that code (before it > > became onion code), and as I recall it ran circles around most of the other > > options out there. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20050921/b148fedb/attachment.pgp>
