Re: [chrony-dev] Bug -- interaction between ntpdate and chronyd at bootup -- will never sync up

[ray vantassle <rayvantassle@xxxxxxxxx>]

> So why are you using ntpdate?

Installed automatically by the distro (debian).

This machine is a Pogoplug, which does not have a RTC.  Neither does
my router, which runs Linux TomatoUSB.  Neither does a Raspberry Pi.
On these low power computers, ntpd has a heavy footprint, so chrony is
a much better solution, IMHO.

>> Syslog clip:
>>
>> Dec 31 18:00:37 PogoPlug chronyd[1894]: chronyd version 1.27 starting
>> Dec 31 18:00:37 PogoPlug chronyd[1894]: Linux kernel major=3 minor=2
>> patch=35
>> Dec 31 18:00:37 PogoPlug chronyd[1894]: hz=100 shift_hz=7
>> freq_scale=1.00000000 nominal_tick=10000 slew_delta_tick=833
>> max_tick_bias=1000 shift_pll=2
>> Dec 31 18:00:37 PogoPlug chronyd[1894]: Frequency 99963.989 +/-
>> 233363.911 ppm read from /var/lib/chrony/chrony.drift
>
>
> This reading from chrony.drift is absurd. Where did it come from?

Um, no RTC.  Also, ntpdate and chronyd are stepping on one another at
startup.  I think that the timing is such that chronyd is in the midst
of conditioning the clock when ntpdate sets the time, so chronyd
thinks the clock is fubar.
In the case here, chronyd NEVER gets straightened out.  I had to stop
and restart it, and then it got sane.

Since the clock starts out at Dec 31 1969 18:00:00 CST, it is
important to set the date/time to approximately the actual date/time
as soon as possible in the bootup sequence.  Ntpdate with 1 or 2
servers and only 1 sample does that.  Chronyd takes quite a bit
longer.

Rdate would probably be better than ntpdate.  The thing is to
*quickly* get a time at bootup, and then let chrony make it accurate
later on.

If you don't start out with a semi-valid time, this is what happens: "
chronyd[1932]: System clock wrong by 1359997028.288104 seconds,
adjustment started"
That's gonna take a loooooonh time to slew off. -)

On further perusal, adding "makestep 1000 10" to the config is neccessary.


>
>
>
>> Dec 31 18:00:37 PogoPlug chronyd[1894]: NTP packet received from
>> unauthorised host 174.36.71.205 port 123
>
>
> I guess ntpdate's return packet comes back and is intercepted by chrony.
> So why are you using ntpdate? And you might tell ntpdate ( which is a dead
> end
> program and is being phased out by the ntpd people) to use a different port
> than the ntp  port.
The phantom packet doesn't matter, and doesn't hurt anything.  This
messgae just comfirms that ntpdate & chrony are both trying to set the
clock at the same time.

Yes, I know that ntpdate is "officially" deprecated.  And that Mills hates it.
This has been the case for 12+ years, so I don't think the real world agrees.

>
> And why do you not tell chronyd to start up later> Or not run ntpdate at
> all.

No RTC.
Since the clock starts out at Dec 31 1969 18:00:00 CST, it is
important to set the date/time to approximately the actual date/time
as soon as possible

>
>> Dec 31 18:00:40 PogoPlug chronyd[1894]: Source 72.8.140.222 online
>> Dec 31 18:00:40 PogoPlug chronyd[1894]: Source 169.229.70.95 online
>> Dec 31 18:00:40 PogoPlug chronyd[1894]: Source 38.229.71.1 online
>> Dec 31 18:00:40 PogoPlug chronyd[1894]: Source 96.44.142.5 online
>> Feb  3 21:52:34 PogoPlug ntpdate[1427]: step time server 96.126.126.96
>> offset 1359949910.330424 sec
>
>
> So chrony steps the clock.
No.  Ntpdate does.


>
>
>> Feb  3 21:52:35 PogoPlug chronyd[1894]: Selected source 38.229.71.1
>> Feb  3 21:52:35 PogoPlug chronyd[1894]: System clock wrong by 0.699306
>> seconds, adjustment started
>> Feb  3 21:52:35 PogoPlug chronyd[1894]: Required tick -1999 outside
>> allowed range (9000 .. 11000)
>
>
> It is finding that the rate of your clock is way way way too slow.
Yes.  It got totally confused and decided to go insane.


>
>
>
>> Feb  3 21:52:37 PogoPlug chronyd[1894]: Can't synchronise: no majority
>>
>> Some queries:
>> PogoPlug>chronyc tracking
>> Reference ID    : 127.127.1.1 ()
>
>
> ????
> So you have a local time set?

Not really.  Like I said, chronyd is throughly confused.

>
>
>
>> Stratum         : 10
>> Ref time (UTC)  : Mon Feb  4 04:13:07 2013
>> System time     : 0.000000000 seconds fast of NTP time
>> Last offset     : -0.699305534 seconds
>> RMS offset      : 0.699305534 seconds
>> Frequency       : 100027.977 ppm fast
>
>
> Yes, absurd.
>
>
>> Residual freq   : 0.000 ppm
>> Skew            : 0.000 ppm
>> Root delay      : 0.000000 seconds
>> Root dispersion : 0.000001 seconds
>> Update interval : 0.0 seconds
>> Leap status     : Not synchronised
>>
>>
>> PogoPlug>chronyc sourcestats
>> 210 Number of sources = 4
>> Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std
>> Dev
>>
>> ==============================================================================
>> ntp2.ResComp.Berkeley.EDU   5   4   43y    1000000      0.023   +1247s
>> 2210ms
>> 96.44.142.5                 3   2   43y    1000000      0.381   -295ms
>> 702ms
>> clock.team-cymru.org        4   4   43y    1000000      0.061   +1247s
>> 2324ms
>> irc.indoforum.org           9   5   17m    -111174     11.769  -138.8s
>> 2563us
>>
>>
>> PogoPlug>chronyc sources
>> 210 Number of sources = 4
>> MS Name/IP address         Stratum Poll Reach LastRx Last sample
>>
>> ===============================================================================
>> ^x ntp2.ResComp.Berkeley.EDU     3   8   370   20m   -346ms[ -346ms] +/-
>> 97ms
>> ^x 96.44.142.5                   2  10     0   20m   -295ms[ -295ms] +/-
>> 62ms
>> ^x clock.team-cymru.org          2   9   200   20m   -273ms[ -273ms] +/-
>> 19ms
>> ^x irc.indoforum.org             2   8   377   212  -115.8s[-115.8s] +/-
>> 90ms
>
>
> And you are using irc.indoforum.org why?

It got picked up as a pool member from this:
server 0.debian.pool.ntp.org offline
server 1.debian.pool.ntp.org offline
server 2.debian.pool.ntp.org offline
server 3.debian.pool.ntp.org offline

God only knows why it thought the other servers were 43 years off, but
that one was only 17 months off.  Probably an integer overflow
somewhere.


I'm not really complaining about the way chrony works.  Rather, I'm
reporting a scenario where chrony gets crammed in sideways and can't
get itself straightened back out.  I'm not even sure what I'd like it
to do here, other than to not get confused when ntpdate sets the time
behind its back.

BTW, the time in Linux routers is generally set by doing a naive ntp
query and setting the time one an hour to once a day.  Chrony is a
resonable alternative.  Ntp is way too large to be reasonable.

FWIW, I've resolved my immediate problem by having the init.d scripts
for ntpdate and chrony to cross-check for one another.  Not entirely
happy woth that, and it's certainly not a general solution.

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.