On Tuesday 06 January 2009 15:02, Florent Daigniere wrote: > >>>> They are concerned by their bandwidth not being sucked up? Fine! Turn > >>>> them into seednodes, create a distribution toadlet, create a special > >>>> mode where they would only serve UoMs (and would be registered by > >>>> seednodes as such)... They are plenty of solutions to max out their > >>>> upload bandwidth usage if that's what they want their node to do! > >>> Don't you think that more opennet peers for fast nodes, and maybe fewer > > for > >>> really slow nodes, would improve performance for everyone? > >> Fewer peers for slow nodes would help in terms of latency; I'm not sure > >> about more for fast nodes. > > > > Fewer peers for slow nodes would improve the average bandwidth per peer, and > > therefore enable faster nodes to handle more requests. More peers for fast > > nodes would enable faster nodes to handle more requests directly, since right > > now they are bottlenecked by the average. The average bandwidth per peer > > would rise and everyone benefits. The only problem is over-dependance on fast > > nodes, which is why we would impose an upper bound on the maximum number of > > opennet peers. Probe requests consistently show the network is around 1000 > > live nodes at any time, so IMHO the upper limit should be no more than 50. > >>> Given that our > >>> current load management limits a node's performance by the number of its > >>> peers multiplied by the average bandwidth per peer on the network? > >>> > >> IMHO it's a lot more trickier to do than to bump one constant! Anyway, > >> that's not the point: the point is you're about to merge a new > >> client-layer AND considering to change yetAnotherParameter which might > >> have network wide effects in the meantime. All of that in a short > >> timeframe and right before a release (unless I missed something the > >> release is still planned for "soon")! > > > > What does the new client layer have to do with anything? Oh, you think it will > > have negative network effects because people will not keep their nodes > > running for so long ... whereas I think it will have positive network effects > > because people's nodes will not be overloaded for hours after startup ... > >> It's bad practice. > >> > > If you change everything at the same time we won't ever know which > theory is the right one ;)
This may be a fair point, but given that it will likely take some time for any effect to manifest itself clearly, what can we do? > > >> Suppose things get screwed up (or drastically improve): how will you say > >> which of your changes have caused it? It's not like the theoreticians > >> knew for sure what the effects are going to be: they said "it shouldn't > >> break things" ... not that it won't or can't. > > > > Right now I'm working on the history cloaking code, necessary because we got > > rid of firefox. > > I'm not convinced it's necessary... but well :| > > > Hopefully after that I can do some work on the client layer. > > If this (scaling peers with bandwidth) was agreed, it could be implemented > > immediately; it's likely it'll be at least another month before the new > > client layer goes in. > > Huh; I thought the merge was imminent. It is. :| Apart from distractions such as history cloaking, there are several components not finished yet, and large inserts still OOM. - Finish and test dead data structure removal. - Implement dead buckets removal. - Major debugging on (or elimination of) the blob buckets code. - Prefer requests on recently successful high-level requests. - Possibly segmentise inserts. Certainly debug OOMs which are still happening on large inserts. :| -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090106/62567c39/attachment.pgp>
