[LinuxPPS] OT Nano in kernel.

[Hal V. Engel]

On Monday 28 July 2008 03:43:28 pm clemens at dwf.com wrote:
> This is off topic, but perhaps of interest since there have been a number
> of posts
> about getting NANO in both the kernel and ntp.
>
> My understanding of the situation is that we get NANO in the kernel
> (2.6.26) by default, but ACTUALLY SEEING nanosecond timing will depend on
> the
> internal 'clock' that the kernel is using.

This is probably correct.  With older kernels ntpq -c rv would always return 
precision=-19 which is basically a microsecond clock with the new nanokernel I 
get -21 which is still not nano seconds (which would be -29 or -30 I think) 
but it does indicate that there is some added precision with my hardware when 
using the nanokernel but not much.  Other hardware may see additional benfits.

>
> I assume this depends on hardware, but in building the kernel with xconfig,
> I dont
> see any place where there are options, and tho I see NANO in the ntptime
> listing
> I cant be sure that the kernel is actually doing nanosecond timing (the
> timestamps
> seem to bounce around too much).
>
> So, does anyone know about this stuff?
> Is there something to set (that I have missed) in the kernel build?

No I looked over the configuration for both 2.6.26-rc8 and 2.6.26 very 
carefully for something/anything that might affect this and found nothing.  
This will always build a nanokernel as far as I can tell at least on x86 and 
x86_64 hardware.

> It would seem, that if the processor has the hardware (doesnt all late
> model Pentiums)
> one should be doing something like the timecounter stuff in FreeBSD,
> but I havent dug thru the kernel enough to find it.

This I don't know.

I do know that 2.6.26 seems to produce better results than 2.5.26-rc8 but I 
don't know why.  Since these use different LinuxPPS patches it could be 
difference in the LinuxPPS code but it could also be something in the kernel.  
With 2.6.26-rc8 my clock was not as stable as it had been with 2.6.25 kernels 
(IE. microkernels) but 2.6.26 seems to lock onto the clock better and I now 
have submicrosecond accuracy much of the time when the machine is not loaded 
and room temperatures are stable.  This is on a fairly fast dual core machine.  
This is clearly better than with the earlier microkernels which would drift 
+-5us most of the time under similar conditions.

$ ntptime
ntp_gettime() returns code 0 (OK)
  time cc38f6f7.554cec24  Mon, Jul 28 2008 18:55:03.333, (.333205794),
  maximum error 4233 us, estimated error 0 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.003 us, frequency -51.977 ppm, interval 1 s,
  maximum error 4233 us, estimated error 0 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,

But I do find that offsets < 1us tend to jump around so it looks to me like 
the clock has about 0.5us resolution.  A few mintues after doing the above I 
got an offset of 0.706us.  I also suspect that once we get down close to 
microsecond offsets that we are approaching the limits imposed by things like 
the variabie latency of the PPS interupt handler and other external influances 
like clock rate changes with temperature. 

I have also noticed that with the nanokernel that ntpd can be swamped by 
things like quick temerature changes.  For example I just opened the windows 
becasue there is a nice cool sea breeze this evening and this dropped the room 
temperature about 5C in about 5 minutes.   It will likely be an hour or two 
before ntpd has the clock under control again.  I think this is because with a 
nanokernel that ntpd makes smaller clock rate adjustments and has trouble 
dealing with fast changes in the clock rate. 

Hal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20080728/e680deac/attachment-0001.htm