Hi,
Here is my current version of the NTP patches.
They precalculate as much possible and get rid of a lot of rather crude
compensation code. The tick length is now a much simpler value, updated
once a second, which greatly reduces the dependency on HZ.
I rebased the patches against current -mm + John's ntp.c patch.
bye, Roman
--
On Thu, 2006-08-10 at 02:01 +0200, [email protected] wrote:
> Here is my current version of the NTP patches.
> They precalculate as much possible and get rid of a lot of rather crude
> compensation code. The tick length is now a much simpler value, updated
> once a second, which greatly reduces the dependency on HZ.
> I rebased the patches against current -mm + John's ntp.c patch.
Hey Roman,
How much real-world testing have you done with these patches? I've been
running w/ this set of patches for a few days and I've been noticing my
system is having difficulties synching up w/ the NTP server.
I haven't been logging anything, so its currently uncertain data, but
normally I've seen NTP sync the time within 1-2ms in just an hour or so,
however since this morning (~6 hours ago) I'm seeing it still 10ms off.
I'm going to let it run for the rest of the day then try to bisect the
patches to see where things went wrong. I'll let you know as soon as I
find anything.
thanks
-john
Hi,
On Wed, 16 Aug 2006, john stultz wrote:
> How much real-world testing have you done with these patches? I've been
> running w/ this set of patches for a few days and I've been noticing my
> system is having difficulties synching up w/ the NTP server.
I tested it on a few machines of course.
> I haven't been logging anything, so its currently uncertain data, but
> normally I've seen NTP sync the time within 1-2ms in just an hour or so,
> however since this morning (~6 hours ago) I'm seeing it still 10ms off.
>
> I'm going to let it run for the rest of the day then try to bisect the
> patches to see where things went wrong. I'll let you know as soon as I
> find anything.
I would need the loopstats over a few days to really say something about
this. It may also depend on the stability of your remote NTP serer. The
new code adjusts a little a slower, but should be overall a little more
stable.
The ntpd does basically "if (!pll_nano) ntv.constant = sys_poll - 4;" to
adjust for the difference in behaviour of the two models, but this causes
rather fast adjustments. In the NTP4 patch I undo this adjustment for the
new model.
> I'm going to let it run for the rest of the day then try to bisect the
> patches to see where things went wrong. I'll let you know as soon as I
> find anything.
Well, upto the NTP4 patch the behaviour should be mostly unchanged.
bye, Roman