Ed Tomlinson wrote: > eg. if we are basing send rates on average recieve rates from nodes > with much less output bw than input we may be wasting lots of bw...
I don't think our sending rate to peer X is based on peer X's sending rate to us. As far as I know, the bandwidth estimation code decides how many requests to accept in total by measuring the amount of outgoing bandwidth used per incoming request, including requests that are answered locally. That means if we have spare input bandwidth *and* we can answer most requests locally, we'll use the spare input bandwidth. But if we have to forward the majority of requests, we'll be limited by our output bandwidth and probably won't be able to make full use of our input bandwidth. But I don't really see a way out of that situation - asymmetric connections just weren't designed with p2p in mind. > What would happen if we only sent to one peer at a time (queueing > other messages) or what would happen if we used peek recieve > rates instead of average? I don't see how sending to one peer at a time would help - we're more likely to be limited by our output bandwidth than their input bandwidth. Not quite sure what you're suggesting about measuring peak receive rates - we're not trying to measure the peer's "real" bandwidth, we're trying to measure how many requests it can handle in the long term. The low-level congestion control code should take care of short-term peaks and troughs in the available bandwidth. Cheers, Michael
