On 19.12.2012 12:03, Davide Italiano wrote: > On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp <phk_at_phk.freebsd.dk> wrote: >> -------- >> In message <1355873265.1198.183.camel_at_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 MotinReceived on Wed Dec 19 2012 - 09:18:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC