Accounting changes

[Diomidis Spinellis]

Garance A Drosehn wrote:
> At 1:49 AM +0300 5/5/07, Diomidis Spinellis wrote:
>> Poul-Henning Kamp wrote:
>>> In message <463B581E.6070804 at aueb.gr>, Diomidis Spinellis writes:
>>>
>>>> On modern processors the various time values were 0, because many 
>>>> commands took less than 1/64s to execute [bde].  Now time values are 
>>>> stored with microsecond precision as float numbers.(I've written 
>>>> code that allows the kernel to write them without any floating point 
>>>> operations.)
> 
> In http://www.spinellis.gr/FreeBSD/acct.h ,
> there is a comment which says:
> 
>      * Time units are milliseconds.
> 
> Is it milliseconds or microseconds?

Microseconds; I've corrected it - thanks!

> Looking at the current version of acct.h, it has a u_int16_t field,
> where the value stored is 1/64th of a second, and it's stored in a
> special floating-point format (ie, it is a format that we define,
> instead of using the native machine floating point).
> 
> Does this mean the new accounting record will be using the
> native-hardware format for floating point numbers?  Does that mean
> the records produced will be different for different hardware?

My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC 
60559) 32-bit float format.  This is the C "float" type on all the 
architectures we support.  I could add a typedef clarifying this, but I 
doubt we'll ever support an architecture (VAX?) where float is a 
different format.

> How about going to an u_int32_t field for those three time fields,
> and again use a custom-defined format for the floating-point value?
> The main reason I suggest this is so we know the format will be
> exactly the same on all architectures.  We could go with a 4-bit
> base-8 exponent (up from 3 bits in the current format), and still
> have 28 bits for the fractional-part.

The 32-bit IEEE format is close to your suggestion: 32 bits; 24 
significant binary digits (1 implied); 8 exponent bits.  The advantage 
of the IEEE format is that userland utilities can interpret the records 
without further processing.  We also avoid introducing another 
non-standard floating point format.  Many years ago I wrote Perl code to 
interpret comp_t.  It wasn't fun.

> I also wonder about using a time_t for ac_btime (starting time).
> Now that we're running freebsd on very fast, multi-processor systems,
> we might care whether "<this>-command" executed before "<that>-command",
> and we might wish to have better resolution for the start-time of a
> given command.  This is just an idle thought on my part though, and
> it is not something that I have a strong opinion on.

I don't have a strong opinion either.  Let's see if others think whether 
using a struct timeval for ac_btime would be useful.


Diomidis