On Friday 16 May 2008 09:53, Jano wrote: > Ian Clarke wrote: > > > On Thu, May 15, 2008 at 3:28 PM, Michael Rogers > > <m.rogers at cs.ucl.ac.uk> wrote: > >>>> That would be a very valuable system, I just don't see what it's got to > >>>> do with Freenet. > >>> > >>> Ummm, the fact that it would be a routable small world darknet? > >> > >> That's an assumption, not a fact. As far as I know there's little reason > >> to assume that the contact graphs of clandestine political organisations > >> are routable small worlds, let alone to assume that the combined contact > >> graph of several diverse organisations is a routable small world. > > > > Well, I think they might be a routable small world, but even if they > > are it doesn't follow that this "sneakernet" functionality should be > > part of freenet. > > > > I've heard a few people refer to Freenet as "bloatware", and frankly, > > given that 10MB of the install consists of client apps that really > > don't need to be bundled with Freenet, I can see why. > > I disagree here. Freenet feels like bloatware because it has had[*] problems > with high CPU usage, disk trashing and munching memory like crazy. > > A big download and a couple of satellite apps don't cause a judgment of bloat > ware (at least not in the people I known). It is that your computer really > loses responsiveness when such a resource hungry java app is running in the > background. > > YMMV. > > [*] I ceased running freenet in my desktop over half a year a go, so this may > be inaccurate now.
It has improved somewhat, but the basic problem remains that the bigger the queue of uploads and downloads, the more memory Freenet wants to use ... and if it doesn't get what it wants, it tends to use 100% CPU and then crash. Also our bandwidth limiting isn't very accurate, and therefore can interfere with e.g. online gaming, and there's no obvious two-click way to throttle/disable it such as a systray icon. Here's what Victor Denisov's Russian friends said about Freenet (in the priorities thread). These are actual would-be-users who were put off by Freenet being bloatware: >|> 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? > >Well, memory usage was what finally turned them off, as far as I can >see. One of the people I've mentioned (a pretty experienced computer and >p2p user) had immediately and repeatedly crashed his node upon >discovering Thaw and Frost file sharing tools - he put a couple of >hundreds of large files there for both insertion and download, not >really understanding how Freenet handles this (on a side note, this is >something which is *really* unclear to most casual P2P users I've talked >to, especially those with Gnutella/eMule/Kazaa background). Naturally, >Freenet quickly ran out of memory, and simply wasn't recovering on its >own. We've finally been able to solve this problem by giving Java enough >memory to load the queue, then quickly removing files from it (there's >probably a better way, but I wasn't aware of it). > >In the second case, the machine on which we tried to install Freenet was >a little bit old (but nothing ancient - P4 2.4 GHz/1 Gb RAM), used as a >dedicated P2P machine by my other friend. Shortly after installing >Freenet, it became unresponsive - almost constant disk access, high CPU >usage, etc. After stopping Freenet, the load went down immediately. We >tried actually giving Freenet less than default memory (96 Mb, IIRC), >but it didn't really help. As you can see, what makes an application bloatware is: - Memory usage that depends on the number of files you queue, especially if there's a low default limit. - High CPU usage (especially if it's at high priority). Mostly nowadays this is caused by memory issues, although on AMD64 systems FEC may be a problem. - Constant heavy disk I/O. All of these are things we should address in 0.7.1. -------------- 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/20080516/514ccb60/attachment.pgp>
