Re: system time running out - again

> > After 10 minutes, the error with this server is more than 2s. It is a 
> > great offset in a small time. Following below the ntpdate output:
> > 
> > 26 Dec 16:53:13 ntpdate[7757]: adjust time server 200.20.186.75 offset 
> > -8.465980 sec
> > after 10min:
> > 26 Dec 17:03:51 ntpdate[7764]: adjust time server 200.20.186.75 offset 
> > -2.119054 sec
> > 
> > I checks this times with 2 Intel machines (a P4HT and a Celeron D 
> > Boxes), with the same kernel configs (PIII processor in config, with 
> > local APIC, IO APIC, Unsynced TSC support, APM and ACPI configured). The 
> > results are alike.
> > 
> > After that, I recompile the kernel with the CLOCK_TICK_RATE seted with 
> > 1193182 (the value is found in the timex.h from kernel 2.6 tree).
> > The results are the same in the two boxes. See the ntpdate output:
> > 
> > 26 Dec 17:44:32 ntpdate[18590]: adjust time server 200.20.186.75 offset 
> > -0.015455 sec
> > after 10 min:
> > 26 Dec 17:54:56 ntpdate[18726]: step time server 200.20.186.75 offset 
> > -2.059203 sec.
> > and after ~22min:
> > 26 Dec 18:16:50 ntpdate[18749]: step time server 200.20.186.75 offset 
> > -4.354148 sec
> > 
> > I check the error in the CLOCK_REALTIME and the CLOCK_GPOS in both 
> > situations. The error is +/- 32ns in almost cases. Both the clocks is 
> > run much faster than I expected.
> > 
> > Someone have any comments or same results with your configurations in 
> > your boxes?
> > 
> > Comments may be very useful!
> 
> In our lab for a number of machines I managed to fix CLOCK_TICK_RATE
> using the value produced by the attached module. To me the problem
> seems to be that the value of CLOCK_TICK_RATE is so mobo specific
> that it should really be algorithmically determined in the config
> phase. But aparently there are other things that affect clock speed,
> because I was unable to fix my home box by adjusting CLOCK_TICK_RATE.
> For this system I didn't go to the bottom to find out a fix. I hope
> to find this serious problem fixed for the 2.6 kernels.
>
thanks for that module - I will see if we can integrate it in some form of
calibration to resolve this problem.

The CLOCK_TICK_RATE is a general problem and not related to RTLinux - the 
variance in the range of seconds within a few minutes is not that uncommon
One problem I know of is on some P4 where speed-stepping can't be disabled
(if you could you would toast the CPU any way) and where the TSC does not
run with the nominal frequency but is also scalled down - I don't think
there is a solution for those systems other than to state that they are not
usable for rtlinux (or most likely for real-time in general).

I guess what needs to be reviewed is the calibration process - obviously there
are some problems there that are resposible for the low quality calibration of
the TSC - its on my TODO list but I did not yet look into it.

hofrat 
_______________________________________________
Rtl mailing list
[email protected]
http://hq.fsmlabs.com/mailman/listinfo/rtl
http:/www.rtlinux-gpl.org/