Messages in this thread | | | From | "Ulrich Windl" <> | Date | Thu, 22 Apr 1999 17:17:10 +0200 | Subject | Re: RFD: tickadj way too small? |
| |
On 22 Apr 99, at 13:53, Harald Koenig wrote:
> On Apr 22, Ulrich Windl wrote: > > > Hello, > > > > I don´t know what the initial reasoning for "500/HZ" was, but I think > > the value for tickadj is way too small in the Linux kernels. > > > > (tickadj limits the speed of a adjtime() system call) > > > > The current rate is 0.5ms per second. Thus a correction of 128ms > > needs 256s, almost 5 minutes. A correction of one second (not unusual > > if the computer was powered down for a day) almost needs half an hour. > > IMHO 128ms is a pretty huge difference and should almost never happen. > and if it happens, waiting 1/2 hour shouldn't be a problem (as it > never happens anywy -- per definition;) > > and at powerup you first should use ntpdate or similar to step the clock then. > > > > The current rate of 0.05% (500PPM) is too slow in most cases. Many > > systems use much larger values. > > > > I'm suggesting to boost the value of tickadj by a factor of 100. > > Therefore tickadj will be 50000/HZ, 500 for i386. This will result in > > a correction of 50ms per second (5%). > > NO, that's _WAY_ too large! if you're trying to do some timing/benchmark > in this period you'd get 5% error just because of tickadj.
If the benchmark is long enough, the result will be the same. Despite of that I'd prefer a rather short adjust after boot over an adjustment the next hour after boot.
In addition NTP get's confused when the adjtime() remainder is still processed when precision time adjustments (MOD_OFFSET, STA_PPSTIME) is in effect, especially as the granularity of adjtime is 1µs while the other algorithms work with sub-microsecond resolution. Yesterday's experiment with the nanokernel showed that the frequency settles down quicker and without the "micro-sawtooth" if adtime() finishes quickly.
I think HP-UX uses a tickadj around 600µs...
> IMHO that's completely out of range! waiting a bit longer to get clocks > in sync is much preferable than to risk 5% errors in timing/sleep intervals > etc.
As indicated to someone else, sleeps and delays work with jiffies and are unaffected by adjtime().
[...]
Regards, Ulrich
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |