Re: [chrony-users] gpsd, pps and chrony

[Ed W <lists@xxxxxxxxxxxxxx>]

>>> - include a hack I keep in Fedora to force name resolving until it
>>>   succeeds (enabled by configure option), the problem is with
>>>   /etc/resolv.conf filled on boot, before network is reachable, which
>>>   makes getaddrinfo() return a permanent error instead of temporary.
>>
>> Yes, this would be *very* helpful.  I'm trying to get my embedded boot
>> times down and I would like to start chrony as early as possible,
>> without waiting for the network to come up.  Also I don't expect users
>> to be connected most of the time, so I need to think about hard coding
>> IP addresses (not ideal), and offline/online management
> 
> If you are in control of the boot process, you shouldn't need it. Just
> make sure /etc/resolv.conf is empty until network is available.

This isn't obviously a solution in my case because I have a local
resolver (dnsmasq) running on the box, so I would normally have my
resolv.conf pointing at that.  Bear in mind that I might serve some
local DNS data that doesn't depend on an upstream dns server?


>> 1) "include" directive in the config file so that the file can be split
>> up for management (probably only useful to me to make updating server
>> entries simple though, so not that desirable)
> 
> Ok, that shouldn't be hard.

Thanks - I see you have already implemented this!  Building it now!


>> 2) lpj offset adjustment when re-reading tracking data...
> 
> Hm, I'm not sure chrony should know anything about clock sources and
> their calibration. Is the lpj value available in /sys, or just dmesg?
> I think this is better handled in the system scripts.


I have investigated this further and in fact lpj set on the kernel
command line appears to make *no* difference to chrony's frequency
estimation... Curious.

In fact this code in tsc_init() is causing the frequency offset to vary:

        tsc_khz = x86_platform.calibrate_tsc();
        cpu_khz = tsc_khz;

The reason I was misled is because I was altering the calibrate_tsc
functions, which in turn generate the lpj, however, it's not actually
the lpj which is causing any effect on chrony, it's something to do with
the assignment above

Now, I was partially successful at altering the calibrate_tsc to make it
more stable at boot, but I can't get it reliable to the tick every
single time unless I spend perhaps 1-2 secs calibrating at boot...
(which isn't really sensible)


Quick poll:

Who finds their boot sequence gives a rock solid "Detected xxxKhz
processor" line at bootup, and similarly gets a rock solid "Bogo mips"
and "lpj=yyy" line at every boot? (remember, zero variation is the
question?)


Followup question for someone smarter than me (Miroslav..):

- I see a clear connection between my cpu Mhz as reported in say
/proc/cpuinfo (unknown if this source is reliable when processor
powersave in use?) and the stable chrony tracking parameters
- Assuming it's not just an anomoly which affects me, could chrony
additionally store the detected kernel Mhz with the tracking params and
in the case that the next boot uses different detected Mhz, adjust the
initial tracking params to compensate?

At least in my case the above proposal will significantly increase my
initial frequency estimate by around 100-150 ppm (!!) and because I have
only intermittently connected ntp this will help enormously...


Having googled a bit I see that the basic problem has been found by
others, eg this (unsuccessful) attempt at a kernel hack in this thread:
	http://osdir.com/ml/linux-kernel/2009-05/msg05048.html

I'm quite surprised that others don't see this gross variation that I
do?  For me at least I get no value at all from chrony's saved tracking
params because chrony is tracking an average offset of around 130ppm,
but the bootup variation is some 100+ ppm around that offset?  Do others
get less variation with each boot?


Thanks - seem to be homing in on the problem at least!

Ed W

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