On Wed, 2005-08-24 at 18:44 -0700, George Anzinger wrote:
> > Ok, so your forcing gettimeofday to be interval aware, so its applying
> > different fixed NTP adjustments to different chunks of the current
> > interval. The issue of course is if you're using fixed adjustments, is
> > that you have to have n ntp adjustments for n intervals, or you have to
> > apply the same ntp adjustment to multiple intervals.
>
> Uh, are you saying that one ntpd call can set up several different
> adjustments?
Well, it allows for frequency adjustments, tick adjustments, and offset
adjustments in a single call or just the singleshot (adjtime)
adjustment. However it does not give multiple scaling factors for
different intervals, so you are correct there.
> I was assuming that any given call would set up either a
> fixed adjustment for ever or a fixed adjustment to be applied for a
> fixed number of ticks (or until so much correcting was done, which, in
> the end is the same thing at this point in the code).
>
> If ntpd has to come back to change the adjustment, I am assuming that
> some kernel action can be taken at that time to sync the xtime clock and
> the gettimeofday reading of it. I.e. we would only have to keep track
> of one adjustment with a possible pre specified end time.
Well, I guess a component of the adjustment would end at a specified
time, that's true.
> >>I would argue that only two terms are needed here regardless of
> >>how late a tick is. This is because, I would expect the ntp system call
> >>to sync the two clocks. This means in your example, the ntp call would
> >>have been made at, or prior to the timer interrupt at 2 and this is the
> >>same edge that gettimeofday is to used to start applying the correction.
> >
> >
> > If you argue that we only need two adjustments, why not argue for only
> > one? You're saying have one adjustment that you apply for the first
> > tick's worth of time, and a second adjustment that you apply for the
> > following N ticks' worth of time in the interval. Why the odd base
> > case?
>
> Correct me if I am wrong here, but I am assuming that ntpd can ask for
> an adjustment of X amount which the kernel changes into N adjustments of
> X/N amount spread over the next N ticks.
No, sorry, you are correct there, I was confusing things.
It may work, and I had considered a similar idea when developing my
solution, but it seemed far too ugly and complicated. But that could
have just been my fault. :)
thanks
-john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |