On Friday 14 November 2008 17:40, Dennis Nezic wrote: > On Thu, 13 Nov 2008 18:16:55 +0000, 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]
