Re: NTP and UTC woes.

Okay, so the problem isn't that your time is syncing to UTC, the problem is that you have your localtime set incorrectly. `ls -l /etc/localtime` ntp is being silly. If it syncs correctly then you're all good. It might be worth your while to commit the localtime to the hwclock time every once in a while so that the initial sync isn't always huge.

All the best,

-HG

Last edited by HalosGhost (2013-07-04 00:27:34)

"All errors are ᴘᴇʙᴋᴀᴄ errors—It's just a matter of narrowing down which keyboard and chair." -Trilby\ldots

Re: NTP and UTC woes.

alias ntpdq='sudo ntpd -q && sudo hwclock -w'

ntp P.D.Q.

I've never understood running ntp as a daemon. I use that alias once every week or so, and it only has to adjust by a second and change. Having a daemon continuously running for that seems silly to me.

Re: NTP and UTC woes.

I thought you were meant not to use hwclock if you used ntp?

I have noticed the same issue as the OP has but only occasionally and only after rebooting, generally if I've had failed boots in between. For a brief period, the system thinks that what is actually the adjusted local time is utc and then corrects the local time by whatever is necessary for the timezone. After a few minutes, it rights itself.

This last happened to me a day or so ago when I was booting a kernel which did nothing but reboot the machine. When I booted Arch's kernel later, everything was an hour out i.e. it thought the value of BST was UTC and then set local time to that value +1 so everything was an hour on.

Whenever I check in bios, my clock seems correct, though. Is this the hardware clock?

systemctl shows the status of ntpd.service as running fine. /etc/adjtime does not exist.

According to the manual page hwclock assumes the clock is in UTC if this file does not exist. So I take it my hardware clock is set to 02:34 rather than 01:34. But why? Why doesn't ntpd.service take care of this?

EDIT EDIT: The manual page of hwclock is quite helpful further down and I think more so than the wiki which I was reading earlier. I used hwclock -w and now hwclock reports something sensible. But I'm not really clear if I should be doing something to keep it in line with the system time on a regular basis. I gather from the man page on hwclock that this probably doesn't matter much but I thought I understood this before and was very wrong...

Re: NTP and UTC woes.

cfr wrote:

I thought you were meant not to use hwclock if you used ntp?

I think you thought wrong. Do you know where that idea came from? Ntp(d) just sets the system clock. The system clock settings are lost at shutdown unless they are stored to the hardware clock via hwclock.

cfr wrote:

Whenever I check in bios, my clock seems correct, though. Is this the hwclock?

By correct do you mean it matchs your watch or wall clock? If so it is *not* correct (unless you coincidentally lived in a GMT time zone). Is that the "hwclock" ... well, that's the hardware clock - the terminology gets trickly, I prefer to reserve "hwclock" for the program of that name: hwclock syncronizes the hardware clock and the system clock - this is why I'm unsure of your original question about using a hwclock - you *definitely* use a hardware clock, I think you should also use hwclock.

Re: NTP and UTC woes.

Edited post above to clarify. I knew I used the hardware clock. It is the use of hwclock I'm not sure about.

I got part of the idea from the wiki. I worked through the page on ntp and it said to use hwclock -w only in the section on querying ntp as a one-off rather than using the daemon. So I thought that running the daemon took care of that automatically. I had a further idea that you should *not* use hwclock if running the daemon (as opposed to merely not needing to) but I am not now sure where that idea came from.

By "correct" I meant that the clock in bios has seemed roughly to correspond to utc. For half the year, that is also local time and for half it is not. However, I have not had to go into bios anywhere near as often since Lenovo replaced the motherboard as I've not had to constantly reset stuff to get bluetooth working. So I cannot say for sure when I last checked. I would have thought I would have checked after upgrading the bios but perhaps I did not notice it was an hour out. (I think it would have matched local time at that point if it was wrong.) I assume that changing the motherboard would probably have affected the clock though I'm not sure about this. Also Lenovo had to run something after I updated the bios because I don't think they'd run a required set up programme when they installed the new motherboard and it complained every boot because the serial number was missing. I am sure I went through bios after that but perhaps I didn't pay attention to the clock.

EDIT: Apparently what you are meant to do now is

timedatectl set-local-rtc 0

