On Thursday 18 February 2010 01:59:26 xor wrote: > > ----- Original Message ----- > From: <john...@kiwyepfki1gwkbfu44x5zhnbhcrbfgdowx8lom22bq4> > Newsgroups: freenet > Sent: Tuesday, February 09, 2010 5:12 PM > Subject: Re: [freenet-support] Freenet reconnection issues > > > > john...@kiwyepfki1gwkbfu44x5zhnbhcrbfgdowx8lom22bq4 wrote : > >> joh...@6kzjmqcftzffej0wthb29r63t5jkjg2xy5hzsvitg1a wrote : > >>> Matthew Toseland <t...@amphibian.dyndns.org> > >>> > >>> There was a bug "freenet does not reconnect properly": When a Freenet > >>> node > is > >>> hibernated or its IP address changes, it would take *ages* to reconnect, > it > >>> would not start announcing straight away or it would take hours to get > back up > >>> to a reasonable number of connections. I think that 1241-pre1 may have > fixed > >>> this, so if you have this bug, please test 1241-pre1. Thanks. > >>> > >>> You can get this by means of update.sh testing (linux/mac) or update.cmd > testing > >>> (windows). You might need to update the scripts manually from > >>> https://checksums.freenetproject.org/update.sh (or update.cmd) if they > haven't > >>> been used for some time and give an error message. > >>> > >>> Alternatively, use the jar I posted to freenet (this should replace your > >>> freenet.jar): > >>> http://127.0.0.1:8888/CHK%40Y7OIgh0uxo04Uf2pjN4Ni2dfctOlb- > YN5yWlud2VspU,TWXc1Yc% > >>> 7EjDMWToabe2tbaZU-i6pAuFyY8ESkwGFfuaI,AAIC--8/freenet-cvs-snapshot.jar > >> > >> Ah, that's why 1240 gave me 20 peers (of 40) in roughly 1 hour after cold > restart. I had had my node fully integrated in about 20 minutes before new > version came up and was very upset.
Announcements stop when the node reaches half the limit or 10 peers, whichever is lower. Getting from 15 peers up to 40 can take some time because it relies on path folding, not on announcement. This in turn relies on successful CHK requests. Recent builds should have improved on this very slightly if at all. > Average input speed was also 25% less than > configuration limit even after all peers had been connected (something I > don't > think I had seen before). Input speed is determined by lots of things. If you are fetching a lot of popular data, it should be reasonably high - but it won't necessarily reach torrent levels even then. If you aren't fetching anything, input speed should be slightly lower than output speed. > >> > >> Now I'm on 1241-pre2, have restarted two times and have had 20 peers in > 20-25 minutes, 30 peers in an hour. A bit better, but speed still tends to > jump higher than limit and then fall much lower than limit for a long time so > resulting average speed is currently 50% of a node's limit even with FMS and > Frost updating messages. > >> > >> I don't know if it does matter: > >> > >> Preemptive Rejection Reasons > >> 9481 Input bandwidth liability > >> 18 >SUB_MAX_PING_TIME > >> 1 >MAX_PING_TIME > >> > >> Local Preemptive Rejection Reasons > >> 3719 Input bandwidth liability > >> 5 >SUB_MAX_PING_TIME Curious. Most people's nodes are limited by *output*, not input. What are your bandwidth limits set to? Is your input limit less than your output limit? > > > > No luck. Average input speed is still 25% less than limit, 37/40 peers all > the time, six-digit number next to "Input bandwidth liability". > > > > When I turn off the limit Freenet speed can be very high (when downloading > freesite, for example) and average speed is higher than my desired limit, so > it is not network problem. > So increase the input limit. We have several conflicting goals and we can't always meet all of them at once. One important goal is not to run so many requests at once that if they all succeeded they would take an unreasonably long time to transfer - this is what "Input bandwidth liability" means.
Description: This is a digitally signed message part.
_______________________________________________ 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:support-requ...@freenetproject.org?subject=unsubscribe