patch: 2.4.0/2.5.0: nanoseconds time resolution

patch: 2.4.0/2.5.0: nanoseconds time resolution

[Ulrich Windl]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1155 bytes --]

Hello,

I have spend some time making a patch against the Linux kernel to 
switch to nanoseconds time resolution together with several time-
related updates. I really need support for architectures other than 
i386, specifically a routine that has a very fine and accurate time 
resolution (just using ns == 1000*us isn't the best choice).

For the 2.4.0 patch the ia64, sh, mips64, and parisc architectures are 
completely not done, and the other architectures are either untested or 
done sub-optiomal.

Therefore I put together a simple "hacking document" (see attachment) 
to guide you when trying to port the code.  More text can be found in 
Documentation/kernel-time.txt after the patch, or in the distribution 
for Linux 2.2 (PPSkit-1.0.2.tar*) So please spend an hour or two to 
help me out there. I hope I'm not forced to drop the project.

Unless you can convince me not to have a /proc/sys/kernel/time 
directory, I'd also suggest to accept the patch for 
/usr/src/linux/include/sysctl.h for the standard kernel. Currently I 
have allocated "50" for the "time" entry. I'd like to have a stable 
number for the future.

Regards,
Ulrich Windl



[-- Attachment #2: Text from file 'hacking' --]
[-- Type: text/plain, Size: 3006 bytes --]

=====================================================================
A sketch on what to consider when implementing the new time framework
on new architectures (like ia64, mips64, parisc, sh).
=====================================================================
(See
http://ftp.kernel.org/pub/linux/daemons/ntp/PPS/PPS-2.4.0-pre3.tar.bz2
for an implementation for i386)

* Add new config variables to `config.in' and `defconfig' (CONFIG_NTP,
  CONFIG_NTP_PPS, CONFIG_NTP_PPS_SERIAL)

* use `<time.h>' instead of `<timex.h>' or `<sched.h>' to access
  kernel time.

* The kernel knows how to convert kernel time to CMOS time, don't mess
  with time zones yourself

* time is kept in nanoseconds. `do_fast_gettimeoffset()' is replaced
  with `do_exact_nanotime()' that returns nanoseconds passed since
  occurrence of the last timer interrupt. `do_slow_gettimeoffset()' is
  replaced with `do_poor_nanotime()' accordingly.

* `do_gettimeofday()' and `do_settimeofday()' are implemented in the
  architecture-independent module, messing with all the status
  updates.  The common code uses the `do_nanotime()' callback to call
  the architectures' code (allowing code selection during runtime or
  boot-up).

* `set_rtc_mmss()' is called `update_rtc()' now, and it sets the
  complete date and time (not just minutes). A new `ktime_to_rtc()'
  converts kernel time to broken down time components suitable to
  write to CMOS RTC.  `mktime()' is also architecture-independent
  now. The new `rtc_to_ktime()' is used after reading the RTC to get
  kernel time.

* a new `timevar_init()' initializes all the time variables.

* `struct timex' has been changed significantly while trying to
  preserve binary compatibility as far as possible.

* time routines are in `kernel/time.c' now, and `xtime', the kernel's
  representation of time, is protected by `rwlock_t xtime_lock'.  A
  new `rtc_runs_localtime' determines if time-zone corrections have to
  be made for RTC time updates. A new data type `l_fp', a 64bit
  quantity, is used for some internal time variables (needed by the
  NTP clock model).

* a new sysctl interface allows controlling of some time variables,
  most notably the time zone and `rtc_runs_localtime'.  While
  adjusting `time_tick' (the former `tick') is deprecated for NTP
  applications, it allows fine compensation of systematic clock
  errors.

* When the kernel time is set, the RTC update procedure is triggered.

* Old routines are implemented using POSIX-alike `do_clock_gettime()'
  and `do_clock_settime()'. There's also a `do_clock_getres()' that
  gives quite realistic (not optimistic) estimates.

* `adjtimex()' has been significantly reworked, just as most of the
  other time-keeping routines.

* Updating the RTC is controlled by new variables: `rtc_update_slave',
  when non-zero, controls after how many seconds the RTC has to be
  updated. Internally `last_rtc_update' keeps the time of the last
  update.  Upon update the `rtc_update_slave' is cleared on success.

Re: patch: 2.4.0/2.5.0: nanoseconds time resolution

[Ulrich Windl]

On 22 Jan 2001, at 22:55, Albert D. Cahalan wrote:

> > Therefore I put together a simple "hacking document" (see attachment) 
> > to guide you when trying to port the code.  More text can be found in 
> > Documentation/kernel-time.txt after the patch, or in the distribution 
> > for Linux 2.2 (PPSkit-1.0.2.tar*) So please spend an hour or two to 
> > help me out there. I hope I'm not forced to drop the project.
> 
> URL for the patch? BTW, this is something for the 2.5.xx series.

The URL for the patch is on top of the hacking document, thinking that 
those who don't read it won't need the URL.

Yes the patch is intended for 2.5 if you all want it. However it 
applies to 2.4.0 for those who need it right now. As stated it requires 
some extra work that can't be done by myself alone.

> 
> > * time is kept in nanoseconds.
> 
> Nice, I'd imagine. Would that be 64-bit nanoseconds since 1970?

Compatibility: Just using timespec instead of timeval at the user-level.
Seconds are still 32bit on 32 bit machines.

> 
> > `do_fast_gettimeoffset()' is replaced
> >   with `do_exact_nanotime()' that returns nanoseconds passed since
> >   occurrence of the last timer interrupt. `do_slow_gettimeoffset()' is
> >   replaced with `do_poor_nanotime()' accordingly.
> 
> Ugh. Those names are awful. Why would anyone use do_poor_nanotime()
> when they could have something better?

That's exactly the point: For a i486 you must use the timer's counter 
register to interpolate between interrupts, but for the Pentium you can 
use the cycle counter of the CPU. When making a kernel for a 
distribution, you can't know whether the system will have a Pentium, so 
the decision is made during boot. (Just as it was before)

The old naming put stress on speed of the routines (I guess), while I 
put stress on the accuracy. So "poor" means "poor accuracy".

> 
> > * Updating the RTC is controlled by new variables: `rtc_update_slave',
> >   when non-zero, controls after how many seconds the RTC has to be
> >   updated. Internally `last_rtc_update' keeps the time of the last
> >   update.  Upon update the `rtc_update_slave' is cleared on success.
> 
> What about leap seconds on network and non-UNIX filesystems?  >:-)

You mean to say that a leap second is an implicit time update? I can 
Implement it without any trouble, if you all can agree that the idea is 
acceptable. BTW: Same applies for RTCs using local time, and we switch 
from/to DST: The kernel doesn't have the tables, so you (or cron) must 
update the /proc/sys/kernel/time/timezone.

I'd be glad if these were the only problems you had. ;-)

Regards,
Ulrich

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