Messages in this thread | | | Subject | Re: [RFC] New timeofday proposal (v.A1) | From | john stultz <> | Date | Wed, 08 Dec 2004 16:51:32 -0800 |
| |
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/
| |