Date: Wed, 31 Oct 2001 22:47:08 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bakul Shah <bakul@bitblocks.com> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <77749.1004564828@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 31 Oct 2001 13:04:55 PST." <200110312104.QAA16756@wellington.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200110312104.QAA16756@wellington.cnchost.com>, Bakul Shah writes: >> Using double in the kernel is not needed. > >Not needed because...? The needed precision is reachable in integer fixed point, and we don't currently waste time saving FPU state in context switches. >> 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. Right, but you need to be able to faithfully implement your half of the NTP PLL without systematics or rounding errors. nanosecond resolution alone will not do that and leads to box-car effects in the PLL. >> 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? 1. There is extra overhead if your basic representation isn't binary: you need to divide instead of shift to get seconds. 2. We already use time relative to boot for accounting. >128 bit is enough but not necessary for most userland apps. for the current interpretation of quantum mechanics, 64 bits fractions on seconds are decisively enough. >> 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. Would you mind examining current reality before you pontificate ? Thankyou. >> 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. But you don't seem to realize that a fixed point binary format is the only format which can be converted to any other format cheaply and efficiently. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?77749.1004564828>