From: Jonathan Nieder <jrnieder@gmail.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH] fetch-pack: grow stateless RPC windows exponentially
Date: Mon, 18 Jul 2016 12:31:47 -0700 [thread overview]
Message-ID: <20160718193147.GC29326@google.com> (raw)
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:
>> 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
next prev parent reply other threads:[~2016-07-18 19:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 18:36 [PATCH] fetch-pack: grow stateless RPC windows exponentially Jonathan Tan
2016-07-18 18:55 ` Jonathan Nieder
2016-07-18 19:10 ` Junio C Hamano
2016-07-18 19:16 ` Jonathan Tan
2016-07-18 19:31 ` Jonathan Nieder [this message]
2016-07-18 20:00 ` Junio C Hamano
2016-07-18 21:05 ` Jonathan Tan
2016-07-18 21:36 ` Junio C Hamano
2016-07-18 22:21 ` [PATCH v2] " Jonathan Tan
2016-07-18 22:40 ` Jonathan Nieder
2016-07-19 16:46 ` Stefan Beller
2016-07-19 19:03 ` Jonathan Tan
2016-07-19 19:17 ` Stefan Beller
2016-07-19 19:23 ` Junio C Hamano
2016-07-19 19:53 ` Jonathan Nieder
2016-07-19 20:20 ` Junio C Hamano
2016-07-20 13:40 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160718193147.GC29326@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).