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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
