We haven't reproduced this slow behavior, but perhaps the situation is not exactly the same. I have a few ideas that just may help and after that, if we have no more data, we'll throw it back to Incomplete.
Here are the specific ideas:
* remove undue buffering of outgoing hpss data <https://bugs.edge.launchpad.net/bzr/+bug/590638>
* make it possible to see the server debug log on the client <https://bugs.launchpad.net/bzr/+bug/590633>
* use a socketpair to talk to the ssh client process <https://bugs.launchpad.net/bzr/+bug/590637>
* run tcptrace <http://www.tcptrace.org/> to see if there is bad tcp-level behaviour
* log server cpu time per request
* print more stats at the end of the command including cpu seconds, total rpcs, and number of large/small network reads
We haven't reproduced this slow behavior, but perhaps the situation is not exactly the same. I have a few ideas that just may help and after that, if we have no more data, we'll throw it back to Incomplete.
Here are the specific ideas:
* remove undue buffering of outgoing hpss data <https:/ /bugs.edge. launchpad. net/bzr/ +bug/590638>
* make it possible to see the server debug log on the client <https:/ /bugs.launchpad .net/bzr/ +bug/590633>
* use a socketpair to talk to the ssh client process <https:/ /bugs.launchpad .net/bzr/ +bug/590637>
* run tcptrace <http:// www.tcptrace. org/> to see if there is bad tcp-level behaviour
* log server cpu time per request
* print more stats at the end of the command including cpu seconds, total rpcs, and number of large/small network reads