On Friday 11 July 2008 01:13, Daniel Cheng wrote: > On Thu, Jul 10, 2008 at 11:55 PM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > On Thursday 10 July 2008 10:44, Florent Daigni?re wrote: > >> * Matthew Toseland <toad at amphibian.dyndns.org> [2008-07-07 12:17:33]: > >> > >> > 3. Eliminate all checkboxes in the installer, move to the wizard, and > >> > create an advanced options button in the installer. (Toad) > >> > > >> > This would streamline installation significantly: Paranoid users could > >> > click a box to turn UPnP etc on/off, everyone else doesn't need to worry > >> > about it. > >> > > >> > >> Heh, what's the story about the installer and the checkboxes? > >> Good to know that you have debated that... and reached some kind of > >> agreement; I wasn't even aware that those checkboxes were a problem! > > > > We did debate it (briefly) at the summit. Ian (was it Ian?) was of the view > > that there are still too many steps involved in the installation process and > > this is confusing new users. > >> > >> That said I'm more than happy to hand over the maintainance of the > >> installer :p > > > > I'll bug you if I don't understand something. Which is most of the installer > > still. :) > >> > >> > 5. THROTTLE EVERYTHING !! (Toad) > >> > > >> > Not all traffic is throttled at the moment. We should subject all > >> > traffic, not only data transfer packets, to both congestion control and > >> > bandwidth limiting. This is related to the low-level streams proposal, > >> > but can be done without it, and should be easier. This is especially > >> > problematic for online gaming. See bug 2312. Note that a lot of Freenet > >> > runs on altruism, thus it is *essential* that it not severely disrupt > >> > a user's internet connection! > >> > >> I think that this one is important. > > > > Agreed. > >> > >> > 7. Automatic bandwidth limit calibration. (Toad) > >> > > >> > Several other p2p apps implement this, we should too. Bandwidth is *the* > >> > scarce resource most of the time, we want to use as much of it as we can > >> > without significantly slowing down the user's internet connection (see > >> > above). > >> > >> I don't think that such a thing can reliably work. It might work in 80% > >> of the cases but will badly screw up in others. > > > > It works for other p2p's. What specifically is the problem for Freenet? Small > > number of connections? > > Freenet is a bit more CPU intensive.
True .. especially if you have lots of requests queued. > When I increase the bandwidth limit here, it cause high backoff and > result in much poor performance. > (ya, I know I should upgrade the computer..) Interesting. The background CPU load from just running a node should be pretty low even on oldish hardware, unless the bandwidth is huge... what sort of hardware? What sort of bandwidth? Queued requests etc? (Note that queued requests will go faster if you give it more bandwidth, so that might also be an issue...) > > Never mention it does _not_ work that well for other p2p. Asking people to set bandwidth limits manually works better? How many azureus users even know what their upstream bandwidth is? Granted we may have a slightly geekier crowd... but even those who do know may not bother to change it. -------------- 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/20080711/785d200b/attachment.pgp>
