Date: Wed, 31 Oct 2001 13:04:55 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110312104.QAA16756@wellington.cnchost.com> In-Reply-To: Your message of "Wed, 31 Oct 2001 21:18:55 %2B0100." <75868.1004559535@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> Using double in the kernel is not needed. Not needed because...? Actually double arithmetic is even faster! 45ns for divide on the same machine where I get 130ns for long long divide. In the program I posted change all long long to double and fix up io conversion. Changing it to long double yields 62ns; still faster than long long. I bet your 128 bit fixed point will be much worse. > 10^-9 is not enough internal resolution for an NTP compliant > timekeeping implementation. We currently use 10E-9/2^32. Which your average machine isn't. PCs and even suns or sgis and whatnot have crystals with lousy staibility as you well know. > There is _no_ benefit to use a metric unit internally in > the kernel, in fact, there is only extra overhead whenever > you add together or subtract two timestamps, (which we do > everytime we (re)schedule a task on a cpu). Well you don't keep a pair like in timeval or timespec. It is a long long where the unit of count is 1 ns so there is no extra overhead (but you are better off using a long double!). Also, shouldn't you be using time relative to boot time for scheduling? > > - very few applications require resolution less than 1ns. > ... yet. (Submitted to "Famous last words" for consideration). This is not the same case as having insufficient number of bits in an address or 640Kbytes being good enough. I am sure there will be more and more applications the % won't increase. 128 bit is enough but not necessary for most userland apps. > Here we have the primary need of the process statistics > which need to figure out how long time each process sat > on the CPU, and the devinfo stuff which calculates device > statistics. These two together are the overwhelming > users of timestamps in the kernel. This should be using bootime specific time type, which doesn't need multi century range but finer resolution. > They both need to find delta-T's. They get a timestamp, > wait some time, get another one, subtract them. For this > the timespec/timeval mess sux. Agreed. > We can argue what resolution we need for this, but I think > that with 2GHz CPU's announced, 1 nanosecond is not enough > for very long time. We want to be able to account (and > profile!) down to the cpu-clock. 32bit fractions of second > gives us 4.mumble GHz, that is not enough for long enough. I have no problem in using a finer clock here; I just don't think it should be the same as a generic time type. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110312104.QAA16756>