During 24 hours of uptime with 30 gig of ds, 750 open connections, 40 megs
in the sendqueue and 200 threads my JVM didn't allocate more than 182MiB in
the web interface (eventhough the 'Maximum memory the JVM will allocate' was
something like 240MiB) and fred never actually used more than 160MiB as
Specifying
java -Xmx128Mb -cp freenet-e
results in
Maximum memory the JVM will allocate192 MiB
/N
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
Happens very seldom but can happen nevertheless. I have seen it in the past
too.
/N
Jul 11, 2003 6:56:51 AM (freenet.node.states.request.TransferReply,
QThread-7490, NORMAL): Failed to send data with CB 0x83 (CB_RECV_CONN_DIED),
for freenet.node.states.request.TransferReply:
key=fcf8c554ba13c3040
> Secondary reason is that based on observation, incoming bandwith tends
> to stabilize around the level outgoing bandwith is capped. Spikes are
> _very_ rare; of course when browsing/downloading the incoming bandwith
> goes up.
Well.. no. In my case incoming bandwidth seems to stabilize at about
I suggest we do not throttle incoming bandwith at all.
The main reason is that we do not throttle messages with trailing fields
differently from the ones that don't. For the end-user that means that
they cannot set separate limits for routing data as opposed to file
transfer. Most end users i
Toad ([EMAIL PROTECTED]) wrote:
> 57.6/33kbps (good modem) is 7.2kB/sec and 4.1kB/sec.
No it's not, because of the stop, start and parity bits. Each byte
that goes out over a modem takes *ten* bits (8 data bits, 1 start
bit, 1 stop bit at 8N1; or 7 data bits, 1 start bit, 1 stop bit and
1 parity
Interesting conversation on IIP (my side wasn't much interest):
I am just thinking of people who will install it and with the
default settings of 0 0 0 0 freenet consumes all bandwith (which
is like... duh) but most users will drop to a trans node
thinking it is better bec
On Fri, Jul 11, 2003 at 12:09:52AM +0200, Niklas Bergh wrote:
> Jul 10, 2003 5:31:38 PM (freenet.node.states.request.TransferReply,
> QThread-5104, NORMAL): Failed to send data with CB 0x83 (CB_RECV_CONN_DIED),
> for freenet.node.states.request.TransferReply:
> key=26240fada3ea073b64ae1bfeda20b7c16
In message <[EMAIL PROTECTED]>, Niklas Bergh
<[EMAIL PROTECTED]> writes
Did the data actually disappear from your disk?
In the sense that the native FS (Reiser) no longer had it (but had the
same numbers as the Environment page), yes. I haven't done any hardware
level checks on the disk, but I
Did the data actually disappear from your disk?
/N
- Original Message -
From: "Roger Hayter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 10, 2003 11:37 PM
Subject: Re: [freenet-dev] ds changes
> In message <[EMAIL PROTECTED]>, Ed Tomlinson
> <[EMAIL PROTECTED]> wri
Jul 10, 2003 5:31:38 PM (freenet.node.states.request.TransferReply,
QThread-5104, NORMAL): Failed to send data with CB 0x83 (CB_RECV_CONN_DIED),
for freenet.node.states.request.TransferReply:
key=26240fada3ea073b64ae1bfeda20b7c16d159530140302, hopsToLive=22,
id=6cd43dc2ee6cce32,[EMAIL PROTECTED]@10
In message <[EMAIL PROTECTED]>, Ed Tomlinson
<[EMAIL PROTECTED]> writes
Pascal,
How robust are your lastest ds changes? I just noticed my ds droppped
from 8G to 178M.
This could have happened anytime yesterday or today. Running unstable
from cvs.
Running the stable build snapshot before 500
> > if (!javaversion14orabovedetected)
> > {
> >
System.out.println(ELABORATE_USER_HELP_REGARDING_UPGRADE_TO_JAVA_VERSION_1_4
);
> > System.exit(1);
> > }
>
> IMHO better idea than checking the version number is checking features
> (e.g. if loading of NIO cla
>> if (!javaversion14orabovedetected)
>
>IMHO better idea than checking the version number is checking features
>(e.g. if loading of NIO classes creates ClassNotFoundExceptions...).
yes this is very true and it has been coded just like you suggested (from cvs@):
- tcpConnection.setI
"[EMAIL PROTECTED]" schrieb:
> public static void main (String[] args)
> {
> // stuff...
>
> // check java version
> if (!javaversion14orabovedetected)
> {
>
> System.out.println(ELABORATE_USER_HELP_REGARDING_UPGRADE_TO_JAVA_VERSION_1_4);
>
>> there have been many mails regarding problems with old java installations to
>> the support list, and all the answers were the same: "install java 1.4!"
>> maybe this could be automated when fred checks it for itself and
>> prompts the user where to find and maybe how to install a 1.4 jre.?
Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> there have been many mails regarding problems with old java installations to
> the support list, and all the answers were the same: "install java 1.4!"
> maybe this could be automated when fred checks it for itself and
> prompts the user where to
>maybe it would be possible to add a check for the current java version in the java
>code on fred startup, prompting a fat message, that the installed java version is not
>1.4.x, which is necessary to run the freenet
>daemon, along with some urls where to get a 1.4 java installation, e.g. sun or
maybe it would be possible to add a check for the current java version in the java
code on fred startup, prompting a fat message, that the installed java version is not
1.4.x, which is necessary to run the freenet
daemon, along with some urls where to get a 1.4 java installation, e.g. sun or ibm
On Thu, Jul 10, 2003 at 09:27:26AM -0700, [EMAIL PROTECTED] wrote:
>
> > If they can contact you, they can bust you. Or they can bust the relay.
>
> > Or the webmail provider. End of line!
>
> One often useful mechanism for scenarios like this - ARK. When relays
> get busted, connect to a new o
I've reformatted the FCP document, and still have work to do as far as
adding newer commands and more formatting. Hopefully this will suffice for
now.
http://freenetproject.org/index.php?page=docs
--
Jay Oliveri "In the land of the blind,
GnuPG ID: 0x5AA5DD54
probably the best/fastest thing to do in the short term is to just drop any
query packets when the length of the queue is more than 5 minutes or
90-something percent of that.
if we close the connection, the other node will try to renegotiate - more cpu,
more bandwith. If we try to QR, we need t
> If they can contact you, they can bust you. Or they can bust the relay.
> Or the webmail provider. End of line!
One often useful mechanism for scenarios like this - ARK. When relays
get busted, connect to a new one and up your ARK. Also, while The Freenet
Project, Inc. would never be involve
now y'all are making me feel even more stupid for forgetting my Trent
password to identify my self as jrandom, which is why I switched to jrand0m
on iip. oh well
anyway, my 3+ page reply to Toad is up at [EMAIL PROTECTED]/jrandom/18//
I think it addresses what Ian says too, though I'd suggest t
Toad wrote:
Rejecting queries is EVIL. SOLVE the problem.
You're going to buy everyone insanely fast links to the internet?
Yay!
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
On Wed, Jul 09, 2003 at 11:12:38PM -0500, Tom Kaitchuck wrote:
> On Wednesday 09 July 2003 08:05 pm, Toad wrote:
> > Yes. The thread PIDs are listed (in hex) as tid=0xsomehexnumber in the
> > stack dump you get by kill -QUIT'ing your node (the top java process
> > from pstree, or `cat freenet.pid`)
> We cannot make freenet perfect before we can make it work. Just because
> a few pages work does not mean that Freenet is actually routing
> efficiently. Freenet is already meeting the needs of the censored and
> the subversives in China, Europe and around the world. Steganographic
> protocols wit
Hrm, I've never used that updater. I read update.sh, found out what it did, and I handpick which build I want or which source. Actually, this might be unfeasible, but add in a selection: Which kind of node do you want? Unstable, Stable, or Experimental, and you get the latest build or build one of
I agree with almost all of what Toad says, if we wait until Freenet has
theoretically perfect security, then we may as well give up now as we
will never reach that (even Chord can be attacked with traffic
analysis).
Right now Chinese dissidents are circumventing censorship by sending
lists of HT
Currently the "Update Snapshot" link on Windows doesn't keep backups -
although it does detect errors during the install and never overwrites any
files unless ALL files download correctly (files are downloaded to temp
and then copied).
But I like the idea of keeping an archive of configurations - m
Stable build 5008 is now available; use the updater or get it from
http://freenetproject.org/snapshots/ .
Major changes:
* Changed the datastructures in the datastore (NativeFSDirectory, we now
use a SkiplistWithHashMap rather than just a Hashtable), this will
speed up and reduce the memory co
On Wednesday 09 July 2003 08:05 pm, Toad wrote:
> Yes. The thread PIDs are listed (in hex) as tid=0xsomehexnumber in the
> stack dump you get by kill -QUIT'ing your node (the top java process
> from pstree, or `cat freenet.pid`).
OK, There were two offending threads. The lesser of the two was the
On Mon, 16 Jun 2003, Toad wrote:
> Default ulimit -n on my (debian) system is 1024. I have no changes in
> /etc/security/limits.conf. I hear that BSD has an actual fixed size
> table, but I assumed linux was less braindead. It is. But it imposes a
> default of 1024 anyway. Wonderful. Is this the s
Recent jrand0m flog:
On a less positive note, I saw greycat's flog today and, well, I've just
got to respond to some of the things he quoted. (no, I know I don't have
to, and should probably just shut my mouth, but with people quoting me
quoting toad on devl and #freenet-opn, well, ya know).
34 matches
Mail list logo
