Because we can't burst we will never be so fast that you search for a big video file, download it at 600KB/sec+ and then watch it. HOWEVER, there are other measures of performance. Of the top 5 items on uservoice, one is a plea for more speed, one is more concerned with data persistence, one is concerned with the impact of Freenet on online gaming, and two are about the user interface. Rare torrents frequently don't have any seeders. Because Freenet has datastores, IMHO we have the potential to be fairly good at unpopular data. In the past I have managed to retrieve significant amounts of very old data. On the other hand, downloads frequently get stuck at 0% for very long periods, and many anecdotal reports point to a 2 week lifetime for newly inserted, unannounced content. But it appears that routing is essentially working, and we have a very high store size to bandwidth ratio, so I would expect that Freenet could work quite well. The following measures should help significantly: - DHKs: Triplicate the top block in a splitfile. Everything below it is redundant, and frequently an unpopular file will be stuck at 0% for a long time, but then make significant progress once the top block has been found. This will be implemented before 0.8.0 hopefully, and is easy. - Last segment problem in splitfiles: The last segment of a splitfile can be too small to offer good redundancy. We can solve this. This may or may not get done before 0.8.0, but it is also easy. - Bloom filter sharing: This will be a key feature in 0.9, and will take some time to implement. Whether it will work on opennet is an open question, hopefully there will be enough stability that it will work on *some* opennet peers. IMHO if it is reasonably widespread it will avoid relayed, load limited requests completely for very popular data (just get it from your [darknet] peers), drastically reduce the number of hops needed for most fetches, and greatly improve reachability for less popular content. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090423/3aaaf5d5/attachment.pgp>
