Accounting changes

[Garance A Drosehn]

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?

>>Why on earth introduce another time format ?
>>
>>Please use a standard time format please.
>
>If we use struct timeval for the three time values the structure 
>size increases considerably (especially on an amd64).  Here are some 
>numbers:
>
>i386
>Old size=48
>New size=64
>New size with timeval=76
>
>amd64
>Old size=56
>New size=72
>New size timeval=112
>
>On a busy system this increase can be more than 10GB / month.  Is
>there some other standard time format I've missed?

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?

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.

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.

-- 
Garance Alistair Drosehn     =               drosehn at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA