PS: one thing that would help in the process is the average amount of files the system is storing and the average number of online nodes. There is no need to state anything about document content/nodes' geographical distribution, so I suppose this stuff can be published without any breach to individual privacy.
I don't think that the actual content of data (textual, multimedia or whatever else) can have any impact on energy consumption, so I guess we don't need any such figure. Pls correct me if I'm wrong. >From a CO2 saving POV download speed is not an issue, unless we say that a machine will stay UP just because of the dnload process. I can hardly imagine that happening, though. We all run dnloads in the background, while we do other things. What I see is more like a bandwidth/CPU sharing model, as in grid computing (like http://en.wikipedia.org/wiki/World_Community_Grid). Under this approach, the one and only key factor is whether freenet can easily adapt to changes in topology and use those resources that are present at the moment. I have no notion whatsoever of how topology is managed and of the implied security treats, so I will not make any (most probably) idiotic suggestion.As far as I can see, my freenet connections are constantly reorganizing themselves... so WHY an extended uptime is so much better? I tend to understand this impacts on my response time only. Kind of "the longer I've been online, the better my node could explore the network to find quick and stable connections". So if I have a reduced or occasional uptime all that happens is that I'm slower than I could be. Am I correct? And if I am correct... is there any way to benchmark "how much slower" it gets, and how quick it gets better? Berto 2009/4/3 B?rto ?d S?ra <berto.d.sera at gmail.com> > Hi Matthew! > > In sight of a number of things that are happening at international level I > think there is one issue that needs a close watch: CO2 saving. By having an > application to run over freenet we manage to do without big servers. This is > a huge saving, as huge backbone servers make a LOT of CO2. If you can > achieve a network that can make a lot of reduced uptime this means tons of > CO2 savings that can be certified and cashed, down to individual level. > Obviously enough, we will need some numbers (average emission of a home > machine vs emission of a public dedicated WWW server) to reach that stage, > hours of uptime and numbers of machines needed to reach the same effect, > etc. > > This has a deep impact on project financing. If you and I can prove we > saved 1 tonn of CO2 emission by using freenet we get cash for that, and al > the users get their share. Needless saying, money is often a much more > powerful engine than ideology, so this may dramatically impact on the > diffusion and employment of your technology. And if it saves CO2 emission, > the more it's used, the more all users (and you) cash in. > > Do we have any data that can serve for a start-up computation of the > savings implied? If we identify several critical factors I guess net stats > and basic benchmarks can be used to make a public chart of the ongoing > savings. This will need certification and once certified it will > automatically turn into cash. As a first term of comparison, one can say > that an average 24*7*52 www server (with some 430Wh consumption) makes > ~3,8MWh, for an equivalent discharge of 2,3 metric tons of CO2. The nodes > that run on freenet shall not be taken into account at all, as they have the > same emission that people reading WWW data would have anyway (IF AND ONLY IF > we require the same uptime for these nodes). > > Now let's have some basic math: the penalty a government pays for just ONE > such server is stated in 100 ? + inflation rate/missed ton of > CO2equivalents. So it's 230?+inflation per year, per server. > If we aim to take away 1 hundred servers we already deal with a financial > revenue of 23K? a year, plus inflation. Once clearly documented and > certified, this becomes a key factor for maketing freenet to lots of > countries who desperately need to buy CO2e certificates for the 40% of their > top industries, as it doesn't absolutely matter where they get their > certificates from. > > I'ma ware as anyone that loads of alternative models for CO2e savings have > already been produced. Yet they all imply some kind of serious HW change at > mass level: see http://www.netvoyager.co.uk/general/wtc.html Maybe a thin > client is the best thing on earth, yet reality is that we all have normal > PCs. If freenet can produce a way to use these PCs to produce CO2 savings > without requiring the users to spend any money, then it can be easily > marketed. > > Any data I can use to make some energy computations? I'm in the process of > applying for funding and I really need to support my claims. Privacy is > fantastic (and sure enough nobody needs to drop it because of this) but if > freenet can prove worth an investment from more than one point of view it > will be much simpler to keep things going. > > hmmmmmm you say freenet does not "burst". Can you elaborate in detail? This > may well mean that we can make lighter computation of consuption/efficiency, > since the consumption rate seems to be independent from what a user actually > does. > > Berto > > 2009/4/2 Matthew Toseland <toad at amphibian.dyndns.org> > >> Freenet can never compete on speed with traditional peer to peer, for >> several >> reasons, of which at least 1 is intractable: >> 1. Freenet assumes high uptime. This does not happen in practice, at least >> not >> for the mass market. To some degree we can resolve this with e.g. >> persistent >> requests in 0.10. >> 2. Freenet returns data via intermediaries, both on darknet and opennet. >> This >> is what makes our caching model work, and it's a good thing for security, >> however broadcasting a search (or using some more efficient form of >> lookup) >> and then having those nodes with the data contact you directly will always >> be >> faster, often much much faster. Caching may well obviate this advantage in >> practice, at least in the medium term. >> 3. Freenet has a relatively low peer count. Hence the maximum transfer is >> determined by the output bandwidths of the peers, which is low. Increasing >> the number of peers will increase various costs, especially if they are >> slow, >> and make it harder to see whether the network can sclae, otoh it would >> increase maximum download rates... >> 4. Freenet avoids ubernodes. Very fast nodes are seen as a threat, >> rightly, >> because over-reliance on them makes the network very vulnerable. >> Practically >> speaking they may be attacked, if this is common it again neutralises this >> advantage of "traditional" p2p. >> 5. FREENET DOESN'T BURST. >> >> The last is the fundamental, intractable issue IMHO. Freenet sends >> requests at >> a constant rate, and exchanges data between peers at a roughly constant >> rate. >> On something like Perfect Dark (which admittedly has much higher average >> upstream bandwidth and bigger stores), you start a request, and you get a >> huge great spike until the transfer is complete. It's similar on >> bittorrent, >> provided the file is popular. On Freenet, our load management is all >> designed >> to send requests constantly, and in practice, up to a certain level, it >> will >> use as much bandwidth as you allow it. We could introduce a monthly >> transfer >> limit as well as the upstream limit, but this would not help much, because >> bursting is inherently dangerous for Freenet's architecture. If you are >> Eve, >> and you see a big burst of traffic spreading out from Alice, with tons of >> traffic on the first hop, lots on the second, elevated levels on the >> third, >> you can guess that Alice is making a big request. But it's a lot worse >> than >> that: If you also own a node where the spike is perceptible, or can get >> one >> there before the spike ends, you can immediately identify what Alice is >> fetching! The more spiky the traffic, the more security is obliterated. >> And >> encrypted tunnels do not solve the problem, because they still have to >> carry >> the same data spike. Ultimately only CBR links solve the problem >> completely; >> what we have right now is hope that most of the network is busy enough to >> hide traffic flows, but this is the same assumption that many other >> systems >> rely on. But big spikes - which are necessary if the user wants to queue a >> large download and have it delivered at link speed - make it much worse. >> >> There are lots of ways we can improve Freenet's performance, and we will >> implement some of the more interesting ones in 0.9: For example, sharing >> Bloom filters of our datastore with our peers will gain us a lot, although >> to >> what degree it can work on opennet is an open question, and encrypted >> tunnels >> may eat up most of the hops we gain from bloom filters. And new load >> management will help too when we eventually get there. However, at least >> for >> popular data, we can never achieve the high, transient download rates that >> bursty filesharing networks can. How does that affect our target audience >> and >> our strategy for getting people to use Freenet in general? Does it affect >> it? >> >> _______________________________________________ >> Tech mailing list >> Tech at freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech >> > > > > -- > ============================== > Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole > les droits du peuple, l'insurrection est, pour le peuple et pour chaque > portion du peuple, le plus sacr? des droits et le plus indispensable des > devoirs. > -- ============================== Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole les droits du peuple, l'insurrection est, pour le peuple et pour chaque portion du peuple, le plus sacr? des droits et le plus indispensable des devoirs. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090403/d1403e0f/attachment.html>
