Re: [RFC - 0/12] NTP cleanup work (v. B4)

[Roman Zippel]

Hi,

On Wed, 20 Jul 2005, john stultz wrote:

> I really don't think the NTP changes I've mailed is very complex.
> Please, be specific and point to something you think is an issue and
> I'll do my best to fix it.

Maybe I should explain, in what direction I would take it.
Let's first only take tick based updates, one property I don't want to see 
go away (and which you remove in the last patch), is to basically update 
xtime at every tick by (tick_nsec+time_adj) (and maybe fold time_adjust 
into time_adj), no multiply/divide just adds/shifts. Every second (or 
maybe even less frequently) we update time_adj, where we even might 
integrate a better to way to add previous errors due to SHIFT_HZ.

To add support for continous time sources, the generic ntp code would just 
provide [tick,frequency,offset] values and the time source converts it 
into its internal values. A tick based source calculates [tick_nsec, 
time_adj] and a continous source calculates the [offset,multiplier]. These 
values should be recalculated as infrequently as possible and not every 
single tick as you do with ppc_adjtimex. This also means a continous 
source updates xtime basically by calling gettimeofday (what ppc64 already 
almost does) and doesn't use update_wall_time() at all.

Maybe I'm missing something, but I don't see a reason to forcibly merge 
both ways to update the clock, keep them seperate and let the generic ntp 
code provide the basic parameters which the time source uses to update the 
clock. The important thing is to precalculate as much as possible, so that 
the runtime overhead is as low as possible and these precalculations 
differ between time sources, so what your patches basically do is to 
remove all of these precalculations and I can't convince myself to see 
this as a good thing.

BTW do you have any user space test code for this? This might be useful to 
verify that the changes are really correct and a prototype might be a good 
way to demonstrate the kernel changes.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/