Date: Fri, 26 Oct 2001 15:25:55 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG, Peter Wemm <peter@wemm.org>, Bakul Shah <bakul@bitblocks.com> Subject: Re: 64 bit times revisited.. Message-ID: <200110262225.f9QMPta39239@apollo.backplane.com> References: <Pine.BSF.4.21.0110261622450.11653-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: :trouble is, that ticks are: :1: not guaranteed to be constant :2/ inaccurate. : :also, :you can represent ticks in terms of 1/(2^64) units, certainly to the :accuracy of the crystals that we use for timekeeping at this time. It doesn't work. That is, it *might* appear to work if a tick is an 8254 (in the microsecond range), but you wind up with a completely non-deterministic error creep that depends entirely on the frequency. The higher the frequency, the more pronounced the error. If you are trying to sync a microtime style aggregation by using the 1/(2^64) fractional format you wind up adding an error, even if it is small, every single time you call microtime(). The more often you call microtime(), the more pronounced the cumulative error. What happens if microtime() gets called in a tight loop? Oh, wait, I seem to recall that it has already been demonstrated that calling microtime in a tight loop screws things up! This is just more of the same, just with more bits to try to hide the problem. But it doesn't work if you have more processors, or faster processors. Adding more precision does NOT solve the problem. You would have to go to a 128 bit fractional quantity and that is just plain crazy. We are moving towards 10GHz in the next 10 years (probably less). With clusters one might need a unique timestamp and move to an offset counter mechanism (so each host is guarenteed completely unique timestamps) which is roughly 100GHz or 1THz virtual resolution. A 1/1E10 of cumulative error per call when a cpu may be making millions of calls is simply not acceptable. It is not a timing mechanism that will carry is forward. What happens if in the next 10 years platforms are phase-locked to each other? Think that's spacy? Gigabit ethernet already has to do it. I am not being totally wild here, I am being pragmatic. Error-prone representations are a bad base to work from. For kernel time keeping the only representation that is not prone to non-deterministic error creep is to store the time in the native counter format -- ticks at X frequency, or ticks at X*(constant) frequency. From there you can use a baseline cache conversion mechanism to convert it, with NO cumulative error, into some other format (if you need it in some other format). You wind up with a non-cumulative deterministic error no matter how often the routine is called, no matter what the frequency of the counter, etc etc etc. -Matt 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?200110262225.f9QMPta39239>