Thomas Bruderer wrote: >> emphasis "using more bandwith of the overall network". The network is of >> course starved for bandwidth most of the time, due to asynhronous >> connections. > > Do we agree that most darknet nodes idle?
Not afaik. My node is always under-utilising its bandwidth limits, it seems to use in the range of 50-400Kbps (in both directions) all the time, but Ive set it for ~4Mbps. I think nodes on slower connections dont "idle" in this sense though. People with slower connections seem to complain about over-usage though. (I saw atleast a couple of these complaints on IRC). Anyone with a more "common" DSL or cable connection able to give their view of this? > Or do we atleast agree that most testnet nodes idle? Yes. > The testenviroment right now is quite perfect, the inserts should be fast > right > now. What I am saying is that if downloads are fast, inserts have to be as > fast, > because we don't use more bandwith per link. The asynchronous connections are > problem for all p2p protocols, they are not only a problem with uploads, they > limit the downloads aswell. Yes, inserts should be almost as fast as downloads on an idle testnet, as long as end-to-end latency is not too huge to affect speed. TCP has a max-window size which limits bandwidth according to latency, I'm not sure the current code has any max settings for windowsize though? If it doesn't, it should theoretically handle any latency with good throughput? I guess this would require the transfer to be long enough to let the window grow though. > For inserts the speed limit is the per link bandwith (well for downloads > aswell) > but I get told all the time it has something to do with number of hops, which > can't be true. Well, if end-to-end latency is allowed to limit bandwidth, which I don't know if it is, it is an issue. > We should check different strategies in testnet till inserts are fast at least > in testnet... I totally agree here. --- John B?ckstrand
