On Wed, Feb 22, 2006 at 05:53:52PM -0500, Jon LaBadie wrote:
> On Wed, Feb 22, 2006 at 11:23:09PM +0100, Josef Wolf wrote:
> > On Wed, Feb 22, 2006 at 12:27:32PM -0500, Jon LaBadie wrote:
> > > On Wed, Feb 22, 2006 at 08:24:00AM -0800, Kevin Till wrote:
> > 
> > > INMNSO the default precision for the "*Rate" parameters and
> > > maybe for the "Compress" parameter also, should be changed
> > > to "0".  As in:
> > > 
> > >   -    { "TapeRate",   1, 6,  1,  0, "%*.*f",  "KB/s" },
> > >   +    { "TapeRate",   1, 6,  0,  0, "%*.*f",  "KB/s" },
> > > 
> > > Does anyone really care if the rate was 1231.3 or 1231.4 KB/s?
> > > Not only does a percision of zero get rid of the useless digit,
> > > also the decimal point is eliminated.  Thus two character
> > > positions are gained.
> > 
> > I agree with you when the difference is between 1234.3 and 1234.4.
> > OTOH, a difference between 0.1 and 0.9 is of much more interest.
> 
> Really?  If you are reading a column of taping or dumping rates?
> I'd equate each to ZERO and look for what was wrong.
> 
> Similarly for compressibility, I doubt I'd care if it was 0.1 or
> 0.9%.  I forget which way the column reports, but one way it says
> not compressible, the other says immensely compressible.  The
> fine degree of "not" or "immense" would not matter to me.

Oh, I did not recognize that you talk about those two columns _only_.

> > A better way (IMHO) would be do automatically adjust the value
> > to 2..4 digits, strip off the dot and append the unit.  With this,
> > 1234567 would become 1234k, 123456 would become 123k and 12345678
> > would become 12M.  Please check the kb() subroutine in the amandatape
> > program to see what I mean.  I find this a good compromise because
> > the witdh is always between 3..5 characters and the error is always
> > below 10%.
> 
> You are talking about the size columns.

I talk about all the columns.

> They are not reported with
> a decimal number even though the values are floats.  Only the rates
> and compressibility are reported with fractional numbers.  These
> don't have a big range of values in a single report.

Dumper rates can still vary very much, depending on how fast the clients
are and whether compression/encryption is enabled.

> Certainly not
> like the sizes which easily might be from 0 (or 32KB) to multi-GB
> in magnitude.

Yes. Having only one "displayunit" is not very helpful, IMHO.  This is
why I made it automatically in amandatape.  And while I was at it, I
did it for the rates, too.