After installing gentoo-sources-2.6.26 I discovered an issue when rebuilding ntp which needs to happen when upgrading from an earlier kernel. The 2.6.26 kernel is now a nanokernel meaning that it supports nanosecond time resolution. Older kernels (if they are not patched with a nanokernel patch which none of the gentoo kernels are) are microkernels meaning that they support only microsecond time resolution. There are declarations that should appear in /usr/include/sys/timex.h that expose the nanosecond functionality to other applications like ntp. But looking at the installed header file (which resolved to /usr/include/gentoo-multilib/amd64/sys/timex.h on my system) I found that it did not contain any of the nanokernel related declarations. As a result ntpd only supports microsecond functionality and it fails to properly synchronize my system clock since it is giving the kernel microsecond adjustments which the kernel thinks are nanosecond adjustments (IE. the adjustments are off by 3 orders of magnitude). As a result the time on my system slews all over the place sometimes having an offset of several milliseconds from my reference clock which is accurate to within +-50 nanoseconds of UTC. After modifying /usr/include/gentoo-multilib/amd64/sys/timex.h to include the missing nanokernel related declarations and rebuilding ntp it is syncing up to my reference clock and maintaining the clock to with in about 10 microseconds (usually less than 1 microsecond) of my reference clock (Motorola OnCore UT+ GPS) which means it is over 2 orders of magnitude (almost 3 actually) more accurate. (most of the loss of accuracy compared to the ref clock is related to variations in the latency of the interrupt handler for the PPS signal which is what limits the overall accuracy in this system). Here is what things look like with a proper nanosecond build of ntp which is showing an offset of 344 nanoseconds. # ntptime ntp_gettime() returns code 0 (OK) time cc360e41.f128bee0 Sat, Jul 26 2008 13:57:37.942, (.942028273), maximum error 6733 us, estimated error 0 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -0.344 us, frequency -52.055 ppm, interval 1 s, maximum error 6733 us, estimated error 0 us, status 0x2001 (PLL,NANO), time constant 4, precision 0.001 us, tolerance 500 ppm, # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *GPS_ONCORE(0) .GPS. 0 l 3 16 377 0.000 0.000 0.000 # ntpq -c rv associd=0 status=0485 leap_none, sync_uhf_radio, 8 events, clock_sync, version="ntpd 4.2.5p118@1.1735-o Sat Jul 26 17:00:49 UTC 2008 (5)", processor="x86_64", system="Linux/2.6.26-gentoo", leap=00, stratum=1, precision=-21, rootdelay=0.000, rootdisp=0.338, refid=GPS, reftime=cc360e44.39270f98 Sat, Jul 26 2008 13:57:40.223, clock=cc360e4b.5743f70e Sat, Jul 26 2008 13:57:47.340, peer=3211, tc=4, mintc=3, offset=0.000, frequency=-52.055, sys_jitter=0.000, clk_jitter=0.001, clk_wander=0.000 In the kernel source tree include/linux/timex.h has the missing declarations. These declarations do not appear in /usr/include/linux/timex.h on my system but I don't think it would matter since the ntp build does not pickup this file since it uses /usr/include/sys/timex.h. This bug report was intended mostly as a heads up for the kernel maintainers since it is highly likely that only a small subset of users, specifically those who are interested time related issues (IE. time nuts), would be aware of the potential issue and actually test this new functionality. In addition, LinuxPPS functionality will likely show up as a standard part of kernel 2.6.27 (it almost make it into 2.6.26) which will make Linux a more attractive platform for applications requiring high accuracy time sources so there needs to be a plan for the nanokernel transition.
upgrade your toolchain to the latest versions and things should magically work
What is missing on my system is that with kernels starting with 2.6.26-rc8 there are changes to the timex.h file that are not reflected in /usr/include/sys/timex.h. So far the only way I have found to correct this is to hand copy the nanokernel specific changes from the timex.h file in the kernel source tree to /usr/include/sys/timex.h. I suspect that the correct way to handle this would be to emerge a newer version of linux-headers that contains an updated version of timex.h. The latest linux-headers ebuild in portage is 2.6.25-r4. I just checked the header files that are part of the linux-headers-2.6.25-r4 tarball and include/linux/timex.h does not contain any of the nanokernel declarations. The simple way to check this is to search timex.h for STA_NANO. Just an FYI there are other nanokernel specific changes in timex.h besides #define STA_NANO ... With linux-headers-2.6.25-r4 installed ntp builds for a microkernel when in fact I have a nanokernel installed which will be the case for all users once they upgrade their kernels to 2.6.26 or later. This is clearly not the correct behavior and results in ntp being broken even though it appears to be working unless it's behavior is very closely inspected. I guess that I should have been more specific and opened this against linux-headers so that it was clearer what the specific problem is. Sorry I should have been clearer - my bad. Specifically the issue is that currently there is no linux-headers-2.6.26 ebuild available and using the existing linux-header ebuilds results in ntp being broken with these newer kernels. I should add that even with the incorrectly built ntp it appears on the surface to be working but when connected to a high stability time source such as a GPS, loran or atomic clock the incorrect ntpd build will exhibit very significant issues with clock instability and degraded clock accuracy.
After an emerge --sync today I see that linux-headers-2.6.26 is available. Inspecting /usr/include/linux/timex.h after emerging it I see that it now has the nanosecond related declarations. So I am closing this.
