Re: Migration path, please! (Re: [freenet-support] Freenet 0, 5 and 0, 7
Juiceman wrote: With 10 connections, the data that could intercepted by one attacker is roughly 10%. The problem is the attacker doesn't know how many connections you have, so you could just be passing on data from any number of connections you have. It's currently trivialy easy to find out if a request of a connected peer was forwarded by that peer or if it was a local request from that peer because local requests aren't stored in the datastore/-cache. (http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity, search for the headline "Datastore") Thus you only have to probe the datastore of the requesting peer after sending the data to it and can find out if it was forwarded or originated there. In my opinion this isn't really acceptable on either a dark- or opennet (perhaps on a true darknet but that doesn't exist right now) but it certainly would cause havoc on an opennet. ___ 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] Snapshots
It seems so, as if the snapshots do not get updated anymore. At least the unstable-latest.jar (or similiar, the file which gets downloaded from the update script) is still version 60103, although 60105 was already announced. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] various problems
In einer eMail vom Di, 27. Apr. 2004 17:40 MEZ schreibt [EMAIL PROTECTED]: In einer eMail vom Di, 27. Apr. 2004 16:26 MEZ schreibt Niklas Bergh [EMAIL PROTECTED]: As soon as a new build with your logging improvements gets out I will report what is loged then, thanks for your help so far. :) The Error Action cannot be taken after termination does not happen anymore after the update to 60079, strange. (and nice ;) )But the temp-files are still not deleted properly and the error Please close() me manually in finalizer: Key: *removed* Buffer: [EMAIL PROTECTED] : *removed*:temp:*removed* New: true ( 0 of 262460 read) java.lang.IllegalStateException: unclosed does still occur. And a new one was introduced: sendingPacket NULL in sendPacket java.lang.Exception: debug ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] various problems
In einer eMail vom Mi, 28. Apr. 2004 14:28 MEZ schreibt [EMAIL PROTECTED]: The Error Action cannot be taken after termination does not happen anymore after the update to 60079, strange. (and nice ;) ) Have to correct me, they reappeared. For some reason not one of them occured at first, so I just began to hope that they vanished... ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Bug found in 5077
In einer eMail vom Di, 27. Apr. 2004 15:44 MEZ schreibt Toad [EMAIL PROTECTED]: On Sun, Apr 25, 2004 at 01:57:41PM +0200, Rama Jagerman wrote: Current upstream bandwidth usage 164677 bytes/second (164.7%) [...] average out to no more than the target. HOWEVER, there is a hard limit of 140% of the stated limit. The reason we have two limits is that there are two limiting mechanisms. If you get this sort of transfer [...] If I did not miss something, then that output transfer speed is over the hard limit and that seems a little bit wrong to me. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] various problems
In einer eMail vom Di, 27. Apr. 2004 15:25 MEZ schreibt Toad [EMAIL PROTECTED]: On Tue, Apr 27, 2004 at 09:16:41AM -0400, [EMAIL PROTECTED] wrote: In einer eMail vom Di, 27. Apr. 2004 13:03 MEZ schreibt Niklas Bergh [EMAIL PROTECTED]: There seems to be a whole bunch of different temp files around.. Not only 'store\temp'... Maybe some of those other contained files? I will check that, I thought temp files are in the specified temp folder. Why do you assign one, if the temp files are stored somewhere else... Because we need to store *datastore* temp files in the datastore. Whereas other temp files can be anywhere. I have now checked the datastore and found the temp folder in it. Should have looked there before... Anyway, I have not count the files in the folder, but the output of them to the console took 10 - 20 secs, so there are probably some hundred files in it. (Currently near 400MB of temp-files after two and a half hours) Some were even created soon after the startup of freenet and never touched again. It seems so, as if freenet simply fails to delete them, or at least does not do that. (If you think of the IO error because of too man open files, this should result after some time in near 1000 temp-files.) Would it hurt the node if I would just delete some of the old ones, while freenet is running, to free up some space, or could that for example damage the datastore? (ok, they should be opened, I do not know if it is possible to delete open files, but I do not think so. :|) ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] various problems
I wanted to report, that I get currently a lot of the following error messages: Action cannot be taken after termination java.lang.Exception: debug Please close() me manually in finalizer: Key: *removed* Buffer: [EMAIL PROTECTED] : *removed*:temp:*removed* New: true ( 0 of 262460 read) java.lang.IllegalStateException: unclosed I do not know, what the error messages mean, but perhaps it has something to do with the following behaviour: Every time I insert something, the value Space used by temp files increases irreversible. It does not matter if the insert succeeds or not (usually not, my current insert speed is between 0kb/s and 1kb/s, sometimes freenet does not manage to get anything inserted for hours), the value increases and never decreases again. The crazy thing about this is, that the temp folder contains at any time only some files (the maximum I observed was something around 20). At one time there was not one single file in the temp folder and freenet reported 200MB of temp files... This behaviour ends normally in a Java VM crash after some time (I do not think, that the crashes have something to do with this, Java VM crashes occured already before, but just in case...), or, if the reported temp file value reaches around 700MB, in a IO error, because too many files are opened. (Which files?! Some files in the datastore?) Freenet is already working with the same settings for months, so I do not think, that I have misconfigured anything, but it may be, that I just had not inserted enough in the past, to notice this behaviour. (The node is running on Linux Mandrake 9.1, so this is definatly not the windows temp file bug or something like that!) A month ago I did not insert much data and I could run freenet for up to 2 days or more on that computer without any crash (as long as I did not put heavy load on the node), so this should have something to do with recent changes, but I could be wrong there. I have already tried various changes to the settings (for example disabling the diagnostics, just in case that they use temp files or disabling the datastore index, just to test if it got corrupted or something like that.), but nothing really helped. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] The Freenet Experience
In einer eMail vom Fr, 23. Apr. 2004 5:45 MEZ schreibt Galen [EMAIL PROTECTED]: Hi Freenet People, I'd like to hear about your experience with and uses for freenet. I'm interested in those that use freenet. How usable is it? What is your setup? What kind of performance do you get? What kinds of content do you get on it? How often do you use it? I ask this as one hopelessly trapped behind NAT (well, at least for a little while longer) and not really able to sample freenet properly. Thanks, Galen Currently I am running freenet on an old P2 linux box permanently. The memory is limited to 100mb, but as long as I do not use the fproxy interface too much I can run a freenet node for more then 2 days. (at least that was the case around one week ago.) The CPU usage is also ok, I am not experiencing any problems which could be caused from an overloaded CPU. The linux computer is behind a NAT router with port forwarding set and has a extremly limited upload bandwith (7kb/s) and a more moderatly set download bandwith (40kb/s right now thinking of limiting to 20kb/s) because this way I am able to use the internet for other things while running the freenet node the whole time. (the bandwith limits are set in the config of the node - higher set upload bandwith caused the whole internet access to be blocked sometimes - using DSL). Currently the node gets around 1500 request/hour and finishes around 4% (thats changing often, this is a better value) of them. The node has a datastore of 25GB, which is completly used. Data seems to last around 3 months in it(unaccessed), but that will depend on how much I download. If I download not so much data it will last longer. Currently I am having problems with RNFs despite more then 100 connections and a routing table of ~400 nodes (~300 node references), but data finding is not bad as soon as a request can be made. (The popular dbr sites can be fetched most of the time, only near the rollover time I have sometimes problems which seems logical.) To the usage: I am runing a second computer permanently for fuqid and frost, but I use only a small amount of threads for requests. (normally around 20 threads together) So as you see it is really possible to use freenet with DSL and NAT. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] OutOfMemoryError
In einer eMail vom Di, 16. März 2004 17:28 MEZ schreibt Niklas Bergh [EMAIL PROTECTED]: Fwolff said: And to the philosophy of some devs: RAM is cheap New SDRAM will be detected only with half of it's normal size or even not detected at all in old computers When I was having problems with half-size-detected issues it turned out that it was due to the old motherboard only managing to detect one _side_ of any double-sided SDRAMs... Thats not the problem with new RAM here. double-sided, single-sided, they are all the same. they just get detected half. If tested with newest bios, older bios, newer or older computers that does not make any difference. It is caused from some changes in the SDRAM architecture compared to the old RAM. At least it was explained in this way to me. Actually I have some double-sided RAMs, which are way older, running in the same computers correctly, in which newer one is only detected half. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] OutOfMemoryError
In einer eMail vom Sa, 13. März 2004 3:52 MEZ schreibt Chris Gentile [EMAIL PROTECTED]: I am also struggling with 5074. Here is my freenet.conf: ipAddress=www.gentilehome.com listenPort=27882 seedNodes=seednodes.ref outputBandwidthLimit=48000 storeSize=3G overloadHigh=0.6 overloadLow=0.4 I've got a fast net connection 7mbps downstream 1mbps upstream. I've got over 2GB in my store. After a few hours of stability (6 or so), it stops sending/receiving significant amounts of data and the CPU sits at 100%. The memory sits at 150MB and I see these errors in the freenet.log Mar 12, 2004 7:14:38 PM (freenet.PeerPacketParser, Network reading thread, ERROR): Caught java.lang.OutOfMemoryError in [EMAIL PROTECTED] PeerPacketParser[lengthBuffered=-1, waitingMessageLength=-1, waitingMessageCurrentBytes=-1, [EMAIL PROTECTED] MuxConnectionHandler[conn=[tcp/connection: 3540580.134.44.225:31603,[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], identity=[DSA(a971 6c0e ce49 3474 7679 8e61 f4e5 67bb f1c3 0cc5)], sock=[Socket[addr=drumbass.dyndns.org/80.134.44.225,port=31603,localport=35405]], chan=[java.nio.channels.SocketChannel[connected local=/192.168.1.50:35405 remote=drumbass.dyndns.org/80.134.44.225:31603]], peer=[Peer [DSA(a971 6c0e ce49 3474 7679 8e61 f4e5 67bb f1c3 0cc5) @ 80.134.44.225:31603 (1/3)]], outbound=[true]]].processMessage(buf,86,105,true) java.lang.OutOfMemoryError As per the default start-freenet.sh script, java is being launched with this switch: -Xmx128m S, what gives? Why can't it live within it's 128MB space? - Chris Gentile Chris Gentile [EMAIL PROTECTED] Cause freenet wants as much memory as possible... ;) You could try unstable, if you want that, since memory usage seems to be a little bit less insane there. At least my node can run more then 2 days with a maximum of 100mb allocated RAM with unstable. But the more you use your freenet node (making requests, looking at the interface,...) the faster it gets out of memory (Thats at least my experience.), and you can do what you want, you will have to restart your node every one or two days. And to the philosophy of some devs: RAM is cheap New SDRAM will be detected only with half of it's normal size or even not detected at all in old computers (if you call computers from up to 2000 old...), so you have to buy some RAMs with large sizes and thats not so cheap (or old version of that type of RAM, but thats not that easy, too). Apart from that it is not that easy to get more then 256MB RAM in older computers like P2s, because they do not like RAMs with larger sizes. So the maximum alocate able size of memory is below 200MB, with some OSs even further down. But ok, it already got a lot better in the last unstable builds. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Webinterface with 6495
I will try another update now, but I wanted to report this, since I have not read of a similar problem with that build until now in the support group. It failed, too. Just now I run that build without the webinterface, but I will switch back to the old build, soon. It works again in 6 :) ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] Webinterface with 6495
I yesterday executed the update.sh script and got that way the 6495 build. But I had to reinstall the old build a hour later, because with 6495 build the webinterface stopped working. At least I could not access it with any network computer I tried, and that worked all builds before. I cannot test, if the webinterface works at the node-pc, since that computer is running only in the console mode of linux, and I do not now enough linux commands to test, if the PC is even listening on the right port and so on. (and the xserver is broken on that pc, no way to get a graphical interface there, without having to mess with a lot linux things, which I do not understand...) I will try another update now, but I wanted to report this, since I have not read of a similar problem with that build until now in the support group. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Webinterface with 6495
I will try another update now, but I wanted to report this, since I have not read of a similar problem with that build until now in the support group. It failed, too. Just now I run that build without the webinterface, but I will switch back to the old build, soon. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: E-Mail nicht zustellbar
In einer eMail vom So, 15. Feb. 2004 21:43 MEZ schreibt Paul Derbyshire [EMAIL PROTECTED]: On 15 Feb 2004 at 18:39, [EMAIL PROTECTED] wrote: Die E-Mail, die Sie am Fri, 13 Feb 2004 21:14:02 -0500 an [EMAIL PROTECTED] gesendet haben, konnte nicht zugestellt werden, da die E-Mail Adresse [EMAIL PROTECTED] nicht existiert. Achten Sie auf die richtige Schreibung der E-Mail Adresse und versuchen Sie es erneut. Sollten Sie wieder diese E-Mail erhalten, vergewissern Sie sich, das der Empfänger (noch) ein Mitglied unseres E-Mail Dienstes ist. Could you please repeat that in English? I don't understand your followup to my post. (In fact, since you quoted not a word of it I could only infer it is a response to one of my posts by your having mailed me a copy.) I guess you thought I could speak what looks like German for some odd reason -- I'm afraid I must report that I don't speak a word of it, as a matter of fact; I haven't a clue what gave you the impression that I did, or why for that matter you'd reply off- language to an English-language mailing list. In any event the result is clear: your response has not been understood, and is unlikely to be by me or most of the others around here save by your repeating it in a language you know all of us understand. :) The Mail is some kind of automatic reply from [EMAIL PROTECTED]. It means that a mail could not be delivered because the email-address [EMAIL PROTECTED] does not exist. I do not understand completly, how this mail could be caused, but thats what it says :) I would guess, that the mail was sent from the mailserver freemail4u.ath.cx automatically in reply to a mail from a user. But I do not understand, how that message got to the maillist. Perhaps because the user tried again with the error message in it. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
RE: RE: [freenet-support] Crashes with 6469
In einer eMail vom Di, 10. Feb. 2004 15:57 MEZ schreibt [EMAIL PROTECTED]: In einer eMail vom Di, 10. Feb. 2004 12:44 MEZ schreibt Niklas Bergh [EMAIL PROTECTED]: This is prbably not causing you trouble.. I have committed some logging changes that will better say what the cause is now (will incluse a callstack and what the atual sizes are). Let me know what it says. Regards /N This logging changes are implemented in 6470? I just run the upgrade skript after I saw your Mail and upgraded this way to that version. Stopping Freenet was necessary anyway: It stopped working again, this time after 40mins uptime and without an error. After some time the interface was reachable again, but there was no internet traffic, so this was definatly not caused by overload. If 6470 is the version with your changes, you have actually fixed it for me.. :/ At least the error did not appear until now, and before it appeared right after starting the node. I will send a mail, if I see the error again. But after Fproxy responded again at the last half-crash (Thats also strange, since Freenet did not recover at all at the previous two crashes), I noticed also some freenet.Message: DataRequest @freenet.MuxConnectionHandler errors in the Recent Log thing. They occured somewhere near the death of the node, so they could have something to do with it, but I am not sure about the exact time of the death, so thats hard to judge. After I have reduced the log level to Normal, I noticed, that I get sometimes several Unrecognized Trailer ID errors in just a second, but if I remember previous postings to the support list correctly, that error is common. Perhaps it's just another of this errors, which just leave on their own, as I wrote in the first post... I would not be mad if it would be so. As I write this mail, the node is running fo 35 mins, no sign of the previus size error and it responds good, but I have not made any request, so perhaps it's just because of that. (Before the first and second request I made some Fproxy Requests and before the third some Fuqid downloads with 5 Threads.) ok, the problem was fixed with that version for sure, the node runs now again for at least 24 hours. (have not tried further, because of updating.) Even the memory leak seems to have got smaller, at least my node only uses ~65MB of maximal available 100mb memory most of the time, thats better then before. Thanks for your help :) ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] Crashes with 6469
After updating to 6469 I always get this log entry right after starting the node, before the first request is made. 12:13:07 Size was wrong reading in SimpleDataObjectStore Until now I was also not able to run the node for longer then one or two hours, while it before would run for more then one day. Now it always crashes ~1 hour after starting with an error I have not seen before. Something with the thread factory and AutoRequest. Will copy it the next time when it is prompted in the Linux Terminal. Freenet will run on after that Error, but there are no transfers anymore and no interface is working. (Just the threads stay there.) Perhaps it's just another problem that will vanish on it's own, but since it occured on both restarts which were made after the update, the update and the crash seem related to me. As before I have no logs with the status Normal, since I only let log events with the status Error, since this seem to avoid out of memory errors for me. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
RE: RE: [freenet-support] Crashes with 6469
In einer eMail vom Di, 10. Feb. 2004 12:44 MEZ schreibt Niklas Bergh [EMAIL PROTECTED]: This is prbably not causing you trouble.. I have committed some logging changes that will better say what the cause is now (will incluse a callstack and what the atual sizes are). Let me know what it says. Regards /N This logging changes are implemented in 6470? I just run the upgrade skript after I saw your Mail and upgraded this way to that version. Stopping Freenet was necessary anyway: It stopped working again, this time after 40mins uptime and without an error. After some time the interface was reachable again, but there was no internet traffic, so this was definatly not caused by overload. If 6470 is the version with your changes, you have actually fixed it for me.. :/ At least the error did not appear until now, and before it appeared right after starting the node. I will send a mail, if I see the error again. But after Fproxy responded again at the last half-crash (Thats also strange, since Freenet did not recover at all at the previous two crashes), I noticed also some freenet.Message: DataRequest @freenet.MuxConnectionHandler errors in the Recent Log thing. They occured somewhere near the death of the node, so they could have something to do with it, but I am not sure about the exact time of the death, so thats hard to judge. After I have reduced the log level to Normal, I noticed, that I get sometimes several Unrecognized Trailer ID errors in just a second, but if I remember previous postings to the support list correctly, that error is common. Perhaps it's just another of this errors, which just leave on their own, as I wrote in the first post... I would not be mad if it would be so. As I write this mail, the node is running fo 35 mins, no sign of the previus size error and it responds good, but I have not made any request, so perhaps it's just because of that. (Before the first and second request I made some Fproxy Requests and before the third some Fuqid downloads with 5 Threads.) ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] problems with rate limiting
After upgrading to 6459 I got this situation: Current routingTime 18ms Current messageSendTimeRequest 0ms Pooled threads running jobs 22 (20%) Current upstream bandwidth usage 211 bytes/second (2,1%) Estimated external pSearchFailed (based only on QueryRejections due to load): 1.8249762470488975E-21 Current recommended request interval sent to client nodes 1825735.5630938804ms (deleted the, as I think, unimportant lines) for some reason the request interval got insane, with the result, that the node got the last 500 queries in 2,7 hours. Probably the node got no request since then. The node also did some other strange things after the update: For example it allowed a lot inbound connection from nodes with versions below 6452, and took also some in the routing table. There was even some transferring, both up and down. I know, I should switch the port, to not get any inbound connection from old nodes, but it seems strange to me, that the node is actually communicating with nodes with different network protocolls and is even transferring usefull data as it seems. Until now (7 hours after the upgrade), the old nodes seem to disappear from the routing table, but even now they are not completly gone. The node is also currently easily overloaded, (FCP connection are often rejected for no obvious reason) then actually blocking the whole internet connection. I also get a lot RNFs again, which was not the case before at least 6457. I just will try to restart it now, hoping that that will help. If someone want a log or something: I could start logging now, but for reducing the out of memory errors, I reduced the log level to Error, so there is really nearly nothing interesting in there right now. The only entrys are right now: 21:06:44 Please close() me manually in finalizer: Key: d3b3237051aac42b0ae6f33a435823cd6bd3337e120302 Buffer: [EMAIL PROTECTED]:0x1:aac42b0ae6f33a435823cd6bd3337e120302:temp:262641:a09e6d4f6132b600 New: true ( 0 of 262460 read) 01:00:56 jobPartDone(245) on [EMAIL PROTECTED] MuxConnectionHandler[conn=[tcp/connection: CLOSED,[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], identity=[DSA(099a 5af2 bdc7 1eb5 bbfb fa36 a90d 6573 3217 f0e7)], sock=[Socket[addr=/68.48.126.51,port=19407,localport=6824]], chan=[java.nio.channels.SocketChannel[connected local=/192.168.213.112:6824 remote=/68.48.126.51:19407]], peer=[Peer [DSA(099a 5af2 bdc7 1eb5 bbfb fa36 a90d 6573 3217 f0e7) @ 68.48.126.51:19407 (1/3)]], outbound=[false]] but sendingPacket == null! 03:07:09 Got a trailer chunk ahead of our time!: message starts 18187, stream currently at 0 from [EMAIL PROTECTED]: id=29855, keyOffset=18187, length=1399, cb=null on [EMAIL PROTECTED]: curPos=0, 0 chunks pending, wantChunk=true the one from 21:06 was reported before I updated. Just added it, because I never saw such a error in the logs before. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Update
thx ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Update
thx ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
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
