That's certainly much better. More could be done but perhaps this
specific bug should be closed, and we can identify some others to do
next.
A few questions:
* how close is 170kB/s to saturating your local link?
* are there any obviously inefficient hpss calls (there probably are
too many graph calls, and that would be clearly a different bug)
* is 11.5MB a reasonable size for the amount of actual change in that
repo from r10721 to r10876?
> 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).
Taking 28.7s before starting to send bulk data is a bit high.
>
> I think that's probably good enough to consider this specific report
> closed. What do other people think?
I think so. I don't like having very broad bugs open that are going
to stay open until we reach some kind of asymptotically good
performance. On the other hand it is nice to have a few clear leading
bugs to point users and developers to.
That's certainly much better. More could be done but perhaps this
specific bug should be closed, and we can identify some others to do
next.
A few questions:
* how close is 170kB/s to saturating your local link?
* are there any obviously inefficient hpss calls (there probably are
too many graph calls, and that would be clearly a different bug)
* is 11.5MB a reasonable size for the amount of actual change in that
repo from r10721 to r10876?
> 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).
Taking 28.7s before starting to send bulk data is a bit high.
>
> I think that's probably good enough to consider this specific report
> closed. What do other people think?
I think so. I don't like having very broad bugs open that are going
to stay open until we reach some kind of asymptotically good
performance. On the other hand it is nice to have a few clear leading
bugs to point users and developers to.
--
Martin