On Friday 01 February 2008 20:26, Robert Hailey wrote: > > On Feb 1, 2008, at 11:55 AM, Matthew Toseland wrote: > > >> I'm not saying this is an issue, but when a node is busy the 90- > >> second- > >> standard might actually make the average chk transfer time (over long > >> distances) always exactly 90 seconds (through the busiest node). > >> Since > >> the transfer timeout is 120 seconds, this actually leaves only 30 > >> seconds to accumulate acceptable latency; by your previous value of > >> 30 > >> hops, this means one second per hop (1/2 ping time plus coalescing > >> delay?). > > > > Hmmm. Perhaps. So we should reduce the 90 seconds to say 60 seconds? > > That > > might cut actual bandwidth usage... > > If my understanding is right, that would only be the case during the > transition period (other nodes feed us at the 90 rate, but we expect > the 60). This would be a good reason to not drastically cut it in one > build (like, to 30; as for the time nodes would be running at 1/3 > bandwidth).
Well even if this is true, one second per hop is plenty. > > >> Or else, how many transfers are aborted because nodes disconnect, and > >> if they would succeed if the target transfer time was shorter than 90 > >> seconds? Particularly as the CHK is streaming, that the traffic up > >> unto the abort is wasted (50% payload?). > > > > Hmmm. IIRC that is fatal? > > For the request, yes. But my point is that we have already transferred > a lot of data which then does not count as payload, right? For stats purposes it counts as payload. > And it will > probably be retried almost immediately; there is no stat AFAICS which > represents request failure percentages (except Success, how many > TRANSFER_FAILED, ACCEPT_TIMEOUT, FATAL, etc). Do we need one? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080201/0b6219a2/attachment.pgp>
