[ntp:questions] Re: uclinux and ntpd

David Woolley david at djwhome.demon.co.uk
Fri May 26 20:52:02 UTC 2006


In article <3351bfbe0605221835q1f3f9d2bqa66a8f985e793a2f at mail.gmail.com>,
ndprasad at gmail.com (DeviPrasad Natesan) wrote:

> with linux kernel version 2.4.32 which has tickadj as 5 (i.e 500/HZ).

It's the value of HZ, not tickadj, which is generally the issue.
Too high a value of HZ increases the lost interrupt rate.  HZ=100
is normally safe, although I've known disk controller drivers that
can't cope with that.

> I have given the log below of one of my systems when the shift
> happens. Please let me know what other details are required.

Again, you don't have a shift, you have a loss of synchronisation, which
always happens when a step correction is happening.

> Does it depend on the processor speed for the ntpd/jitter convergence
> to work properly. I am running microblaze at 60mhz. I also have

No, but it can affect interrupt latencies and the chances of losing 
interrupts (although hardware and software design is more of a factor).
60mHz is too slow for anything better than about 1 hour resolution,
although 60MHz should be OK :-).

> software fpu instead of hardware. Is there any other factor that can
> make this to take long time before it converges properly.

Any disturbance to the clock before it has stabilised, e.g. I don't see
any NTP startup messages which makes me concerned that you have reset the
clock manually after NTP has started (to get it into the NTP capture
range).

Lost interrupts, variable network delays.

ntdp v4's uses floating point, so its accuracy will be degraded by the
increased processing latency, but I wouldn't expect this large an 
error.




More information about the questions mailing list