> So I propose leaving this bug In Progress until Launchpad upgrades their bzr server to 2.2, and then re-evaluating where we are at.
Well, 'bzr ping lp:bzr' reports that LP is running 2.2.0, so I tried the situation in the bug description: pulling r10876 of bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ into a (tree-less) branch of r10721. I did this from my laptop here in Sydney, so other side of the world to data centre.
So it's apparently much better now, so that's good! There's more going on here, though: that kB/s figure is perhaps misleadingly pessimistic. It divides the total kB transferred over the life of the process, when (arguably) a more helpful value would be over the active lifetime of the connection. i.e. from connection created to last bytes sent or received. This means the kB/s figure includes e.g. tree building time after the network chatter is (hopefully...) finished. So take care when interpreting that number.
Looking closer at the -Dhpss logging: the get_stream request was sent at 28.7s and the response was finished some time before 92.9s, and the total bytes sent in that one response was 10992877 (combined *.pack and *.?ix files on disk after the transfer are 9.7M, FWIW), so that's ~170kB/s for the stream itself. The original report was 21K/s (and nearly 13 minutes, rather than nearly 2).
I think that's probably good enough to consider this specific report closed. What do other people think?
> So I propose leaving this bug In Progress until Launchpad upgrades their bzr server to 2.2, and then re-evaluating where we are at.
Well, 'bzr ping lp:bzr' reports that LP is running 2.2.0, so I tried the situation in the bug description: pulling r10876 of bzr+ssh: //bazaar. launchpad. net/~launchpad- pqm/launchpad/ devel/ into a (tree-less) branch of r10721. I did this from my laptop here in Sydney, so other side of the world to data centre.
Result: Transferred: 11582kB (114.0kB/s r:11397kB w:185kB)
So it's apparently much better now, so that's good! There's more going on here, though: that kB/s figure is perhaps misleadingly pessimistic. It divides the total kB transferred over the life of the process, when (arguably) a more helpful value would be over the active lifetime of the connection. i.e. from connection created to last bytes sent or received. This means the kB/s figure includes e.g. tree building time after the network chatter is (hopefully...) finished. So take care when interpreting that number.
Looking closer at the -Dhpss logging: the get_stream request was sent at 28.7s and the response was finished some time before 92.9s, and the total bytes sent in that one response was 10992877 (combined *.pack and *.?ix files on disk after the transfer are 9.7M, FWIW), so that's ~170kB/s for the stream itself. The original report was 21K/s (and nearly 13 minutes, rather than nearly 2).
I think that's probably good enough to consider this specific report closed. What do other people think?