On 03/12/15 07:20, Victor Denisov wrote: >> As a /user/, freenet is extraordinarily heavy for the computers I've >> used it on (some of them not that low spec). Disk trashing in some of >> them was so interfering with normal use to make it unbearable. > It's gotten from "computer is unusable when Freenet is running" to > "computer is barely usable when Freenet is running" (which absolutely > *is* an improvement, btw).
Umm... good? :| > However, Freenet is still extremely > IO-limited (to the point that I have to limit bandwidth to around > 200-300 KB/s, or the node is backed off almost 100% of the time) This is surprising. Are you sure it is actually I/O bound and not just having an impact on the rest of the system? Is there any way you could test this? We need to know whether it is actually disk limited or whether it is merely unfair on the rest of the system, since the fixes may be different. Backoff should not be related to I/O *at all*, if you mean the number of peers listed as "BACKED OFF" (or "BUSY"). Unless you mean something else? It is quite possible that there are multiple simultaneous problems. Is this all datastore, or do you have active uploads, active downloads? The client layer is responsible for a significant fraction of disk I/O nowadays, and uploads are much less efficient than downloads even after we got rid of db4o. Datastore reads are constant (but should actually be fairly infrequent), but datastore writes are periodic bursts, thanks to the caching layer. There are tunables you could play with - IIRC there is a buffer size config variable? Also, it's not actually reconstructing right now? If it is it would have much heavier disk access but there'd be a message about it. > - which > is something I don't get, as torrent clients on ARM-based NAS boxes > (arguably, about 10% of my desktop's computing power) have no issues > with sustaining 4 MB/s 100 GB+ torrents for hours, and it's basically > the same workload (small-block multithreaded random reads/writes), IO-wise. Right. We ought to be able to handle this. Although I believe BitTorrent uses bigger blocks, which might be a factor here - and hard to fix. > Regards, > Victor Denisov. > > P.S. I knew I've seen this discussion before, and that I've made the > same point about performance before, so this is what I've found - from > 2.5 years > https://emu.freenetproject.org/pipermail/devl/2013-July/037145.html. Yes, the pay-for-opennet thing, like many other ideas on Freenet, has been refined and discussed periodically over a period of years. This is normal, the details evolve and the context changes; many such ideas eventually get implemented. If they are posted on the mailing list then we have some hope of attributing them properly. Interestingly, MAST first came up on Frost, i.e. anonymously and without proper archives. And it caused no end of worry and disruption for people like me, in spite of turning out to be bogus. Psy-ops perhaps? Who knows. Re your old message, I agree that we will probably have growing darknet cells glued together by opennet for some while, at least if we keep the goal of a single coherent network. I do have ideas for improving performance, which I might get to over the coming year. I believe corporate leak hunters may have access to intelligence level resources, at least to the tools that the regular police have access to (one of the key resources of a good PI is a network of bent cops willing to do favours!). And we could run tunnels over darknet if people *really* don't trust their friends, although it would take quite a bit of additional research (PISCES is rather unclear on some key points); the price of making this fast would be less invisibility, but people like China and Iran can block Freenet even if it's pure darknet. I think sorting out system overhead issues is probably more important/urgent than general downloading performance though. Because it causes people to uninstall Freenet, or (occasionally) to run it with poor uptime.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
