You are not logged in.

#1 2013-07-04 00:16:49

lluixhi
Member
Registered: 2013-06-28
Posts: 9

NTP and UTC woes.

NTP is synchronizing the actual time where I am as the current UTC time, making the time on my computer appear much earlier than it is:

$timedatectl status
       Local time: Wed 2013-07-03 10:14:52 PDT
  Universal time: Wed 2013-07-03 17:14:52 UTC
        RTC time: Wed 2013-07-03 17:14:52
        Timezone: America/Los_Angeles (PDT, -0700)
     NTP enabled: no
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2013-03-10 01:59:59 PST
                  Sun 2013-03-10 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-11-03 01:59:59 PDT
                  Sun 2013-11-03 01:00:00 PST

At the time I copied this, the actual UTC time was

Thurs 2013-07-04 12:14:52 UTC

Any idea how I can resolve this?

Last edited by lluixhi (2013-07-04 00:22:29)

Offline

#2 2013-07-04 00:22:04

HalosGhost
Member
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 1,486
Website

Re: NTP and UTC woes.

Wait, that looks fine to me, you're timezone is PDT, I assume? What's the output of `date`?

All the best,

-HG


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

Offline

#3 2013-07-04 00:22:49

lluixhi
Member
Registered: 2013-06-28
Posts: 9

Re: NTP and UTC woes.

Wed Jul  3 10:22:24 PDT 2013

It's not 10 AM tongue

Edit:
That's funny, it changed to

Wed Jul  3 17:24:38 PDT 2013

just now.  Solved, I guess..?
I had been synchronizing with NTP for a while now and it hasn't been working.

Last edited by lluixhi (2013-07-04 00:25:23)

Offline

#4 2013-07-04 00:26:18

HalosGhost
Member
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 1,486
Website

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

Offline

#5 2013-07-04 00:32:19

lluixhi
Member
Registered: 2013-06-28
Posts: 9

Re: NTP and UTC woes.

Seems like what actually happened is that I never ran hwclock --systohc /after/ synchronizing with ntp.  That would do it tongue

Offline

#6 2013-07-04 01:22:31

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,992
Website

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.

Last edited by Trilby (2013-07-04 01:22:49)


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Offline

#7 2013-07-04 01:30:46

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,662

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?

EDIT: OK. I'm very confused.

hwclock

Dydd Iau 04 mis Gorffennaf 2013 03:34:25 BST  -0.348825 seconds

timedatectl 
      Local time: Iau 2013-07-04 02:34:44 BST
  Universal time: Iau 2013-07-04 01:34:44 UTC
        Timezone: Europe/London (BST, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sul 2013-03-31 00:59:59 GMT
                  Sul 2013-03-31 02:00:00 BST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sul 2013-10-27 01:59:59 BST
                  Sul 2013-10-27 01:00:00 GMT

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...

Last edited by cfr (2013-07-04 02:03:41)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#8 2013-07-04 01:41:12

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,992
Website

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.


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Offline

#9 2013-07-04 02:11:53

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,662

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...)

Last edited by cfr (2013-07-04 02:31:05)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#10 2013-07-04 14:23:41

qinohe
Member
From: A Dutch location..)
Registered: 2012-06-20
Posts: 649

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)

alias ntp='sudo ntpd -qg && sudo hwclock --systohc --utc'

or

alias ntp='sudo ntpd -qg && sudo hwclock --systohc --localtime'

-I can give you a ladder, but you need to climb it yourself-

Offline

#11 2013-07-04 15:14:04

brebs
Member
Registered: 2007-04-03
Posts: 3,439

Re: NTP and UTC woes.

FYI, the kernel has options to do it itself:

CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
Trilby wrote:

only has to adjust by a second

A real-time app may be sensitive to such large-by-CPU-standards adjustments, though.

Chrony is easy to set up and then forget about.

Offline

#12 2013-07-04 15:34:29

qinohe
Member
From: A Dutch location..)
Registered: 2012-06-20
Posts: 649

Re: NTP and UTC woes.

Thanks for that info brebs, didn't know it could be done like that, will take a look at it.


-I can give you a ladder, but you need to climb it yourself-

Offline

#13 2013-07-04 16:14:38

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,992
Website

Re: NTP and UTC woes.

brebs wrote:

a real-time app may be sensitive to such large-by-CPU-standards adjustments, though.

True, but it could be sensitive to *any* change.  When running as a daemon, one doesn't really know when the clock will be udpated.  With an alias, I specifically choose when to adjust the time.


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Offline

#14 2013-07-04 17:27:10

brebs
Member
Registered: 2007-04-03
Posts: 3,439

Re: NTP and UTC woes.

Trilby wrote:

could be sensitive to *any* change

Sigh. Do you have a realistic example?

This is interesting:

chronyd in the default configuration never steps the time, in order not to upset other running programs.

Offline

#15 2013-07-04 17:28:37

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,992
Website

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.

Last edited by Trilby (2013-07-04 17:44:17)


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Offline

#16 2013-07-04 17:33:37

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

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.

Offline

#17 2013-07-04 18:32:02

qinohe
Member
From: A Dutch location..)
Registered: 2012-06-20
Posts: 649

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.(


-I can give you a ladder, but you need to climb it yourself-

Offline

#18 2013-07-04 22:00:42

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,662

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...)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#19 2013-07-04 22:14:11

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

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.

Offline

#20 2013-07-04 22:38:11

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,662

Re: NTP and UTC woes.

Thanks. That's interesting. Do you happen to know if the docs talk about CONFIG_RTC_SYSTOHC anywhere?

Note: I'm using the stable kernel but the documentation rtc.txt doesn't seem to cover this though it does cover hctosys.

Last edited by cfr (2013-07-04 22:39:11)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#21 2013-07-04 22:47:16

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: NTP and UTC woes.

Indeed, there is no mention of SYSTOHC in the 3.10 docs either.  That I'm not entirely sure about.

Offline

#22 2013-07-04 22:51:55

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,662

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.]

Last edited by cfr (2013-07-04 22:52:54)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#23 2013-07-04 23:02:41

Tarqi
Member
From: Ixtlan
Registered: 2012-11-27
Posts: 106
Website

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.

Edit:Corrections.

Last edited by Tarqi (2013-07-04 23:24:46)


Knowing others is wisdom, knowing yourself is enlightenment. ~Lao Tse

Offline

#24 2013-07-05 00:24:43

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,662

Re: NTP and UTC woes.

Well that cannot be working on my machine given that the clocks were clearly not synchronised.


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#25 2013-07-05 00:30:02

brebs
Member
Registered: 2007-04-03
Posts: 3,439

Re: NTP and UTC woes.

Trilby wrote:

That link actually says that by default ntpd *will* step the time.  And besides "stepping" the time, what other way is their to adjust?

That link I gave, shows a way - speeding up/down the clock by miniscule amounts.

Ntpd is old, use chrony. It's an easy, automatic way to have the PC's time correct.

half a dozen uncontrolled variables

Eh? It's all handled automatically in /etc/adjtime (edit: ) and /var/lib/chrony/chrony.drift

Last edited by brebs (2013-07-05 00:33:05)

Offline

Board footer

Powered by FluxBB