for utc or 1 for localtime. This sets up /etc/adjtime (even if you don't run it with privileges). This is supposed to be instead of the use of hwclock but I'm not quite sure how it all works. (https://wiki.archlinux.org/index.php/Time) (Actually, I think running hwclock -w must have done that. timedatectl seems to have no effect though the wiki says it should...)

Re: NTP and UTC woes.

@cfr,Just for clarity

CMOS = harware clock

NTP = program to update system time in localtime, set for your timezone (software)

hwclock = program to sync system time with CMOS, in UTC or localtime

I think the advice given by Trilby is the right advice, and you should not need to set RTC yourself, it is done when you issue the alias he provided.This one I use, the first one, you could use if your machine is *nix only, or with windows ,the second, for instance (I don't use)

Re: NTP and UTC woes.

You want me to provide examples that support your point? You think that my alias to adjust the time under controlled circumstances could be a problem because it would interfer with programs that require use of the system time. *IF* that is true, that it is only more so a problem when these adjustments are made not under controlled circumstances and without the user's knowledge.

Perhaps you would argue that the daemonized process only makes small changes while periodically using an alias makes big changes, but this depends on how often the alias is used, how the daemon runs, how innaccurate the hardware clock is, and how sensitive the programs are to time adjustments. So I have one variable I have complete control over, and you think having half a dozen uncontrolled variables would make it more reliable? That's absurd. I don't need to give examples of when a program would be sensitive to such changes, as you were the one that made that claim. I only comment that *if* that is true, then it only further supports using the alias method.

If a program is sensitive to changes in the system clock, then I'd prefer to have control of if/when the clock changes rather than having it be updated without my knowing it.

That link actually says that by default ntpd *will* step the time. And besides "stepping" the time, what other way is their to adjust? The local clock could be held at the current second for a little longer than a second or a little shorted until it is back on track - now no program will be upset by a "jump" or step in time, but instead the programs are getting false measures of time - which to me seems worse.

Re: NTP and UTC woes.

Trilby wrote:

alias ntpdq='sudo ntpd -q && sudo hwclock -w'

ntp P.D.Q.

I've never understood running ntp as a daemon. I use that alias once every week or so, and it only has to adjust by a second and change. Having a daemon continuously running for that seems silly to me.

I think that there are some server/client type programs that will bitch and moan if the two machines differ in time. Though I am not sure what would typically be tolerable in these cases. I tend to think that a second or so would typically work just fine, but I don't really know, nor have I ever tested these kinds of things.

I too tend to think that running ntpd.service contstantly is a bit silly though. So recently, I discovered there is the ntpdate.service that in included with the ntp package. So I set up a timer unit. Instead of the ~10min update interval of ntpd.service, I have the timer to update OnBootsec=25s and then OnUnitActiveSec=4hr. I figure that 25s is more than enough time to boot as well as establish an internet connection.

Re: NTP and UTC woes.

@brebs, I just looked into a standard kernel config, and looks these are enabled by default.So should I not use 'hwclock' then, or use it like Trilby, with '-w' option?, which is the same according to the man.It doesn't make much sense anymore right now.(

Re: NTP and UTC woes.

What exactly do those kernel options do?

Should I not have used hwclock -w to correct my hardware clock? i.e. should I have done it some other way or should I do something different in future? (Already wondering how to do this in future as I will not remember to run an alias regularly so I need something more automated...)

Re: NTP and UTC woes.

cfr wrote:

What exactly do those kernel options do?

If you are asking about the configuration stuff in brebs' post #11, these options are turned on in the standard Arch kernel. But if you want more information about what these do, you can find the documentation at /usr/src/linux-*-ARCH/Documentation/rtc.txt. (Of course the wildcard is for the version. I am using the staging kernel at the moment) You will need the linux-docs package installed.

Re: NTP and UTC woes.

Re: NTP and UTC woes.

It is just that I was hoping it might tell me why my hardware clock was not set by the system time since I was guessing that that is what that kernel config option should do i.e. if hctosys sets the system time to the hardware clock time on startup, systohc maybe should set the hardware clock to the system time on shutdown or something. I can't find anything likely looking in the directories under /sys which rtc.txt points me to for hctosys though that does confirm that system time is being set to hardware clock time on boot in my case. [And although the documentation says /proc provides more information in my case it provides zilch.]

Re: NTP and UTC woes.

Trilby wrote:

I think you thought wrong. Do you know where that idea came from? Ntp(d) just sets the system clock. The system clock settings are lost at shutdown unless they are stored to the hardware clock via hwclock.

Well... it depends. From the hwclock(8) manpage:

Automatic Hardware Clock Synchronization By the Kernel You should be aware of another way that the Hardware Clock is kept synchronized in some systems. The Linux kernel has a mode wherein it copies the System Time to the Hardware Clock every 11 minutes. This is a good mode to use when you are using something sophisticated like ntp to keep your System Time synchronized. (ntp is a way to keep your System Time synchronized either to a time server somewhere on the network or to a radio clock hooked up to your system. See RFC 1305).

This mode (we'll call it "11 minute mode") is off until something turns it on. The ntp daemon xntpd is one thing that turns it on. You can turn it off by running anything, including hwclock --hctosys, that sets the System Time the old fashioned way.

To see if it is on or off, use the command adjtimex --print and look at the value of "status". If the "64" bit of this number (expressed in binary) equal to 0, 11 minute mode is on. Otherwise, it is off.

If your system runs with 11 minute mode on, don't use hwclock --adjust or hwclock --hctosys. You'll just make a mess. It is acceptable to use a hwclock --hctosys at startup time to get a reasonable System Time until your sys‐ tem is able to set the System Time from the external source and start 11 minute mode.

While adjtimex is not present here, just use:Wrong code block deleted.

As you can see, with ntpd running, the status bit is equal to 0 (0x2001).Rechecked with adjtimex, which says that Bit 64 is 0. So the kernel will update the hardwareclock every 11 minutes.