Re: [PATCH] correct inconsistent ntp interval/tick_length usage

Roman Zippel
2008-02-19T04:04:18Z

Hi,

On Mon, 18 Feb 2008, john stultz wrote:

> If we are building a train station, and each train car is 60ft, it
> doesn't make much sense to build 1000ft stations, right? Instead you'll
> do better if you build a 1020ft station.

That would assume trains are always 60ft long, which is the basic error in
your assumption.

Since we're using analogies: What you're doing is to put you winter
clothes on your weight scale and reset the scale to zero to offset for the
weigth of the clothes. If you stand now with your bathing clothes on the
scale, does that mean you lost weight?
That's all you do - you change the scale and slightly screw the scale for
everyone else trying to use it.

To keep in mind what time adjusting is supposed to do:

freq = 1sec + time_freq

What we do instead is:

freq + tick_adj = 1sec + time_freq

Where exactly is now the problem to integrate tick_adj into time_freq? The
result is _exactly_ the same. The only visible difference is a slightly
higher time_freq value and as long as it is within the 500 ppm limit there
is simply no problem.

> And yes, if we remove CLOCK_TICK_ADJUST, that would also resolve the
> (A!=B) issue, but it doesn't address the error from #2 below.
> [..]
> 2) We need a solution that handles granularity error well, as this is a
> moderate source of error for course clocksources such as jiffies.
> CLOCK_TICK_ADJUST does cover this fairly well in most cases. I suspect
> we could do even better, but that will take some deeper changes.

How exactly does CLOCK_TICK_ADJUST address this problem? The error due to
insufficient resolution is still there, all it does is shifting the scale,
so it's not immediately visible.

> My understanding of your approach (removing CLOCK_TICK_ADJUST),
> addresses issues #1 and #3, but hurts issue #2.

What exactly is hurt?

bye, Roman