* bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-04 15:48:09]:
> Ok, so I will open a feature request for this issue. Because with the
> informations provided in SimpleProgress a freenet client cannot
> display a correct progress to the user. Either we need more
> informations about the progress of each segment, or the node
> normalizes this by itself and provides a percentage :)
>
> But the current behavior often leads to downloads that have more than
> 100% progress *g*
Is it *that* important to have an accurate progress bar ? some blocks
can take *ages* to be retrived whereas some will come up
instantaneously... Imho we can't provide a reliable
percentage/ETA/whatever for small files even if we had detailled stats
on what's going on.
Btw, haven't you ever experienced the same "bug" on the queue toadlet on
fproxy ? more than a lack of feedback from fcp, it's a network
charateristic : we can't predict precisely the time needed to fetch
anything and even less waranty it will be delivered on time.
Making FCP more verbose is probably a good idea, but do not think it
will enable you to display a precise ETA from it. Keep in mind what
the 'E' is standing for ;)
> On 1/4/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org>
> wrote:
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-04
> > 15:40:24]:
> >
> > > Of course I heard about FEC, in fact I implemented all this stuff in
> > > the 0.5 part of Frost by myself ;)
> > >
> > > And thats why I thought if the node says X blocks are required, then
> > > this amount of blocks is required to decode the file (no matter if
> > > data or check blocks).
> > > So please tell me what Required means in the SimpleProgress message
> > > then? Or do you mean that there were not enough blocks for one
> > > segment, but more than enough for another segment, is it this?
> >
> > That's probably it ... it's hard to tell without logs.
> >
> > >
> > > On 1/4/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org>
> > > wrote:
> > > > * bbackde at googlemail.com <bbackde at googlemail.com> [2006-12-29
> > > > 22:04:07]:
> > > >
> > > > > Following SimpleProgress shows it: some threads in freenet node seems
> > > > > to be started and do not finish if we have all the needed blocks:
> > > > >
> > > > > SimpleProgress {Total=9606, FatallyFailed=2, FinalizedTotal=true,
> > > > > Failed=287, Su
> > > > > cceeded=6411, Identifier=get-11673399350836773, Required=6404}
> > > > > EndMessage
> > > > >
> > > > > Its a request with DDA enabled, not in global queue.
> > > > >
> > > > > Reasons? Fixes? Ideas?
> > > >
> > > > Well, it's a wholly erroneous interpretation of what "required" means.
> > > > It does mean that the download *can't* complete without that "amount" of
> > > > blocks... but it doesn't mean it will.
> > > >
> > > > Ever heard of ForwardErrorCorrection and Hamming distance ?
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFFnRJuU/Z/dHFfxtcRAtxsAJ0b1s3hkAc5U/MVnz5iVBMsI6O2AgCfRwOW
> > En/iX2M3+WV8QIpGwJw2tpk=
> > =B4sk
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > Tech mailing list
> > Tech at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
> >
> >
> _______________________________________________
> Tech mailing list
> Tech at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
-------------- 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/20070104/7bc3542d/attachment.pgp>
