Re: [RFC] HZ free ntp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 20 December 2006 02:54, john stultz wrote:

> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.

Changing it to one creates a potential problem with calling second_overflow(). 
It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off 
by one (when xtime is close to a full second and the tick length is different 
from 1sec). At a higher frequency that's not much of a problem, but at one it 
means second_overflow() is occasionally called twice a second or skipped for 
a second. Usually the error should be quite small, but sometimes it can be 
significant.
So in this case the loop in update_wall_time() should rather look like this:

	while (offset >= clock->cycle_interval) {
		...
		second_overflow();
		while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
			clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
			xtime.tv_sec++;
		}
		...
	}

(Also note the change from "if" to "while".)

Another problem area is that the clock shift value might need adjustments, 
since when you reduce the update frequency, it also increases the error 
adjustment steps and thus influences the jitter. This is especially important 
if we want to synchronize the TSC on multiple cpu's.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux