* Thomas Bruderer <bruthoma at student.ethz.ch> [2006-04-19 09:45:23]:
This one is more interresting :)) > > > My DSL node is only a leaf - node so I can't tell you much there. However I > had > problems with "backed off" nodes which are in fact idle. But I know this is > already known.. > And what's the reason of the backoff ? :) isn't it a high network latency ? try pinging a backed off peer. > > 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? > exactly thats the problem we face. My thought on this is, we have to increase > the windowsize faster. The problem on previous builds was that it was growing to fast. Toad has multiplied the insert speed changing the behaviour. >THe slowstart of TCP is too slow for this kind of > packets. Maybe we should increase windowsize in a fixed intervall, maybe > dependend on the own Speedlimit. (32KB blocks) with a speed of 32KB/s we > should > maybe increase the windowsize every second (so as I can fill my bandwith IF no > congestion is reported) then I will have to wait for quite some time because > the > time of packets in flight is really much bigger than in tcp, you know that. We use a mean time of acknowledged packets atm and one other thread was talking about using the root N square insteed. > > If we resize the window for example only every 2 seconds, and lets say we have > unlimited resource behind my small link but with very big latency (i.e longer > than my insert will take)(so we get no information back at all). I will waste > every second timeslot even if we get no single dropped packet... > > nextgens would like that, its the same algorithm just a bit fine tuned ;)
