[freenet-support] Freenet 0.7 build 1175

2008-11-14 Thread Matthew Toseland 
On Friday 14 November 2008 17:40, Dennis Nezic wrote:
> On Thu, 13 Nov 2008 18:16:55 +, Matthew Toseland
>  wrote:
> 
> > Freenet 0.7 build 1175 is now available. Please upgrade. Changes:
> > - Handle the "Packet X sent Yms ago and still not acked" bug better.
> > Don't complain in the log until 10 minutes, then disconnect from the
> > peer and log the fact. We can then reconnect, but we will do so
> > cleanly, so hopefully not get it again for a while. It seems that
> > most of the disruption caused by this bug was caused by the logging
> > on every resend and not the bug itself... Of course we will need to
> > fix the bug too.
> 
> State Of The (My) 1175... It "feels" like it's running smoother,
> although it's cpu profile here hasn't changed substantially. Perhaps
> just a bit, due to better logging. The log files are finally usable!
> (Usually under 100K per hour now :)

It still has 100% CPU most of the time then? Apparently resulting from Freenet 
itself rather than downloads etc?

Try 1178 ... and then wait until say Wednesday ... hopefully once everyone has 
1178, it will be much better.
> 
> So, in one random 1 hour sample, here are the main ones that I get:
> 
> 4 "Forcing disconnect" PacketSender ERRORs, both from opennet and
> darknet peers, "because packets not acked after 10 minutes!". Does this
> mean that NO packets have been received from these peers, or just a big
> bunch of them? (I'm pretty sure my ISP doesn't kill connections, but
> just drops a fraction of the packets.) For some reason, these error
> messages come in pairs, first by FNPPacketMangler, then by (Dark|Open)
> netPeerNode.

This is caused by the bugs we're chasing at the moment. Hopefully next week it 
will have gone away, or be very rare. It means that we are still connected to 
the node, it's still sending us packets, but it apparently doesn't understand 
some of the packets we send it.
> 
> 40 MessageCore ERRORs "from RequestSender  waitFor _unclaimed iteration
> took 3428ms with unclaimedFIFOSize of 533 for ret of packetTransmit" or
> "from UdpSocketHandler checkFilters took 6260ms with unclaimedFIFOSize
> of 596 for matched: true"
> 
> 24 freenet.io.xfer.BlockTransmitter.sendAsync(), "Terminated send
> -123413232423 ... as we haven't heard from receiver in 1m54s."
> 
> 4 freenet.io.xferPacketThrottle, Blocktransmitter: "Unable to send
> throttled message, waited 60100ms"
> 
> 6 freenet.io.comm.MessageCore Scheduled job ERRORS
> "removeTimedOutFilters took 4000ms"

Hopefully these are related to the current bugs. If so they should greatly 
reduce. On the other hand, they may not be ...
> 
> 4 freenet.node.KeyTracker PacketSender "Packet 1234 sent over 600600ms
> ago and still not acked". (THEY STILL EXIST!?! ;)

Yes, we log them at the same time as the disconnections.
> 
> 19 freenet.io.comm.UdpSocketHandler ERROR messages (from both darknet
> and opennet), "processing packet took 4000ms" .. with times ranging
> from 3000ms to 6600ms.
> 
> 8 freenet.node.FNPPacketMangler "Message[1..4] timeout error:
> Processing packet for freenetnode.tld:1234"
> 
> Also, in this log, I have noticed that the port number, in the
> @ip:port@ portion of the error message does NOT match the port number
> listed on the /friends/ web page. Why is that? 

