Talk:System time

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~: 
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 11:42, 5 November 2024 (UTC)
:: Your reply ~~~~
Navigate to first

Kernel time sync

Talk status
This discussion is still ongoing.

When using kernel synchronization, according to this page the init.d script hwclock should NOT run at all, and/or the /etc/conf.d/hwclock file should have: 

clock_hctosys="YES" 
clock_systohc="YES"

However, the comments in that file suggest the opposite: 

# If you want the hwclock script to set the system time (software clock)
# to match the current hardware clock during bootup, leave this
# commented out.
# However, you can set this to "NO" if you are running a modern kernel
# and using NTP to synchronize your system clock.
#clock_hctosys="YES"

# If you do not want to set the hardware clock to the current system
# time (software clock) during shutdown, set this to no.
#clock_systohc="YES"

The way I read this, is that it should either be "NO" on both, or left as-is (that is, commented out, assuming "NO" is the default). It makes sense to me: The kernel syncs the time every 11 minutes, so if the script runs, there's no need to sync hctosys, nor systohc on startup or shutdown respectively.

Then, in the hwclock(8) man page, line 371, we learn the following:

If your system runs with '11 minute mode' on, it may need to use either --hctosys or --systz in a startup script, especially if the Hardware Clock is configured to use the local timescale. Unless the kernel is informed of what timescale the Hardware Clock is using, it may clobber it with the wrong one. The kernel uses UTC by default.

The first userspace command to set the System Clock informs the kernel what timescale the Hardware Clock is using. This happens via the persistent_clock_is_local kernel variable. If --hctosys or --systz is the first, it will set this variable according to the adjtime file or the appropriate command-line argument. Note that when using this capability and the Hardware Clock timescale configuration is changed, then a reboot is required to notify the kernel.

Pretty much any regular PC (ISA) hardware clock uses a simple "ticks" timescale without leap seconds (as it has no way of knowing about leap seconds, unless the BIOS/UEFI implementation would inject them as needed even before an operating system is booted), eventually synchronized to UTC, or a zoned timescale based on it. "Fancy" hardware clocks (GPS or Radio-Controlled) may operate on any timescale, and I assume that's what the man page refers to, if a HW clock would indeed run on TAI, the kernel needs to know in order to adjust delta-t, if it would use UTC for the system clock.

So when we say a typical PC's onboard ISA RTC is "set to UTC", that is what happens whenever it's adjusted by the kernel or some userspace tool like hwclock, but it doesn't run in UTC (or a local timezone for that matter), it produces 60 ppm, i. e. it ticks at a constant rate and flip date fields accordingly, only accounting for leap years, but not leap seconds or daylight saving. It *may* seem to provide automatic daylight saving switching to an OS, if handled by a UEFI implementation prior to loading the OS. In any event, it works more like TT / TAI (albeit typically _not_ being set ahead of UTC) as it counts ticks (of a quartz, not caesium atoms of course, unless you have a very expensive PC... ;), instead of keeping track of a mean solar day (like, e. g. a radio-controlled device).

Well, I am not sure how that is relevant in the first place when using NTP, but oh well... The three documentation places seem to contradict each other in terms of what should or should not be done in the kernel-syncing case. Do we need to be more specific in distinguishing "precision" and "regular desktop" use cases and ISA HW-Clock vs. "fancy" HW-clocks? — The preceding unsigned comment was added by Flexx (talk • contribs)

The last reverted post

Talk status
This discussion is still ongoing.

My recent post was reverted as "not necessary", but I believe mine has good reasons.

  • "Use UTC if you don't have any idea" is not absurd. William Hubbs (williamh, the OpenRC lead) says at bug #671574#c3 that "[kernel] has a very strong preference for the hardware clock being in UTC."
  • The timestamp of OpenRC log is wrong if the RTC is localtime. See this.
    • Notice no one forces UTC; simply if you use localtime, you may face some troubles, and you have to accept, or at least anticipate it.
  • Clock getting drifted by hours is a recurrent issue in Linux, if not what everyone undergoes. See [1], [2], [3]...
  • Or if there's a hardware fault, typically with the RTC battery, RTC can drift say by minutes everyday.
    • That's why I posted a convenient way to use the "date" command to fix such drifts.
      • When the system clock error is too big (by more than 1000s), /usr/sbin/ntpd won't fix it by default. In that case you need a manual fix with the "date" command (or pass "-g" to ntpd. )
    • And isn't it obvious it's not "configuration", and should be in a separate section?
    • (Rant: the current example "050612342016" as "12:34, May 6, 2016" furiates me. Why assume MMDD as late as in 2016?)
  • Dual booting with MSWin has an annoying background. For those who experienced failure in the past, it's good to tell it's historic. Then the pointer to the Arch Wiki article is inevitable.
    • At the very least the current Gentoo article lacks the dword/qword point. Even williamh referred to the Arch artcile in the above mentioned bug. :p

My previous post was an attemp to (help to) solve the bugs [4] and [5] for some part. (In fact the latter was closed as INVALID but the reporter was not convinced. I understand it.)

If you think my previous edit was unnecessary, you're a lucky one who has never seen such annoyance. If you see things you don't understand well, simply leave it. Regards. --Teika (talk) 07:15, 19 April 2019 (UTC)

First off, hiding comments in the Talk is not necessary. If you have something to say, then say it. One of the main reasons for the revert is that the System Clock section was completely removed. I saw the original article as more clear and too many Translation tags were mangled so it was best just to revert the changes. We also don't do "tl;dr" on this wiki. With reference to ntpd, yes that is known. This is why ntp-client service exists in Gentoo. Alternatively, there is chrony which handles large drifts, offline and poweroff much better than ntpd. This could be added quite simply. I will add in some references but keep most of the body the same. --Grknight (talk) 12:40, 19 April 2019 (UTC)

Sorry, but...

  • As I wrote, I did not erase the "System Clock" section; I split and promoted it to a separate section with a better name I believe, providing some more information.
  • It's nice to mention chrony, thanks. And you know that manual adjustment of the clock can be avoided. But that does not mean an abrupt revert is obviously correct, unless you write those points explicitly in the article. Please, don't assume readers already know what you know.
  • In a similar vein, adding the pointer to ArchWiki at the "external link" section is not enough; an inline mention helps. If all readers were willing to devote their time to read the entire article and references thoroughly, or readers already knew whatever you knew, then your edit would be ok, but that's not the case. (If you insist the link itself has to be in the "external link" section, it's easy to satisfy all.) I wonder if you could be a little kind to readers?
  • And you forgot that 32-bit Win needs dword, not qword. (See Arch Wiki.)
  • The page shouldn't fail to mention that localtime RTC can be the root of many kinds of trouble. If you didn't like "TL;DR", it's a mere matter of style or wording, and can be changed. The priority is: It's the content that matters.
  • Same for the translation issue. I feel sorry for translators, but do you take translation consistency - superficial - in place of improvement?
  • BTW: Perl says "tl;dr" (by Andreas K. Hüttel) [Disclosure: He found my early posts in that page unacceptable, leading to that consequence. No one can object him. ;-) [1]]

Sorry, I have to go now. I'll leave this page to you. I'll respect whatever you will decide. Thank you very much indeed for your work in Gentoo. All the best.

[1] Justification: the page Perl had long been overdue, until I created it; perl upgrading had been a tragedy in the Gentoo community! --Teika (talk) 01:10, 25 April 2019 (UTC)

Retrieved from "https://wiki.gentoo.org/index.php?title=Talk:System_time&oldid=798125"