Re: [freenet-dev] Post-0.7.0 priorities

Top Page
Author: Matthew Toseland
Date:  
To: devl
Subject: Re: [freenet-dev] Post-0.7.0 priorities
Delete this message
Reply to this message
gpg: Signature made Tue May 13 17:53:51 2008 UTC using DSA key ID E43DA450
gpg: Good signature from "Matthew John Toseland <toad@amphibian.dyndns.org>"
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.