Re: ntpd vs ntpdate with no hardware clock
- In reply to: Warner Losh : "Re: ntpd vs ntpdate with no hardware clock"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 07 Jul 2024 19:38:13 UTC
On Jul 7, 2024, at 11:03, Warner Losh <imp@bsdimp.com> wrote: > On Sun, Jul 7, 2024, 11:54 AM Mark Millard <marklmi@yahoo.com> wrote: >> On Jul 7, 2024, at 10:23, bob prohaska <fbsd@www.zefox.net> wrote: >> >> > On Sun, Jul 07, 2024 at 11:18:56AM -0600, Warner Losh wrote: >> >> On Sun, Jul 7, 2024, 11:16 AM Ronald Klop <ronald-lists@klop.ws> wrote: >> >> >> >>> I created fakertc for my rpi4. >> >>> >> >>> https://www.freshports.org/sysutils/fakertc/ >> >>> >> >>> Saves the time on shutdown and sets it back early at boot. >> >>> >> >>> Plus I use ntpdate together with ntpd. Works fine. >> >>> >> >> >> >> Curious why the root mod time isn't firing... it whould alrwady do that >> >> >> > Root mod time seems fairly laggy: >> > rprohask@www:~ % date >> > Sun Jul 7 10:20:38 PDT 2024 >> > rprohask@www:~ % ls -al / >> > total 97 >> > drwxr-xr-x 20 root wheel 512 Jul 5 13:21 . >> > drwxr-xr-x 20 root wheel 512 Jul 5 13:21 .. >> > unless I'm misusing ls -al, of course.... >> >> I mount with noatime in use. Do you? > > Doesn't matter since it's in the superblock. Interesting. I'd not thought of such. >> Are you trying to show: >> >> time when file was created (-Ul) >> time when file status was last changed (-cl) >> time when file was last modified (-l) >> time of last access (-ul) >> >> You implicitly specified "last modified". So >> when was the last change to the root directory >> representation? It likely is not modified often. >> (Modifications to file content and subdirectories >> would not modify / of itself.) > > It's in the superblock. Time of last unmount / update (I'd recalled incorrectly). > >> linux can have relatime vs. strictatime modes. >> relatime mode updates the atime less often, via >> a rule set. A linux can have relatime by default. > > Yea... none of that matters... > Well, even with ports/packages, FreeBSD does not have enough tools to well maintain a RPi4B. For example: for doing EEPROM updates. This can lead to also having linux boot media that could separately suffer the same sort of issues. I have boot media for RaspiOS64lite (my abbreviation) that I update in order to in turn do things like update the EEPROM content of the RPi4B's, for example. Thus, for the type of overall context (RPi4B), I considered the notes potentially relevant and, so, appropriate. === Mark Millard marklmi at yahoo.com