It can be different, usually because of NATs, occasionally because you are 
connected both to the darknet and opennet nodes on that IP (which is a bug, 
shouldn't happen unless you have some wierd configs set).

> (What happens, by the 
> way, if a darknet peer does change his port, by the way--we'd have to
> re-add his node reference?)

Probably yes.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:

[freenet-support] Freenet 0.7 build 1175

2008-11-14 Thread Dennis Nezic 
On Fri, 14 Nov 2008 19:52:46 +, Matthew Toseland
 wrote:

> It still has 100% CPU most of the time then? Apparently resulting
> from Freenet itself rather than downloads etc?

Well, it's not /so/ serious that it stays at 100% all the time. It
jumps up for a few minutes, then calms down to almost nothing for a
few minutes. (The valleys are longer than the peaks.) And keeps
repeating this. I'm running another process that steadily uses on
average 25% of the (1.2GHz) cpu, and my 15minute load time is
consistently around 3. Maybe the threads are all triggered to run at
the same time, and should be staggered? 


> > Also, in this log, I have noticed that the port number, in the
> > @ip:port@ portion of the error message does NOT match the port
> > number listed on the /friends/ web page. Why is that? 
> 
> It can be different, usually because of NATs, occasionally because
> you are connected both to the darknet and opennet nodes on that IP
> (which is a bug, shouldn't happen unless you have some wierd configs
> set).

Actually, the logs do say that I was connected to this same ip address
both in opennet and darknet :|. (And the opennet port is properly
listed in the strangers page. (It seems unlikely that his darknet port
would be routed in a NAT, but not his opennet port :|.)

[freenet-support] Freenet 0.7 build 1175

2008-11-14 Thread Dennis Nezic 
On Thu, 13 Nov 2008 18:16:55 +, Matthew Toseland
 wrote:

> Freenet 0.7 build 1175 is now available. Please upgrade. Changes:
> - Handle the "Packet X sent Yms ago and still not acked" bug better.
> Don't complain in the log until 10 minutes, then disconnect from the
> peer and log the fact. We can then reconnect, but we will do so
> cleanly, so hopefully not get it again for a while. It seems that
> most of the disruption caused by this bug was caused by the logging
> on every resend and not the bug itself... Of course we will need to
> fix the bug too.

State Of The (My) 1175... It "feels" like it's running smoother,
although it's cpu profile here hasn't changed substantially. Perhaps
just a bit, due to better logging. The log files are finally usable!
(Usually under 100K per hour now :)

So, in one random 1 hour sample, here are the main ones that I get:

4 "Forcing disconnect" PacketSender ERRORs, both from opennet and
darknet peers, "because packets not acked after 10 minutes!". Does this
mean that NO packets have been received from these peers, or just a big
bunch of them? (I'm pretty sure my ISP doesn't kill connections, but
just drops a fraction of the packets.) For some reason, these error
messages come in pairs, first by FNPPacketMangler, then by (Dark|Open)
netPeerNode.

40 MessageCore ERRORs "from RequestSender  waitFor _unclaimed iteration
took 3428ms with unclaimedFIFOSize of 533 for ret of packetTransmit" or
"from UdpSocketHandler checkFilters took 6260ms with unclaimedFIFOSize
of 596 for matched: true"

24 freenet.io.xfer.BlockTransmitter.sendAsync(), "Terminated send
-123413232423 ... as we haven't heard from receiver in 1m54s."

4 freenet.io.xferPacketThrottle, Blocktransmitter: "Unable to send
throttled message, waited 60100ms"

6 freenet.io.comm.MessageCore Scheduled job ERRORS
"removeTimedOutFilters took 4000ms"

4 freenet.node.KeyTracker PacketSender "Packet 1234 sent over 600600ms
ago and still not acked". (THEY STILL EXIST!?! ;)

19 freenet.io.comm.UdpSocketHandler ERROR messages (from both darknet
and opennet), "processing packet took 4000ms" .. with times ranging
from 3000ms to 6600ms.

8 freenet.node.FNPPacketMangler "Message[1..4] timeout error:
Processing packet for freenetnode.tld:1234"

Also, in this log, I have noticed that the port number, in the
@ip:port@ portion of the error message does NOT match the port number
listed on the /friends/ web page. Why is that? (What happens, by the
way, if a darknet peer does change his port, by the way--we'd have to
re-add his node reference?)

Re: [freenet-support] Freenet 0.7 build 1175

2008-11-14 Thread Dennis Nezic 
On Thu, 13 Nov 2008 18:16:55 +, Matthew Toseland
[EMAIL PROTECTED] wrote:

 Freenet 0.7 build 1175 is now available. Please upgrade. Changes:
 - Handle the Packet X sent Yms ago and still not acked bug better.
 Don't complain in the log until 10 minutes, then disconnect from the
 peer and log the fact. We can then reconnect, but we will do so
 cleanly, so hopefully not get it again for a while. It seems that
 most of the disruption caused by this bug was caused by the logging
 on every resend and not the bug itself... Of course we will need to
 fix the bug too.

State Of The (My) 1175... It feels like it's running smoother,
although it's cpu profile here hasn't changed substantially. Perhaps
just a bit, due to better logging. The log files are finally usable!
(Usually under 100K per hour now :)

So, in one random 1 hour sample, here are the main ones that I get:

4 Forcing disconnect PacketSender ERRORs, both from opennet and
darknet peers, because packets not acked after 10 minutes!. Does this
mean that NO packets have been received from these peers, or just a big
bunch of them? (I'm pretty sure my ISP doesn't kill connections, but
just drops a fraction of the packets.) For some reason, these error
messages come in pairs, first by FNPPacketMangler, then by (Dark|Open)
netPeerNode.

40 MessageCore ERRORs from RequestSender  waitFor _unclaimed iteration
took 3428ms with unclaimedFIFOSize of 533 for ret of packetTransmit or
from UdpSocketHandler checkFilters took 6260ms with unclaimedFIFOSize
of 596 for matched: true

24 freenet.io.xfer.BlockTransmitter.sendAsync(), Terminated send
-123413232423 ... as we haven't heard from receiver in 1m54s.

4 freenet.io.xferPacketThrottle, Blocktransmitter: Unable to send
throttled message, waited 60100ms

6 freenet.io.comm.MessageCore Scheduled job ERRORS
removeTimedOutFilters took 4000ms

4 freenet.node.KeyTracker PacketSender Packet 1234 sent over 600600ms
ago and still not acked. (THEY STILL EXIST!?! ;)

19 freenet.io.comm.UdpSocketHandler ERROR messages (from both darknet
and opennet), processing packet took 4000ms .. with times ranging
from 3000ms to 6600ms.

8 freenet.node.FNPPacketMangler Message[1..4] timeout error:
Processing packet for freenetnode.tld:1234

Also, in this log, I have noticed that the port number, in the
@ip:port@ portion of the error message does NOT match the port number
listed on the /friends/ web page. Why is that? (What happens, by the
way, if a darknet peer does change his port, by the way--we'd have to
re-add his node reference?)
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Re: [freenet-support] Freenet 0.7 build 1175

2008-11-14 Thread Matthew Toseland 
On Friday 14 November 2008 17:40, Dennis Nezic wrote:
 On Thu, 13 Nov 2008 18:16:55 +, Matthew Toseland
 [EMAIL PROTECTED] wrote:
 
  Freenet 0.7 build 1175 is now available. Please upgrade. Changes:
  - Handle the Packet X sent Yms ago and still not acked bug better.
  Don't complain in the log until 10 minutes, then disconnect from the
  peer and log the fact. We can then reconnect, but we will do so
  cleanly, so hopefully not get it again for a while. It seems that
  most of the disruption caused by this bug was caused by the logging
  on every resend and not the bug itself... Of course we will need to
  fix the bug too.
 
 State Of The (My) 1175... It feels like it's running smoother,
 although it's cpu profile here hasn't changed substantially. Perhaps
 just a bit, due to better logging. The log files are finally usable!
 (Usually under 100K per hour now :)

It still has 100% CPU most of the time then? Apparently resulting from Freenet 
itself rather than downloads etc?

Try 1178 ... and then wait until say Wednesday ... hopefully once everyone has 
1178, it will be much better.
 
 So, in one random 1 hour sample, here are the main ones that I get:
 
 4 Forcing disconnect PacketSender ERRORs, both from opennet and
 darknet peers, because packets not acked after 10 minutes!. Does this
 mean that NO packets have been received from these peers, or just a big
 bunch of them? (I'm pretty sure my ISP doesn't kill connections, but
 just drops a fraction of the packets.) For some reason, these error
 messages come in pairs, first by FNPPacketMangler, then by (Dark|Open)
 netPeerNode.

This is caused by the bugs we're chasing at the moment. Hopefully next week it 
will have gone away, or be very rare. It means that we are still connected to 
the node, it's still sending us packets, but it apparently doesn't understand 
some of the packets we send it.
 
 40 MessageCore ERRORs from RequestSender  waitFor _unclaimed iteration
 took 3428ms with unclaimedFIFOSize of 533 for ret of packetTransmit or
 from UdpSocketHandler checkFilters took 6260ms with unclaimedFIFOSize
 of 596 for matched: true
 
 24 freenet.io.xfer.BlockTransmitter.sendAsync(), Terminated send
 -123413232423 ... as we haven't heard from receiver in 1m54s.
 
 4 freenet.io.xferPacketThrottle, Blocktransmitter: Unable to send
 throttled message, waited 60100ms
 
 6 freenet.io.comm.MessageCore Scheduled job ERRORS
 removeTimedOutFilters took 4000ms

Hopefully these are related to the current bugs. If so they should greatly 
reduce. On the other hand, they may not be ...
 
 4 freenet.node.KeyTracker PacketSender Packet 1234 sent over 600600ms
 ago and still not acked. (THEY STILL EXIST!?! ;)

Yes, we log them at the same time as the disconnections.
 
 19 freenet.io.comm.UdpSocketHandler ERROR messages (from both darknet
 and opennet), processing packet took 4000ms .. with times ranging
 from 3000ms to 6600ms.
 
 8 freenet.node.FNPPacketMangler Message[1..4] timeout error:
 Processing packet for freenetnode.tld:1234
 
 Also, in this log, I have noticed that the port number, in the
 @ip:port@ portion of the error message does NOT match the port number
 listed on the /friends/ web page. Why is that? 

It can be different, usually because of NATs, occasionally because you are 
connected both to the darknet and opennet nodes on that IP (which is a bug, 
shouldn't happen unless you have some wierd configs set).

 (What happens, by the 
 way, if a darknet peer does change his port, by the way--we'd have to
 re-add his node reference?)

Probably yes.


pgpSwGcvJVVsB.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Re: [freenet-support] Freenet 0.7 build 1175

2008-11-14 Thread Matthew Toseland 
Please tell me, one way or the other, whether the problem is solved or whether 
Freenet continues to use lots of CPU etc etc. Thanks.

On Friday 14 November 2008 19:52, Matthew Toseland wrote:
 On Friday 14 November 2008 17:40, Dennis Nezic wrote:
  On Thu, 13 Nov 2008 18:16:55 +, Matthew Toseland
  [EMAIL PROTECTED] wrote:
  
   Freenet 0.7 build 1175 is now available. Please upgrade. Changes:
   - Handle the Packet X sent Yms ago and still not acked bug better.
   Don't complain in the log until 10 minutes, then disconnect from the
   peer and log the fact. We can then reconnect, but we will do so
   cleanly, so hopefully not get it again for a while. It seems that
   most of the disruption caused by this bug was caused by the logging
   on every resend and not the bug itself... Of course we will need to
   fix the bug too.
  
  State Of The (My) 1175... It feels like it's running smoother,
  although it's cpu profile here hasn't changed substantially. Perhaps
  just a bit, due to better logging. The log files are finally usable!
  (Usually under 100K per hour now :)
 
 It still has 100% CPU most of the time then? Apparently resulting from 
Freenet 
 itself rather than downloads etc?
 
 Try 1178 ... and then wait until say Wednesday ... hopefully once everyone 
has 
 1178, it will be much better.
  
  So, in one random 1 hour sample, here are the main ones that I get:
  
  4 Forcing disconnect PacketSender ERRORs, both from opennet and
  darknet peers, because packets not acked after 10 minutes!. Does this
  mean that NO packets have been received from these peers, or just a big
  bunch of them? (I'm pretty sure my ISP doesn't kill connections, but
  just drops a fraction of the packets.) For some reason, these error
  messages come in pairs, first by FNPPacketMangler, then by (Dark|Open)
  netPeerNode.
 
 This is caused by the bugs we're chasing at the moment. Hopefully next week 
it 
 will have gone away, or be very rare. It means that we are still connected 
to 
 the node, it's still sending us packets, but it apparently doesn't 
understand 
 some of the packets we send it.
  
  40 MessageCore ERRORs from RequestSender  waitFor _unclaimed iteration
  took 3428ms with unclaimedFIFOSize of 533 for ret of packetTransmit or
  from UdpSocketHandler checkFilters took 6260ms with unclaimedFIFOSize
  of 596 for matched: true
  
  24 freenet.io.xfer.BlockTransmitter.sendAsync(), Terminated send
  -123413232423 ... as we haven't heard from receiver in 1m54s.
  
  4 freenet.io.xferPacketThrottle, Blocktransmitter: Unable to send
  throttled message, waited 60100ms
  
  6 freenet.io.comm.MessageCore Scheduled job ERRORS
  removeTimedOutFilters took 4000ms
 
 Hopefully these are related to the current bugs. If so they should greatly 
 reduce. On the other hand, they may not be ...
  
  4 freenet.node.KeyTracker PacketSender Packet 1234 sent over 600600ms
  ago and still not acked. (THEY STILL EXIST!?! ;)
 
 Yes, we log them at the same time as the disconnections.
  
  19 freenet.io.comm.UdpSocketHandler ERROR messages (from both darknet
  and opennet), processing packet took 4000ms .. with times ranging
  from 3000ms to 6600ms.
  
  8 freenet.node.FNPPacketMangler Message[1..4] timeout error:
  Processing packet for freenetnode.tld:1234
  
  Also, in this log, I have noticed that the port number, in the
  @ip:port@ portion of the error message does NOT match the port number
  listed on the /friends/ web page. Why is that? 
 
 It can be different, usually because of NATs, occasionally because you are 
 connected both to the darknet and opennet nodes on that IP (which is a bug, 
 shouldn't happen unless you have some wierd configs set).
 
  (What happens, by the 
  way, if a darknet peer does change his port, by the way--we'd have to
  re-add his node reference?)
 
 Probably yes.
 


pgpJKAp7pRaAF.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Re: [freenet-support] Freenet 0.7 build 1175

2008-11-14 Thread Dennis Nezic 
On Fri, 14 Nov 2008 19:52:46 +, Matthew Toseland
[EMAIL PROTECTED] wrote:

 It still has 100% CPU most of the time then? Apparently resulting
 from Freenet itself rather than downloads etc?

Well, it's not /so/ serious that it stays at 100% all the time. It
jumps up for a few minutes, then calms down to almost nothing for a
few minutes. (The valleys are longer than the peaks.) And keeps
repeating this. I'm running another process that steadily uses on
average 25% of the (1.2GHz) cpu, and my 15minute load time is
consistently around 3. Maybe the threads are all triggered to run at
the same time, and should be staggered? 


  Also, in this log, I have noticed that the port number, in the
  @ip:port@ portion of the error message does NOT match the port
  number listed on the /friends/ web page. Why is that? 
 
 It can be different, usually because of NATs, occasionally because
 you are connected both to the darknet and opennet nodes on that IP
 (which is a bug, shouldn't happen unless you have some wierd configs
 set).

Actually, the logs do say that I was connected to this same ip address
both in opennet and darknet :|. (And the opennet port is properly
listed in the strangers page. (It seems unlikely that his darknet port
would be routed in a NAT, but not his opennet port :|.)
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

[freenet-support] Freenet 0.7 build 1175

2008-11-13 Thread Matthew Toseland 
Freenet 0.7 build 1175 is now available. Please upgrade. Changes:
- Handle the "Packet X sent Yms ago and still not acked" bug better. Don't 
complain in the log until 10 minutes, then disconnect from the peer and log 
the fact. We can then reconnect, but we will do so cleanly, so hopefully not 
get it again for a while. It seems that most of the disruption caused by this 
bug was caused by the logging on every resend and not the bug itself... Of 
course we will need to fix the bug too.
- Show a search box on the homepage, pointing to XMLLibrarian, if XMLLibrarian 
is not loaded.
- Finnish translation update.

Please report any bugs you find to the bug tracker:
https://bugs.freenetproject.org/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:

[freenet-support] Freenet 0.7 build 1175

2008-11-13 Thread Matthew Toseland 
Freenet 0.7 build 1175 is now available. Please upgrade. Changes:
- Handle the Packet X sent Yms ago and still not acked bug better. Don't 
complain in the log until 10 minutes, then disconnect from the peer and log 
the fact. We can then reconnect, but we will do so cleanly, so hopefully not 
get it again for a while. It seems that most of the disruption caused by this 
bug was caused by the logging on every resend and not the bug itself... Of 
course we will need to fix the bug too.
- Show a search box on the homepage, pointing to XMLLibrarian, if XMLLibrarian 
is not loaded.
- Finnish translation update.

Please report any bugs you find to the bug tracker:
https://bugs.freenetproject.org/


pgpvSFM2zWbfN.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]