On Saturday 29 November 2008 13:25, Ian Clarke wrote: > Just received this, anyone have any thoughts? :-
There are three basic points here: 1. Freenet uses more resources than it needs to. Mostly in practice we waste CPU due to excessive garbage collection when we have lots of downloads queued, this will be resolved by the db4o branch; lots of optimisations have already been done, but more will be needed. 2. Freenet accesses the hard disk constantly, and does a number of other things that we simply can't get rid of. We need access to the datastore. On the db4o branch, we need access to the database as well, if we are doing any persistent downloads. Plus we do a load of crypto etc etc; there is a limit to how much we can optimise Freenet, especially for battery life. 3. Mobile nodes do not work well on Freenet. A laptop that actually uses its battery, as opposed to sitting on a desk pretending to be a desktop, will likely be offline most of the time. This causes severe problems. When it is online, it will likely be behind other people's NATs, which usually have either severe throttling or charge heavily per gigabyte transferred. This is also bad. There are things we can do about both of these problems, but low uptime in particular is a HARD PROBLEM. Especially on darknet: a darknet consisting of low-uptime nodes is likely to have severe problems, with only a fraction of the network online at a time. Whether this causes big problems for swapping is an open question, but it is clear that the nodes with the data and the nodes requesting the data will frequently not be online at the same time. We will need to deal with low uptime, but not in 0.8, maybe not even in 0.9. The real solution involves long-term requests, a variant on passive requests, where requests are stored on the network, making progress when possible, being rerouted when necessary, trickling back once found as the links come up and go down, somewhat like a Delay Tolerant Networking protocol but still Freenet-ish. My current guesstimate roadmap puts this at 0.10 ... it involves solving some hard problems (e.g. load management of persistent requests). And of course, what we can do about the connectivity issues is also severely limited - if a connection charges per gig, the user will turn Freenet off, or more likely uninstall it; if it doesn't, Freenet will be so severely throttled as to be non-functional, and probably will have serious NAT problems (symmetric firewalls, fast-changing IPs, etc). > > > ---------- Forwarded message ---------- > From: Andrew <...> > Date: Sat, Nov 29, 2008 at 5:33 AM > Subject: powertop/latencytop vs freenet > To: ian at freenetproject.org > > > Yo, > > I uninstalled Freenet from 40 laptops (we're a privacy company) > because they rake havoc on battery life. Fix it please, then we'll > re-install. > > Best, > > Andrew > > > -- > Ian Clarke > CEO, Uprizer Labs > Email: ian at uprizer.com > Ph: +1 512 422 3588 > Fax: +1 512 276 6674 > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20081129/d6e54e10/attachment.pgp>
