I think it's unreasonable to expect that kind of time accuracy from the first microsecond of bootup. Relative accuracy maybe, by counting cycles of a crystal oscillator and storing events in some buffer. Then once you have a good time reference write them all out to permanent storage by doing the arithmetic to assign real times to those events.
Hi.
On Sun, Feb 21, 2021 at 06:10:08PM +0200, Andrei POPESCU wrote:
> On Du, 21 feb 21, 09:20:07, Jeffrey Walton wrote:
> > On Sun, Feb 21, 2021 at 8:58 AM Reco <recoverym4n@enotuniq.net> wrote:
> > > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > > I guess a question is why you want an RTC. If you have a decent
> > > > internet connection just run NTP on something and it will set the
> > > > computer's clock.
> > >
> > > IPSec, Tor, sec=krb5* NFS mounts.
> >
> > And anything related to X.509.
> >
> > In the old days of cell phones, back when you needed a SIM card to get
> > time from the network, you had to jump through hoops to use a
> > non-provisioned device for development.
> >
> > I think things have gotten better since then. I don't recall seeing
> > clock problems on unprovisioned devices in a while.
> >
> > > At least these four things are badly screwed if Debian OS lacks access
> > > to RTC. Systemd manages to launch those before NTP-based time
> > > synchronization kicks in, which leads to funny things to say the least.
> >
> > This may be a Systemd bug.
>
> I'd say it's up to each daemon to declare its dependencies in the
> service file.
The problem here is "started NTPd != time sync". Lack of internet
connectivity, slow to start 1st stratum time source (GNSS cold start can
take several minutes), misconfiugured resolver - it all will lead to the
problem described above.
And it's perfectly understandable why systemd does not have
"time-synced.target" state. To have it it needs to magically deduce
correct time somehow :)
So no, it's not a bug per se, but an unimplementable restriction, and it
cannot be solved by introducing everyone's dependency on ntpd. Besides,
if your platform provides RTC (and most do) - it's a problem that should
not arise at the first place.
> The problems are likely also much less visible for systems that are
> always on as systemd-timesyncd will quite quickly advance the clock on
> reboots based on a time stamp saved during shutdown.
And again - started systemd-timesyncd != synced time. The only
difference with proper ntpd is that systemd-timestynced uses only one
source of correct time - another NTP server.
Reco