On Feb 15, 2012, at 5:00 PM, Bruce Dubbs wrote:
> Qrux wrote:
>> Is there a reason ntpd is run with -x?
>>
>> The big slew is nice, but is there a reason it's preferred over the kernel
>> discipline?
>
> When you are booting, there is probably nothing else really depending on
> timestamps.
Whether or not things run at boot time are sensitive to timestamps is
irrelevant. Because, if nothing cares, then it doesn't matter whether you step
or slew.
It also wasn't the question I was asking. I run ntpd in daemon mode, because I
want it to keep correcting my time after boot, and that's where the
slewing/stepping behavior is relevant. From the man page for ntpd, about -x:
====
"Slew up to 600 seconds.
"Normally, the time is slewed if the offset is less than the step threshold,
which is 128 ms by default, and stepped if above the threshold...Since the slew
rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment
requires an amortization interval of 2000s."
===
If the kernel slew rate is limited to 0.5 ms/s, then your clock had better not
drift by more than ~43 seconds/day, because no amount of slew will correct
this. So, to me, this is kind of silly. Turning slew up to 600 s is kinda
meaningless, unless you can also adjust the slew rate (and I don't see any
mention about kconfig parameter to change that). I would bet that a 43 s/d
drift is rare on "reasonably current hardware", and that if you're seeing it,
you're doing something silly like chaining UPSs or keeping your PCs in a bad
thermal environment (clock oscillators are very sensitive to temperature).
* Most people probably don't drift by more than 43 s/d.
* If they did, -x isn't their solution; it just hides a bigger issue.
* Kernel discipline (which -x disables) handles leap-seconds better.
* So, I propose turning -x off.
In addition, the BLFS ntpd is also run with -g. Long story short, it's better
to step "while you can" (i.e., before anything time-sensitive starts, like your
application stack with database servers or network authentication servers like
LDAP or Kerberos). In fact, the kernel does it anyway, when it loads the
"reference time" from the CMOS RTC.
Last leap-second was in 2008. The next leap-second was originally scheduled
for June 2012. I heard back in Jan that might be postponed. Either way, I
think '-x' should not be the default.
Q
* * * Additional Info * * *
Getting back to -x...I guess slewing is fine if you really need a slew of up to
600 seconds, and you have the kernel support to do it. But, why choose that as
the default over kernel discipine? The situation where -x would benefit you
would be the most rare of situations where you either have a one-time error and
could afford a 14d slew, or you see this kind of drift often enough and could
adjust the kernel slew rate to deal with it. In fact, if your system needs -x,
you probably don't care about good time anyway--or, should be depending on it.
If you need to run ntpd with -x, you probably have bigger fish to fry, first.
Time discipline is about who gets to discipline the clock, and how. NTP can do
it through adjtime()--with microsecond resolution--or through adjtimex() which
allows much higher precision (at the cost of portability, since, AFAIK, that
system call is only available on Linux & FreeBSD). The latter (adjtimex)
requires kernel support. In addition to precision (though, at the cost of
slightly lower accuracy due to less algorithmic sophistication), there is
another benefit to kernel discipline...
There is a time when kernel discipline is better than "always slewing by the
default slew rate limit"...Which is during leap seconds. During a leap-second,
using a non-kernel discipline and a slow monotonic slew, time will go forward a
little bit faster, but very slowly. Which means, using -x, the full extent of
that leap second won't be registered until 2000 seconds later. Practically
speaking, it comes down to: when the next leap second hits, do you want to be
off by over half-a-second over a period of 1000 s, or would you rather have
each timestamp to be off by a few dozen microseconds (arguably the difference
between the higher-accuracy-NTP discipline, or the kernel's own
slightly-less-than-fanatically-accurate discipline). Using the kernel
discipline, which can overcome the default slew rate, it will be registered
very-near immediately.
I would think leap-second-correctness >
possibly-absurdly-high-accuracy-that-may-not-matter. You could reframe my
original question as: "Why is the BLFS default choice to opt for a
possibly-more-accurate time in place of a more-correct-time?" The NTP slewing
is maybe more sophisticated than the kernel's. But, it won't handle
leap-seconds as well.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
