[Box Backup] Upload rate limiting (was: Trac account request)

[Chris Wilson]

Hi Stewart,

On Wed, 12 Jan 2011, Stewart Adam wrote:
> On 2011/01/11 7:20 PM, Chris Wilson wrote:
>>  I've implemented a rate limiting option in trunk. Simply set
>>  MaxUploadRate = 8000 (bytes per second) or similar on the client (in
>>  bbackupd.conf) to use it. Please have a look and see if it meets your
>>  needs.
>
> This is great, many thanks Chris! After some brief testing it seems to 
> work very well and you are right - the CPU usage is very low (0.8% on my 
> machine).

Great, I'm happy that you like it and it works for you.

> I'm going to look into if we can make effectiveRateSoFar a time average 
> of the past few seconds instead of the totals though, as that way if the 
> link throughput changes (say another application finishes a transfer or 
> laptop changes locations) then the calculation for the current rate will 
> more accurately reflect the actual transfer rates.

OK, I was thinking that it would be more stable and accurate across the 
whole lifetime of the connection to use the total bytes transferred, but 
you're right that if some other application uses enough bandwidth that 
bbackupd falls behind, then it will exceed the specified rate to "catch 
up", which is probably not desirable.

> I don't think the SSL overhead is something to worry about... From 
> testing it seems that there's roughly 2KB difference per 50KB (ie 50KB/s 
> limit results in 52KB/s real world; 750KB/s limit results in ~775KB/s).

OK, good.

> Out of curiosity, do the trace messages accurately reflect when data is 
> being sent out by bbackupd?

Not quite. The buffering is on the read side, but reading out the 
encrypted block stream that will be broken down into chunks for 
transmission over the wire by Protocol and SSL.

You can put a breakpoint on RateLimitingStream::Read to see that it's 
called by Protocol::SendStream, which luckily tries to dispatch every 
block that it receives immediately over the wire (by calling 
SendStreamSendBlock), prefixed by a header byte. So more, smaller blocks 
means more header bytes, unfortunately.

The protocol is wrapped in SSL, and SSL may write as few or as many bytes 
as it feels like when more data is pumped into it. But I think it tries to 
send as much as possible, i.e. a whole number of encrypted blocks, where 
the block size is determined by the encryption algorithm but probably 16 
bytes if we're using AES. So I guess that less than 16 bytes would remain 
buffered in SSL after SendStreamSendBlock completes, and the rest has gone 
out to the OS at least, if not the wire.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <chris+sig at qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |