From owner-freebsd-arch@FreeBSD.ORG Wed Dec 19 10:18:13 2012 Return-Path: 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 9E6F89AB; Wed, 19 Dec 2012 10:18:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id C255D8FC12; Wed, 19 Dec 2012 10:18:12 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so210184wgb.0 for ; Wed, 19 Dec 2012 02:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CIHZ1ahh1M/SzSEHIHjnikoUbcY3hIh/SFfqZZf3g20=; b=w9iSy3YziITUVq18IAKOzUDq039HYSUfHl+uzQ9O+9ZYCs3tkLvfjegPgHHHIgX9xI yHsS9eObV6wldPOhkWi7SkUV/qrs4p7hNIG6c29TohkiTlGfn+JUK7dhxtmDEDjEjyRH j27i37M3sUT5heC80Bjib8/ihENHokimMau7W3BjmzBjb5fzTuEEjeMbcShkFj7x06pJ GbgXxfBCVR7zoKxU7JRgX8zTDiYpvE95rXH0CRKm8iT536N82HZZ07qVnqlG37ywi720 /HDlivYcSdiQ6gQ2jmni6LQzJmrBjRqTgjlvKJ/4hhEZNmgeFBuddlQ1AFPpaxNWX0Ah rJ4A== X-Received: by 10.180.24.4 with SMTP id q4mr10538733wif.19.1355911916210; Wed, 19 Dec 2012 02:11:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id ew4sm7163770wid.11.2012.12.19.02.11.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 02:11:55 -0800 (PST) Sender: Alexander Motin Message-ID: <50D192E8.3020704@FreeBSD.org> Date: Wed, 19 Dec 2012 12:11:52 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Davide Italiano Subject: Re: API explosion (Re: [RFC/RFT] calloutng) References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore , phk@onelab2.iet.unipi.it, Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:18:13 -0000 On 19.12.2012 12:03, Davide Italiano wrote: > On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp wrote: >> -------- >> In message <1355873265.1198.183.camel@revolution.hippie.lan>, Ian Lepore writes >> : >>> On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: >> >>> I'm not so sure about the 2^k precision. You speak of seconds, but I >>> would be worrying about sub-second precision in my work. >> >> It is a bad idea, and it is physically pointless, given the stabilities >> of the timebases available for computers in general. >> >> Please just take my word as a time-nut, and use a 32.32 binary format >> in seconds (see previous email) and be done with it. > > Right now -- the precision is specified in 'bintime', which is a binary number. > It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in > the specific platform. > I do not really think it worth to create another structure for > handling time (e.g. struct bintime32), as it will lead to code > duplication for all the basic conversion/math operation. On the other > hand, 32.32 may not be enough in the long future. > What do you think about that? Linux uses 32.32 format in their eventtimers code. Respecting that now we have no any timer hardware with frequency about 4GHz, that precision is probably sufficient. But if at some point we want to be able to handle absolute wall time, then 32bit integer part may be not enough. Then we return to the question: "how many different data types do we want to see in one subsystem"? Sure, using single 64bit value would be much easier then struct bintime from many perspectives, but what's about the edge cases? -- Alexander Motin