Re: [chrony-dev] Question / Feature suggestion - trimrtc on start?

[Ed W <lists@xxxxxxxxxxxxxx>]

Hi


>> I'm not seeing why it makes a difference what the system time is at this
>> point? In fact by definition the system time at this point will simply
>> be the RTC time + estimated offset?
> 
> Because you presumably want the rtc to be close to the right time, or
> what is
> the point?

Correct


>> Essentially, the goal at boot would be to step the RTC by the estimated
>> offset and maintain the current estimated drift params. Much later we
>> will learn that the step wasn't correct, but hopefully it's better than
>> nothing.
> 
> Why is it better than nothing? With nothing on the next boot, the system
> offset and drift will be corrected by chrony, and with it, the system
> offset
> and drift (maybe smaller, maybe larger) will be corrected  by chrony.

I think I highlighted in my previous email that my init scripts (gentoo)
currently set the time mid way through the boot?  Modern kernels set
clock to RTC for you (before init).  The first part of the bootscripts
recalc the boot script dependencies and cache the answer, then later in
the boot scripts we want to want to use chrony to adjust time to match
est RTC+offset (I believe this can only be stepped, there is no slew
correction option?). So now the rest of the boot scripts run with a
potentially large clock drift?

Now, I have further problem in that the application is what looks to
most people like their broadband router. Who has ever logged into the
web interface and shut their router down cleanly?  Nope you just pull
the power out.  Additionally it's not broadband, but a dialup link for
our connectivity. Further news, the power source is battery power and so
the user has an incentive to switch us off to save power

I don't see that your suggestions don't either leave me with a boot
where we either completely ignore the estimated drift, OR we step the
clock during the boot and potentially confusing applications that care
about time step?

Now, my suggestion still steps the clock, but I'm hoping to step RTC
every some hours, and also at the end of the boot process.  The idea
being that unless the RTC is completely busted we should usually be
within some few seconds of estimated real time (updating real time when
we occasionally get connected via dialup)


Now, I have experimented with moving the startup of chrony to very early
in the boot scripts. This works ok, but slightly delays my boot time and
also means I need to put some thought into offline/online/dns for the
applications where there *is* connectivity at boot.  Miroslav has done
some useful changes here I think in 1.26 to add retries, so quite
possible it's now safe to start chrony before networking is started
without offline?


> You can of course do whatever you want on your machine. But what you are
> asking for is to make it general for everyone. Introducing another
> potential
> for bugs to creep in, having people use the option when they have no
> idea what
> it means.

?? Not really?  The code to do it was presumed to already be in chrony.
I can run it from chronyc at boot, I was just proposing to add the
option that calls the existing code automatically at startup?



> Now, If you really wanted you could do a chronyc trimrtc as part of the
> halt
> script ( just as now in Mandriva, hwclock is called to reset the rtc to the
> current time). The case where your system comes up and crashes is an
> anomaly
> that I would not waste any time thinking about.

Please give serious consideration to every embedded appliance around
your house?  When did you last login and cleanly shutdown and reboot
your tv, playstation, DVR, wifi accesspoint, etc?  There is an entire
class of applications where you just assume the shutdown scripts will
never be run?  Even cellular phones probably get rebooted rudely as
often as they get cleanly turned off!

> There will always be a jump ( if you tell chrony to jump the time at
> startup.
> You do not have to . You can tell chrony it should slew the offset even at
> startup if some of your programs object to a step).

I do not believe that chrony has an option to slew the time adjustment
based on reading the RTC?

We had a similar discussion a few months back where I asked if I could
get chrony to track rtc as a time source, I believe NTP offers this as
an option?


> Or you could start
> chrony
> early in the sequence with a offline command so it did not try to
> contact the
> servers since the network is not yet up. THen once the network is up,
> put the
> sources online.

I'm on dialup, so this is exactly what I have to do.  However, it would
not be unusual to be booted up and then rudely powered off without ever
connecting to the internet

(Also: If I do get connected to the internet then it's 2,400 baud, 1sec
RTT and $1.50/min - I probably don't get marvelous time estimates and I
definitely will have the connection maxed out and queuing packets on the
interface. As a result I have to be realistic about time keeping
accuracy and so the goal is to be +/- few secs, with the alternative
being only using the RTC...)


Thanks

Ed W

---
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.