>>>> 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 ;) >> 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.
