> > Well, I'm having concurrent backups, but they use different
> TCP ports,
> > thus I can "--sport 8873" and "--sport 8874" and so on for
> my clients.
>
> If you get this working, let us know how far off it is from
> the values shown for duration and transfer rate (and a 10-25%
> allowanc
Boniforti Flavio wrote:
>> Depending on whether you want to entertain bored users, bill
>> your clients for bandwidth, or conduct scientific
>> measurements, the answers are likely to be vastly different.
>
> I need to give my customers statistics about how much data has been
> transferred each
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Boniforti Flavio wrote:
> Hallo Holger,
>
>>> I need to give my customers statistics about how much data has been
>>> transferred each month, which means summing up day-by-day the
>>> transferred amount of data.
>> so it's the "entertain bored users
Hallo Holger,
> > I need to give my customers statistics about how much data has been
> > transferred each month, which means summing up day-by-day the
> > transferred amount of data.
>
> so it's the "entertain bored users" case :-). Your definition
> leaves room for interpretation. For instan
Hi,
Boniforti Flavio wrote on 2009-05-19 08:53:31 +0200 [RE: [BackupPC-users]
[SUGGESTION] "Duration/mins" not in decimal format]:
> > Depending on whether you want to entertain bored users, bill
> > your clients for bandwidth, or conduct scientific
> > measurement
> Depending on whether you want to entertain bored users, bill
> your clients for bandwidth, or conduct scientific
> measurements, the answers are likely to be vastly different.
I need to give my customers statistics about how much data has been
transferred each month, which means summing up da
Hi,
Boniforti Flavio wrote on 2009-05-18 22:14:50 +0200 [Re: [BackupPC-users]
[SUGGESTION] "Duration/mins" not in decimal format]:
> Il 18.05.09 17:34, "Adam Goryachev" ha
> scritto:
> [...]
the question I believe should have been asked long ago is: What proble
Boniforti Flavio wrote:
>
>
> Il 18.05.09 18:14, "Les Mikesell" ha scritto:
>
>> In all cases, this would be skewed if you add the '-C' (compression)
>> option to the ssh command since that would happen before backuppc sees
>> the data.
>
> And that's my case :-/
> Do you also think that the b
Il 18.05.09 17:34, "Adam Goryachev" ha
scritto:
> So all of these are estimations, and whether backuppc can internally
> even know what the correct settings are/should be, is possibly (probably
> as I think about it) impossible.
You are quite right... I didn't want to put that stuff in our th
Il 18.05.09 18:14, "Les Mikesell" ha scritto:
> In all cases, this would be skewed if you add the '-C' (compression)
> option to the ssh command since that would happen before backuppc sees
> the data.
And that's my case :-/
Do you also think that the best approach is the iptables one?
Boniforti Flavio wrote:
>> I guess you could track the transfer times and sizes for each
>> host/share, but there is a philosophical/practical issue in
>> tracking the storage space since it is pooled and there is no
>> handy way to tell which, if any, other hosts have links to a
>> common file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Boniforti Flavio wrote:
>> bad news is, (AFAIK) that this data is not collected within
>> backuppc, and would need a different implementation for each
>> transfer method. The best suggestion I could make would be to
>> measure this at the network in
> In any case, I think what our colleague is asking for is how
> much transit bandwidth did a host consume during the backup
> process, and this has nothing at all to do with pooling. The
Indeed, that's what I want to know: the really transferred bytes for
that host-to-host connection (from th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Les Mikesell wrote:
> I guess you could track the transfer times and sizes for each
> host/share, but there is a philosophical/practical issue in tracking the
> storage space since it is pooled and there is no handy way to tell
> which, if any, othe
> I guess you could track the transfer times and sizes for each
> host/share, but there is a philosophical/practical issue in
> tracking the storage space since it is pooled and there is no
> handy way to tell which, if any, other hosts have links to a
> common file. In terms of real space co
Boniforti Flavio wrote:
I am not used to consider minutes in decimal format (like
>> 36.8 minutes).
>>
>> I don't think you are supposed to. The point of the web page,
>> as I understand it, is to give you a rough idea of what is
>> going on. Seeing a list of figures 36.8, 37.1, 35.9, 36.4,
Boniforti Flavio wrote:
>> Exactly, perhaps the a better (but more work involved)
>> solution would be to create a new page which shows a nice
>> pretty graph of the various numbers instead of stacks of
>> numbers in great big tables...
>
> Well, if somebody is willing to cooperate with me to d
> If you want an alternative more lay person format, I'm sure
> you could rather easily develop another web page that suits
> your purposes and contribute it back to the project. In fact,
> if you start by thinking of your audience and purpose, the
> ideal summary page for the lay person is li
> > > I am not used to consider minutes in decimal format (like
> 36.8 minutes).
>
> I don't think you are supposed to. The point of the web page,
> as I understand it, is to give you a rough idea of what is
> going on. Seeing a list of figures 36.8, 37.1, 35.9, 36.4,
> 242.8, 37.3 ... makes
> Exactly, perhaps the a better (but more work involved)
> solution would be to create a new page which shows a nice
> pretty graph of the various numbers instead of stacks of
> numbers in great big tables...
Well, if somebody is willing to cooperate with me to do it, I'll be
willing to learn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey J. Kosowsky wrote:
> I agree totally with Holger. It is much easier to convert raw data to less
> precise and/or more humanly readable formats than vica-versa. Plus,
> the data is usually something you only look at when troubleshooting or
> ana
many other changes beyond just time and
storage formats.
Holger Parplies wrote at about 21:18:54 +0200 on Friday, May 15, 2009:
> Hi,
>
> Bharat Mistry wrote on 2009-05-15 15:57:57 +0100 [Re: [BackupPC-users]
> [SUGGESTION] "Duration/mins" not in decimal format]:
u have to admit, he that has a very valid point [?]
On Fri, May 15, 2009 at 8:18 PM, Holger Parplies wrote:
> Hi,
>
> Bharat Mistry wrote on 2009-05-15 15:57:57 +0100 [Re: [BackupPC-users]
> [SUGGESTION] "Duration/mins" not in decimal format]:
> > and 31.
Hi,
Bharat Mistry wrote on 2009-05-15 15:57:57 +0100 [Re: [BackupPC-users]
[SUGGESTION] "Duration/mins" not in decimal format]:
> and 31.21 GB instead of 31214312331231 bytes!!
("." instead of "!!", too? :)
> Ability to email a list o
and 31.21 GB instead of 31214312331231 bytes!!
Ability to email a list of files backed up per host "wood" me kool too.
I know, I know..
On Fri, May 15, 2009 at 7:39 AM, Boniforti Flavio wrote:
> Hello people,
>
> I hope developers will read this and take it into account if p
Hello people,
I hope developers will read this and take it into account if possible: I
am not used to consider minutes in decimal format (like 36.8 minutes).
Would it be possible to convert that data into time format (like
36m48sec) and extend the same thing to hours (not anymore 242.8minutes,
but
26 matches
Mail list logo
