Re: [freenet-dev] Re: Inserts can be as fast as downloads

Top Page
Delete this message
Reply to this message
Author: NextGen$
Date:  
To: Discussion of development issues
Subject: Re: [freenet-dev] Re: Inserts can be as fast as downloads
* Thomas Bruderer <bruthoma@???> [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 ;)