Re: [freenet-support] Stable build 5052
On Fri, 2004-01-09 at 14:32, Niklas Bergh wrote: > Freenet stable build 5052 is now available. > > Changelog: > * tfAbsoluteMaxThreads config parameter added. > tfAbsoluteMaxThreads will allow you to limit maximum number of > threads the YThreadFactory will spawn. Default value is 500 threads. > This solves at least some of the OutOfMemoryError:s people are > encountering. > Note that you need threadFactory=Y for this to work. AFAICS the default is still threadFactory=Q. -- Ed Huff signature.asc Description: This is a digitally signed message part ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support
[freenet-support] Stable build 5052
Freenet stable build 5052 is now available. Changelog: * tfAbsoluteMaxThreads config parameter added. tfAbsoluteMaxThreads will allow you to limit maximum number of threads the YThreadFactory will spawn. Default value is 500 threads. This solves at least some of the OutOfMemoryError:s people are encountering. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support
[freenet-support] Getting no mail
With your twiddling with addresses and earthlink.net twiddling with their spam blocker I am now getting no mail from freenet. Could you give me the domains that you are now using for mail? I know, that may not be enough information with those [freenet] additions in my mailbox, but perhaps we can give a try with the domains in my address book. On next thought, what is the formula for generating those enhanced addresses, perhaps I can generate a group of versions that will get a little more mail through the jungle. Thanks. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support
[freenet-support] Unstable build 6433
Administrative note: in future announcements of unstable builds will only go to the devl and tech lists, please subscribe to one of those lists if you run unstable. Freenet unstable build 6433 is now available. Changelog: * Fixed a major bug that was causing connections to be incapable of receiving requests * Bandwidth limiting tweaks: make low-level bandwidth limiting a little looser, in order for high-level bandwidth limiting to get a chance to operate. High-level limiting is much more efficient in the long term, it works by rejecting queries when too much bandwidth is used; low-level bandwidth limiting on the other hand slows everything down when too much bandwidth is used. Practical result: probably nodes will reject more queries, bandwidth limited nodes may use up to 40% more outbound bandwidth. Queries that are accepted should be faster and average bandwidth usage should be about the same though. You may want to reduce your bandwidth limit slightly if you have problems. * Timeout trailer chunk messages on the queue, after 10 minutes. * Logging. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support
[freenet-support] Unstable build 6432
Freenet unstable build 6432 is now available from CVS and the snapshots should be updated by the time you read this. The major change is the reinstatement of bandwidth limiting, in order to try to eliminate it as a major cause of network brokenness. This may well lead to a significant degradation in the performance of the unstable network, but we absolutely MUST know if so, so please upgrade if you run unstable, which is primarily a technology testbed. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support
Re: Fwd: [freenet-support] bug in 6430
>> I just do not know, where to report this, (probably it was noticed already >> anyway...), but the bandwith limiting in unstable version 6430 seems to be broken: >> >> Current upstream bandwidth usage 14576 bytes/second (145,8%) >> >> And the node is not QueryRejecting or something like that and the load is on 82% >> right now... >> Hope it is fixed soon, since this bug blocks your internet connection, by using the >> whole available upload bandwith :/ > >I can't reproduce that. Example: > >Current routingTime 39ms >Current messageSendTimeRequest 255ms >Pooled threads running jobs 10 (8.3%) >Pooled threads which are idle 8 >Current upstream bandwidth usage17086 bytes/second (85.4%) >Current estimated load 100% >Reason for load: >Load due to thread limit = 8.3% >Load due to messageSendTimeRequest = 30.2% = 60% + 40% * (255.497 - 1000.000) / 1000.000 <= overloadLow (60%) >Load due to output bandwidth limiting = 106.8% because outputBytes(1025189) > limit (96.014 ) = outLimitCutoff (0.8) * outputBandwidthLimit (2) * 60 > > >Can anyone else? Switch "outLimitCutoff" to the standard value of 2.0 and you can reproduce it ;) If that value is on 2.0 you reach 100% Load if you use 200% of the limit. Since you use 0.8, you will not have that problem, since then you will reach 100% Load if 80% of your Upload Limit is used. I switched that value to 1.0 yesterday, and now bandwith limiting "works" as supposed: Requests go in, until the used bandwith reaches the limit, then they are rejected. Unfortunatly the used bandwith goes up further, until the hardware maximum is reached (limit=10kb/s, hardware=~16kb/s for me). After some time less bandwith is used, until the used bandwith goes below the limit. Then it goes up again, and so on... So if you call that working, then the bandwith limiting is actually working. ;) (If you switch "outLimitCutoff"<=1.0) But I think reducing the limit, as Ed Huff suggested, should help. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support
