Déjà Dup

Bug #401094
Comment #8

Comment 8 for bug 401094

Revision history for this message

emilio (emiliomaggio) wrote on 2009-07-20: Re: [Bug 401094] Re: Slow backup speed

It is max speed. It never goes over 300KB

On Mon, Jul 20, 2009 at 2:54 PM, Michael
Terry<email address hidden> wrote:
>> 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.
>
> Right, but he said it maxes out at 300. Asynchronous shouldn't have
> anything to do with max speed, but rather throughput. emilio, can you
> clarify if the problem is max speed or throughput?
>
>> As to CPU, IO does not use much, only the marshaling process and
>> encryption, and 50% sounds about right in bursts.
>
> emilio has a dual-core, so 50% is really 100% of one core. I meant that
> since the marshaling isn't threaded, even if asynchronous were turned
> on, we'd still only use 100% of one core. (Though we'd be using it more
> often -- i.e. even when uploading something. Another max vs. throughput
> issue)
>
> So again, unless emilo can clarify about the max/throughput question, I
> don't think asynchronous is the answer here. We still want both network
> and CPU maxes to be higher, even though asynchronous would help with
> overall throughput.
>
> --
> Slow backup speed
> https://bugs.launchpad.net/bugs/401094
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Déjà Dup: New
> Status in duplicity - Bandwidth Efficient Encrypted Backup: Confirmed
>
> Bug description:
> I am backing up from a laptop to an external NAS via WiFi. And I am running:
> deja-dup 10.1-0jaunty1
> duplicity 0.6.02-0jaunty1
>
> I have tested the file writing speed of the NAS and it is of about 2MB/s. However when backing up with deja-dup the speed tops at about 300KB/s.
>
> Interesting is also the fact that the backup on my dual core machine uses only 50% of the available computational power spread over the two cores.
>
> Any idea on where the bottleneck might be?
>

It is max speed. It never goes over 300KB

On Mon, Jul 20, 2009 at 2:54 PM, Michael
Terry<michael.terry@canonical.com> wrote:
>> 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.
>
> Right, but he said it maxes out at 300.  Asynchronous shouldn't have
> anything to do with max speed, but rather throughput.  emilio, can you
> clarify if the problem is max speed or throughput?
>
>> As to CPU, IO does not use much, only the marshaling process and
>> encryption, and 50% sounds about right in bursts.
>
> emilio has a dual-core, so 50% is really 100% of one core.  I meant that
> since the marshaling isn't threaded, even if asynchronous were turned
> on, we'd still only use 100% of one core.  (Though we'd be using it more
> often -- i.e. even when uploading something.  Another max vs. throughput
> issue)
>
> So again, unless emilo can clarify about the max/throughput question, I
> don't think asynchronous is the answer here.  We still want both network
> and CPU maxes to be higher, even though asynchronous would help with
> overall throughput.
>
> --
> Slow backup speed
> https://bugs.launchpad.net/bugs/401094
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Déjà Dup: New
> Status in duplicity - Bandwidth Efficient Encrypted Backup: Confirmed
>
> Bug description:
> I am backing up from a laptop to an external NAS via WiFi. And I am running:
> deja-dup        10.1-0jaunty1
> duplicity       0.6.02-0jaunty1
>
> I have tested the file writing speed of the NAS and it is of about 2MB/s. However when backing up with deja-dup the speed tops at about 300KB/s.
>
> Interesting is also the fact that the backup on my dual core machine uses only 50% of the available computational power spread over the two cores.
>
> Any idea on where the bottleneck might be?
>