Date: Sun, 06 May 2007 12:06:02 +0300 From: Diomidis Spinellis <dds@aueb.gr> To: Garance A Drosehn <gad@FreeBSD.org> Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes Message-ID: <463D9A7A.1080800@aueb.gr> In-Reply-To: <p06240809c262e5d7ac79@[128.113.24.47]> References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <p06240809c262e5d7ac79@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosehn wrote: > At 1:49 AM +0300 5/5/07, Diomidis Spinellis wrote: >> Poul-Henning Kamp wrote: >>> In message <463B581E.6070804@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463D9A7A.1080800>