Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


On Mon, Oct 22, 2018 at 04:33:21PM +0200, Guilhem Moulin wrote:
On Mon, 22 Oct 2018 at 11:51:35 +0200, Lionel Elie Mamane wrote:
On Wed, Oct 17, 2018 at 09:03:45PM +0200, Guilhem Moulin wrote:

SSH is only used for transport, a git processed is exec()'ed on the
remote just like for git-daemon(1), so the only overhead is
crypto-related.  The handshake is a one-off thing, thus negligible
when you're transferring a large amount of data at once; (...) As
for symmetric crypto overhead, (...) the overhead should be
negligible.

All I know is that about 1/2/3 years ago ('t was I think in some
coworking space in Brussels, probably a hackfest) I showed Michael
Meeks how to have a separate "push" url (with ssh: protocol) and
"pull" url (with git: protocol) and he was very happy at the
speed-up.

Might be orthogonal to the git:// vs. https:// vs. ssh://
discussion.  Gerrit uses JGit as Git implementation, while
git-daemon(1) spawns “normal” (C-based) git-upload-pack(1)
processes.

For us developers of LibreOffice, and thus consumers of the Gerrit /
Git service of freedesktop.org and TDF, whether the difference comes
from the protocol itself or a different git implementation on the
server to serve the different protocols is intellectually interesting
(thanks for that!), but materially inconsequential: if using git: will
be faster, we will use git:.

I recall Norbert and I sat down during FOSDEM 2017 to solve perf
issues with our JGit deployment.  Perhaps you configured your
‘remote.<name>.pushurl’ at the same time :-)

I can easily believe it was earlier.

Anyway, it's easy enough to benchmark no-op `git fetch` on core.  master
is currently at c99732d59bc6, and I'm fetching from the same datacenter
to avoid metrics being polluted with network hiccups.

Yes, but no. You also test in an environment where a network RTT is
probably about one fifth to one third of a millisecond, and bandwidth
at least 100Mbps if not 1000Mbps? In that case, everything will be
fast. Time difference will be lost in noise. The interesting cases
will be:

1) Someone's out in the woods home DSL line in the woods; fiber hasn't
   come to that village yet, or has come to the town but not that
   particular street. RTT time about 50ms; bandwidth about 20 Mbps
   down (or less), much less up.

2) Case 1 added "on the other side of the world" (South-east asia?
   South America? New Zealand?), you can easily get RTT times of about
   300ms. Even if you are in a ultra-fast network (like university
   network). It is the other side of the world.

3) A coworking space that has good-for-typical-use connection, but
   then TDF does a hackfest there and a bunch of geeks (us) overflow
   the connection.

4) I'm at a conference, half listening to the presentation, half
   hacking on LibreOffice. The conference WiFi is overrun by everyone
   doing the same, people's laptops and pocket computers
   ("smartphones") automatically downloading updates (technical and
   social ones...), etc. How usable will it be? E.g. CCC (the Chaos
   Communication Congress) was known for having a totally overwhelmed
   WiFi; every year a new vendor would "gift" their better solution
   and this year the wireless network would actually be good! But
   every year it wasn't. (Has it actually improved in the last years
   that I didn't go?)

Are these protocols (or the *implementations* of these protocols) more
sensitive to RTT than another? They do more roundtrips? Or not?

-- 
Lionel

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.