In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
