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/