Bazaar dirstate locking (was: lock_* API change)

Robert Collins robertc at robertcollins.net
Tue May 18 09:30:19 BST 2010


On Tue, May 18, 2010 at 7:14 PM, Eli Zaretskii <eliz at gnu.org> wrote:
> Can you be more specific, please?  fencepost.gnu.org is also > 1ms
> latency, and yet using bzr on it with savannah.gnu.org is lightning
> fast.  Also, does the latency matter more than bandwidth?

With SFTP/HTTP latency matters a great deal; there are (from memory)
an absolute minimum of 24 IO's to do an absolutely bare bones insert
into the DB and update a branch pointer. Probably many more in
practice due to index queries for related data checks. Upload
bandwidth will also matter too, particularly when a repack occurs as
part of a write (which happens every 10 insertions into a repository,
on average).

> IOW, where you expect the break-even point for these two parameters to
> be, in your experience and according to your knowledge?

They aren't pitched against each other so I'm not sure what you're
asking. On a VFS environment I'd certainly aim to decrease both as
much as possible (because repacks can be very large from time to
time).

>> Until its fixed, I *totally expect* operations to be slow and take
>> ages.
>
> Btw, what would you expect to be a reasonable time for "update" and
> "commit" with bzr+ssh, over a link with ~100ms latency and 3Mb
> bandwidth?  Someone said on the Emacs list not to expect any panacea
> from that, so I'm curious what do Bazaar developers think about that.

I'm in NZ, talking to the launchpad bzr server - 250ms away, and a
standard ADSL 1 link. I just did an update of the launchpad tree I
have here after some weeks without changing it; it downloaded 12MB of
data, in 12 minutes, which is pretty slow. (1MB/minute) There is
something wrong in the network stack here - I can generate that same
push /much/ faster than launchpad is - we had a bug report a while
back from someone that was seeing similar issues, but none of the devs
could reproduce. As I can, now, I'm going to look into it.

Anyhow, to answer your question; I'd expect something like the following:
1/2 sec to do ssh
3 or four roundtrips to find common ancestor
1 roundtrip + streaming - and we should be able to generate 3MB/sec -
to download the new data

For commit, all the really choppy work is done locally, so if your
network is symmetric, it should be able the same as pulling a single
revision.

-Rob



More information about the bazaar mailing list