[freenet-dev] Still getting timeouts

[Matthew Toseland]

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 : http://emu.freenetproject.org/pipermail/devl/attachments/20080201/0b6219a2/attachment.pgp