From owner-freebsd-arch@FreeBSD.ORG Sun May 6 09:06:09 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08DC716A406; Sun, 6 May 2007 09:06:09 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 7726113C484; Sun, 6 May 2007 09:06:08 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l46966Dp025171; Sun, 6 May 2007 12:06:06 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46966ct020659; Sun, 6 May 2007 12:06:06 +0300 Received: from [192.168.136.22] (ppp124-213.adsl.forthnet.gr [193.92.231.213]) by MX-IN-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46964ZT024887; Sun, 6 May 2007 12:06:05 +0300 Authentication-Results: MX-IN-01.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <463D9A7A.1080800@aueb.gr> Date: Sun, 06 May 2007 12:06:02 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Garance A Drosehn References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 09:06:09 -0000 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 "-command" executed before "-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