On Feb 8, 2008, at 10:19 AM, Matthew Toseland wrote: > On Friday 08 February 2008 16:08, Robert Hailey wrote: >> >> I think that this (or more specifically r17687) is a little confused. >> >> You see, the consecutive missing reports is reset to zero every time >> that we receive a new packet; it is effectively the number of >> timeouts >> we can incur before we give up (and the timeout is 30 seconds). So... >> as long as the transmitter is transmitting, it is irrelevant; but >> after r17687, the receiver will hang around for four minutes waiting >> for packets. >> >> I suggest that the bug you are chasing is more related to the >> transmitter (and possibly crazy-slow nodes/high ping time); as the >> problem is surely way too many concurrent transfers > > IMHO not possible because of output bandwidth liability limiting. > >> and not lack of >> timeout grace. Possibly (1) high-pingtime/throttling problem, (2) >> ULPR >> transfers somehow not being accounted for, etc. See the error >> statement on BlockTransmitter(~#149), which could be tightened up >> (right now at two minutes), or simply made to abort the transfer: > > The real problem is likely to be a bug in the transport layer. > > I suggest you revert my change.
Done in r17699. >> Logger.error(this, "per-packet congestion control delay: "+(end- >> now)); > > Do you see this often? I have seen it randomly in the past, but not often. It was certain whenever the crazy-slow-node/bug#2006 cropped up (i.e. whenever the transmission throttle to a peer effectively stops), which BTW has *not* happened since we last discussed it. -- Robert Hailey > >> >> The change may be acceptably benign, but I don't think that it is >> beneficial; it either keep threads hanging around or just let crazy- >> slow transfers pile up. >> >> -- >> Robert Hailey
