Re: [PATCH] fetch-pack: grow stateless RPC windows exponentially

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 18, 2016, 19:31 UTC
Message-ID: <20160718193147.GC29326@google.com>
In-Reply-To: <CAGf8dgJVkkVwJ5aJCQBcYKw7F9g7u3pMsuJHedSGLG6PQk2Keg@mail.gmail.com>

Jonathan Tan wrote:

> On Mon, Jul 18, 2016 at 12:10 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

>> I'd understand if it were more like "aggressive exponential ->
>> conservative exponential" without linear phase when stateless_rpc is
>> in use, though.  I just do not quite understand the justification
>> behind the order of three phases introduced by this change.
>
> Adding conservative exponential phase after the aggressive exponential
> phase was the original intention, but the conservative exponential
> approach (e.g. n' = n * 11 / 10) is slower than the existing linear
> (n' = n + 1024) approach when n < 10240, so I added that intermediate
> phase to avoid a regression in the packet size growth.

You have full control of the growth function. So how about aggressive growth until 1024*10?

That is:

Current git:
  n < 1024: aggressive exponential
	16, 32, 64, 128, 256, 512, 1024
  1024 <= n: linear
	2048, 3072, 4096, 5120, ...

Initial proposal:
  n < 1024: aggressive exponential
	16, 32, 64, 128, 256, 512, 1024
  1024 <= n < 10240: linear
	2048, 307, 4096, 5120, ...
  10240 <= n: conservative exponential
	11264, 12390, ...

New proposal:
  n < 10240: aggressive exponential
	16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384
  10240 <= n: conservative exponential
	18022, 19824, ...

That way, on one hand it would still never use a smaller window than today and on the other hand the heuristic would be easier to understand (only decelarating, instead of decelarating and then accelerating again).

Thanks, Jonathan