announce/RFH (experimental): time mega patch for 2.2.1 (nanoseconds/PPSkit)

Ulrich Windl (ulrich.windl@rz.uni-regensburg.de)
Thu, 11 Mar 1999 08:42:08 +0100


(RFH is a Request for Hacking)

Hi!

[[Why did I spend so many hours doing this? Most applications really
don't need nanosecond time resolution, but there are advantages doing
so; in fact the current code even uses fractional nanoseconds, so
that we fix the issues of the next few years too ;-)
For architectures where 1000000µs don't divide nicly by HZ, the 10^9
nanoseconds give a better approximation (alpha has done a similar
thing already). Most notably with NTPv4 (which is able to sync time
with only one correction per day) it's necessary that the time error
does not become too large between corrections. Where in the current
code a tick correction my 1µs corresponds a change of 100PPM on i386,
the new code will allow tick corrections down to 0.1PPM (which should
be below the random variation the quartz has anyway), completely
ignoring the NTP stuff. In addition you can do sub-nanosecond
corrections using the NTP interface. Finally I think the time code
really benefits from a major cleanup.]]

I have put down another snapshot (number 6) of my PPSkit. You'll find
the file PPSkit-0.6-i386-pre6.diff.gz on
linux.kernel.org/pub/linux/daemons/ntp/PPS and pcphy4.physik.uni-
regensburg.de/pub/wiu09524/PPS, and possibly also on mirrors of the
named servers by the time you read this.

The patch is still based on 2.2.1, but 2.2.2 should work as well.
2.2.3 will cause some conflicts in arch/i386/kernel/time.c. The final
patch will be against the current 2.2 kernel, but right now it's
easier to maintain the single branch until everything is reasonable
stable.

I have done another job or cleaning up the time stuff, most notably
fixing the calculation of time_precision (my Pentium-100 now has
1.5µs instead of 7.5µs).

I'll invite the maintainers (and even the owners) of architectures
other than i386 to try the patch and fix the missing things. I
started to write Documentation, but that's not finished yet.

In the meantime I'll give you some directions: Most time code moved
from kernel/sched.c to kernel/time.c, and most time stuff moved from
arch/*/kernel/time.c to kernel/time.c. Most notably there are two new
function pointers "do_microtime" and "do_nanotime" that return the
time since the last timer interrupt. These functions are required,
even if you use an implementation like follows:

my_nanotime()
{
return 0;
}

my microtime()
{
return my_nanotime() / 1000;
}

These routines are globally available now. Most of the fast/slow
timeoffset stuff is gone from the official interface, and new routines
clock_gettime(), clock_settime() and clock_getres() are there to be
blessed for system calls. These are POSIX.4, and it's likely that
there are comparable syscall numbers for other UNIXes already. I have
not done that part.

Modules using time should include <linux/time.h> instead of
<linux/sched.h>. Similarily <linux/timex.h> should only be included
if you want to deal with the NTP part of the time module. For
architecture specific (hardware) stuff <asm/timex.h> (even though I
don't like the name) should be used.

[[I know some "features" of the new code I don't like, but for Dave
Mills "it's broken if it isn't BSD". Please tell me your experience,
and I'll try to make the best of it all]]

Willing to accept changes!

Reagrds,
Ulrich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/