On Friday 14 March 2008 16:17, Robert Hailey wrote:
>
> On Mar 14, 2008, at 9:45 AM, Matthew Toseland wrote:
>
> > Since we introduced packet priorities, transfer failures have
> > replaced lost
> > messages as the main cause of large numbers of error messages in
> > freenet
> > logs. I have tried to investigate this: Firstly, I have set up some
> > simulations in an attempt to reproduce any bugs which cause this
> > (RealNodeBusyNetworkTest). So far, I only see transfer failures when
> > the CPU
> > is saturated. Secondly, I have added a new statistic for the
> > proportion of
> > transfers which succeed. On my node this seems to be consistently
> > >90%.
> > Therefore, it seems reasonable to abandon the chase for the time
> > being, and
> > demote the timeout messages to NORMAL?
>
> Ok... this is expected given the code for r18410.
>
> On Mar 7, 2008, at 9:18 AM, toad at freenetproject.org wrote:
> > Modified: trunk/freenet/src/freenet/io/xfer/BlockTransmitter.java
> > ===================================================================
> > --- trunk/freenet/src/freenet/io/xfer/BlockTransmitter.java
> > 2008-03-07 13:29:54 UTC (rev 18409)
> > +++ trunk/freenet/src/freenet/io/xfer/BlockTransmitter.java
> > 2008-03-07 15:18:04 UTC (rev 18410)
> > @@ -97,7 +97,7 @@
> > }
> > int totalPackets;
> > try {
> > - _destination.sendThrottledMessage(DMT.createPacketTransmit(_uid,
> > packetNo, _sentPackets, _prb.getPacket(packetNo)), _prb._packetSize,
> > _ctr);
> > + _destination.sendThrottledMessage(DMT.createPacketTransmit(_uid,
> > packetNo, _sentPackets, _prb.getPacket(packetNo)), _prb._packetSize,
> > _ctr, SEND_TIMEOUT);
> > if(_ctr != null) _ctr.sentPayload(_prb._packetSize);
> > totalPackets=_prb.getNumPackets();
> > } catch (NotConnectedException e) {
> > @@ -108,6 +108,12 @@
> > Logger.normal(this, "Terminating send due to abort: "+e);
> > //the send() thread should notice...
> > return;
> > +} catch (WaitedTooLongException e) {
> > + Logger.normal(this, "Waited too long to send packet, aborting");
> > + synchronized(_senderThread) {
> > + _sendComplete = true;
> > + }
> > + return;
>
> If sending the block transfer would timeout, WaitedTooLongException is
> thrown (although a misnomer as it is before the wait...); and the
> receiver is never notified. This would imply that some links are too
> slow to transfer the average number of blocks even if the node(s)
> themselves are not overloaded.
No. The timeout is caused after a wait. PeerNode.sendThrottledPacket sets the
deadline, then calls PacketThrottle.sendThrottledPacket. The complication is
that the latter may have to be called multiple times if a node changes its IP
address. But for it to throw a WaitedTooLongException, we must have passed
the deadline, therefore we presumably have waited.
I have seen "Unable to send throttled message, waited 0ms", but not recently.
I'm not sure what it means.
-------------- 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/20080314/b0fd5e46/attachment.pgp>
