ntpd applet

Denys Vlasenko vda.linux at googlemail.com
Thu Apr 7 09:39:04 UTC 2011


On Thu, Apr 7, 2011 at 5:25 AM, Sergey Naumov <sknaumov at gmail.com> wrote:
> And is there a way to prevent syncing and set time immediately after
> burst requests?

I don't understand what you mean by this.

ntpd -d will exit immediately after it either steps (sets) the time:

                VERB3 bb_error_msg("stepping time by %f;
poll_exp=MINPOLL", offset);
                step_time(offset);
                if (option_mask32 & OPT_q) {
                        /* We were only asked to set time once. Done. */
                        exit(0);
                }

, or discovers that time is already within 0.125 s from correct one
and therefore nothing needs to be done:

                switch (G.discipline_state) {
                case STATE_NSET:
                        if (option_mask32 & OPT_q) {
                                /* We were only asked to set time once.
                                 * The clock is precise enough, no need to step.
                                 */
                                exit(0);
                        }

, or times out using alarm()/SIGALRM mechanism:

        /* If network is up, syncronization occurs in ~10 seconds.
         * We give "ntpd -q" 10 seconds to get first reply,
         * then another 50 seconds to finish syncing.
         *
         * I tested ntpd 4.2.6p1 and apparently it never exits
         * (will try forever), but it does not feel right.
         * The goal of -q is to act like ntpdate: set time
         * after a reasonably small period of polling, or fail.
         */
        if (opts & OPT_q) {
                option_mask32 |= OPT_qq;
                alarm(10);
        }
...
...
                        if (pfd[j].revents /* & (POLLIN|POLLERR)*/) {
                                /*
                                 * At init, alarm was set to 10 sec.
                                 * Now we did get a reply.
                                 * Increase timeout to 50 seconds to
finish syncing.
                                 */
                                if (option_mask32 & OPT_qq) {
                                        option_mask32 &= ~OPT_qq;
                                        alarm(50);
                                }
                                nfds--;
                                recv_and_process_peer_pkt(idx2peer[j]);



>> How about this?
>>
>> http://git.busybox.net/busybox/commit/?id=8e23fafadee75bbe275bb795d0b2c2121dad93e7
>
> In case of disabling syncing (in ntpdate syncing is performed only if
> difference between local and received time is small) ntpd will work
> fast enough and can be run in foreground with practical purposes and
> will be good for instant replacement of ntpdate.

I believe after the last patch it already does that.

> But personally I want
> to create applet similar to rdate - extremely small and fast, but for
> ntp servers. I need time only for logging purposes so it is not
> important for me to sync better than with precision of 1 second, and
> as long as ntpdate perform gradually syncing only for small time gaps,
> I do not need this graduality at all.

bbox doesn't have ntpdate alias (yet?). As to ntpd -q, as I said above,
it will not perform time slewing. Only ntpd without -q will.

> By the way, what is the purpose of ntpd_simple.c code? I can't find
> links to this file in busybox.

It's the old version of ntpd.c, with much simpler time tracking algorithm.
-- 
vda


More information about the busybox mailing list