Comment 5 for bug 401094

Michael Terry wrote:
> I've looked into it before, but there were some problems with it. I
> believe they were largely UI-oriented (difficult to show what duplicity
> was doing, which file it was marshalling, etc).
>
> Now that duplicity tells us when it is uploading a chunk, I may be able
> to give meaningful progress indication again if this is enabled. I'll
> look at it.
>
> However, the non-use of --asynchronous-upload does not explain the max
> 300KB/s speed; at best it explains the 50% CPU, though even then, Ken,
> you say that the marshalling isn't threaded.
>
> So, maybe I don't understand all that asynchronous does, but I suspect
> it doesn't necessarily help here.

Depending on how fast the network is, duplicity will be able to overlap
its marshaling with the previous file being uploaded. We don't build up
a queue, so if it takes longer to marshal the files for the next volume,
say a bunch of small files, then you have dead time in the network.

As to CPU, IO does not use much, only the marshaling process and
encryption, and 50% sounds about right in bursts.

...Ken