Re: 2.6.19 -mm merge plans (NTP changes)

[john stultz <johnstul@us.ibm.com>]

On Wed, 2006-09-20 at 13:54 -0700, Andrew Morton wrote:
> A wander through the -mm patch queue, along with some commentary on my
> intentions.
> 
> When replying to this email, please rewrite the Subject: to something
> appropriate.  Please also attempt to cc the appropriate developer(s).
>
> ntp-move-all-the-ntp-related-code-to-ntpc.patch
> ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
> ntp-add-ntp_update_frequency.patch
> ntp-add-ntp_update_frequency-fix.patch
> ntp-add-time_adj-to-tick-length.patch
> ntp-add-time_freq-to-tick-length.patch
> ntp-prescale-time_offset.patch
> ntp-add-time_adjust-to-tick-length.patch
> ntp-remove-time_tolerance.patch
> ntp-convert-time_freq-to-nsec-value.patch
> ntp-convert-to-the-ntp4-reference-model.patch
> ntp-cleanup-defines-and-comments.patch
> kernel-time-ntpc-possible-cleanups.patch
> kill-wall_jiffies.patch
>
>  Will merge.

No objections here, but I wanted to put forth some caution as I've seen
some odd NTP behavior with the full NTP patchset on my laptop (either it
does not converge or it just converges *much* more slowly then without).
Unfortunately I've not been able to collect solid enough data to analyze
the issue (really, each run should go for atleast a full day and always
run on the same network).

However, in trying to narrow it down, the
ntp-add-time_adj-to-tick-length patch is where the behavior seems to
change the most. Again, no solid data, so I could be seeing ghosts, but
I wanted to mention it.

I'll try to put aside some time to run a few longer tests and see if I
can get some clear results.

thanks
-john