On Monday 12 May 2008 20:19, Victor Denisov wrote: > | On Friday 09 May 2008 07:27, Victor Denisov wrote: > |> | Automatic bandwidth calibration. Other p2p apps have this, we should > |> have it. > |> > |> Good idea. Also, we should definitely look into better utilizing > |> available bandwidth. Freenet's the only p2p app which consistently > |> underutilizes my upload limit (~ 2 Mbit/s out of 8 Mbit/s of link > |> capacity). I understand that we don't want to create supernodes, but > |> come on, 2 Mbit/s is *nothing* these days. > | > | IMHO automatic bandwidth calibration will help a lot with this. Beyond > that > | we're looking at token passing, which may be too big for 0.7.1. > > Excerpt from my current node stats: > > networkSizeEstimateSession: 6039 nodes > nodeUptime: 2d1h > pInstantReject: 0,0% > uptimeAverage: 100,0% > Peer statistics > ~ * Connected: 17 > ~ * Backed off: 3 > ~ * Seeding for: 111 > Input Rate: 17.6 KiB/sec (of 300 KiB) > Output Rate: 15.9 KiB/sec (of 200 KiB) > Total Input: 4.83 GiB (28.3 KiB/sec) > Total Output: 5.66 GiB (33.2 KiB/sec) > > Used Java memory: 122 MiB > Allocated Java memory: 127 MiB > Maximum Java memory: 284 MiB > Running threads: 152/700 > > So, basically, network had grown about 3x after 0.7 release.
Great! > My node has > been up for 2 days, and is pretty well established in the network. It's > not overloaded (CPU usage is ~ 5-10%). Yet it doesn't use more than > about 15% of the allowed bandwidth, on average. Automatic bandwidth > calibration won't help - I've allowed Freenet to use much less that my > uplink allows to. I disagree. Your actual bandwidth usage is determined by how many requests the other nodes send you. This is largely determined by the *average bandwidth limit* across the whole network. If we increase the average bandwidth limit, we increase the traffic on your node. > > It could be related to the fact that I've only been able to dedicate > about 2 Gb for my store, but I doubt it. That certainly won't help. > > | Agreed, memory usage is a usability issue: the user shouldn't have to > care > | about it. > > Great that we agree on this one. I've been unsuccessful in bringing at > least two of my friends to Freenet because they were running into > memory-related problems, one of them going as far as calling Freenet > "that damn bloatware" (well, actual wording also included a couple of > pretty strong Russian expletives :-((((). Hehe. Consensus is good. They are specifically talking about memory/CPU here? Or bandwidth usage, total transfer in a month, etc etc? > > |> Shouldn't we consider auto-updating bundled applications as well? Or > |> perhaps providing an auto-update API for use by third-party apps? Just a > |> thought. > | > | Maybe, that would be harder though. I would be happy to discuss it > with their > | authors. > > Well, it seems more or less straightforward from the outside: handle > additional update URLs and a set of (revocable?) public keys + expose > the API over FCP. Am I missing something important? Yeah but we'd have to unpack, support post-unpack scripts, etc etc ... really we'd want the apps to provide their own unpacker and just feed them a single file for them to do what they want with? > > Regards, > Victor Denisov. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/f2126e45/attachment.pgp>
