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.
On Sun, Feb 21, 2021, 11:24 AM Reco <recovery...@enotuniq.net> wrote: > 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 <recovery...@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 > >
