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). >> 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? 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). -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080201/e59b3adf/attachment.html>
