lkml.org 
[lkml]   [2004]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] New timeofday proposal (v.A1)
On Wed, 8 Dec 2004, john stultz wrote:

> Take a look at the adjtimex man page as well as the ntp.c file from the
> timeofday core patch. There are number of different types of adjustments
> that are made, possibly at the same time. Briefly, they are (to my
> understanding - I'm going off my notes from awhile ago):
> o tick adjustments
> how much time should pass in a _user_ tick
> o frequency adjustments
> long term adjustment to correct for constant drift),
> o offset adjustments
> additional ppm adjustment to correct for current offset from the ntp
> server
> o single shot offset adjustments
> old style adjtime functionality
>
> Tick, frequency and offset adjustments can be precalculated and summed
> to a single ppm adjustment. This is similar to the style of adjustment
> you propose directly onto the time source frequency values.
>
> However, there is also this short term single shot adjustments. These
> adjustments are made by applying the MAX_SINGLESHOT_ADJ (500ppm) scaling
> for an amount of time (offset_len) which would compensate for the
> offset. This style is difficult because we cannot precompute it and
> apply it to an entire tick. Instead it needs to be applied for just a
> specific amount of time which may be only a fraction of a tick. When we
> start talking about systems with irregular tick frequency (via
> virtualization, or tickless systems) it becomes even more problematic.

We would need to schedule a special tick like event at a certain time but
otherwise I do not see a problem. Is there a requirement that these
"specific amounts of time" are less than 1 ms? The timer hardware (such as
the RTC clock) can generate an event in <200ns that could be used to
change the scaling. For a tickless system we would need to have such
scheduled events anyways.

> If this can be fudged then it becomes less of an issue. Or at worse, we
> have to do two mult/shift operations on two "parts" of the time interval
> using different adjustments.

That looks troublesome. Better avoid that.

> Its starting to look doable, but its not necessarily the simplest thing
> (for me at least). I'll put it on my list, but patches would be more
> then welcome.

I am still suffering from my limited NTP knowlege but will see what I can
do about this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.097 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site