lkml.org 
[lkml]   [2004]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] New timeofday proposal (v.A1)
From
Date
On Wed, 2004-12-08 at 16:40, Christoph Lameter wrote:
> On Wed, 8 Dec 2004, john stultz wrote:
>
> > Well, its not *that* bad. Similar to the ntp_scale() function, it would
> > look something like:
> >
> > if (interval <= offset_len)
> > return (interval * singleshot_mult)>>shift;
> > else {
> > cycle_t v1,v2;
> > v1 = (offset_len * singleshot_mult)>>shift;
> > v2 = (interval-offset_len)*adjusted_mult)>>shift;
> > return v1+v2;
> > }
> >
> > Where:
> > singleshot_mult = original_mult + ntp_adj + ss_mult
> > and
> > adjusted_mult = original_mult + ntp_adj
> >
> >
>
> Yuck. Do we support this kind of thing today? Support for periods of a
> tick or so is not an issue right?

Well, ok, you're right. I got my wires twisted and misspoke. Today we
really don't, since NTP adjustments only occur on tick boundaries. So
yes, singleshot adjustments are in multiples of ticks right now. But we
do assume ticks arrive at regular periods. If they don't, well, then we
apply it for only one ticks worth, but we've lost a tick so we're wrong
anyway.

The code above, however, can handle non-regular interrupt intervals,
which is something I think we should assume will occur.

thanks
-john


-
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.124 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site