You are here

Home » Forums » General discussion

Time Clock polling interval - nodes

6 posts / 0 new
Log in or register to post comments
Last post
Mon, 01/30/2017 - 18:40
#1
k1ky
k1ky's picture
Time Clock polling interval - nodes
I've noticed that I have a node that is running 10 seconds "behind" compared to the official time.  I have other nodes that are "right on". In reading the help file, it says that it polls the time server at bootup and maintains time as long as an internet connection is available.  These nodes share the same internet at the same site, so why would they be so far off???  Is there a way to tell a node resynchronize the time without rebooting?
Top
Mon, 01/30/2017 - 18:48
k1ky
k1ky's picture
Time Cloc II
As additional information, I have a node that was up for 56 days that was off (fast) by 2 or more minutes.  Rebooted it and the time was still fast, but after about a minute after reboot, it synchronized.
Top
Tue, 01/31/2017 - 00:20
(Reply to #2)
AE6XE
AE6XE's picture
K1KY,   I think the key is,
K1KY,   I think the key is, "as long as the internet connection is available".   AREDN is running the "ntpclient -s -l -h us.pool.ntp.org" package.   It won't get started unless the time server can be ping'ed.  If it did start, then it likely exited for some reason--probably couldn't communicate with the time server for a period of time.     It can manually be restarted with "/etc/init.d/ntpclient restart" .  
Top
Tue, 01/31/2017 - 01:04
(Reply to #3)
k1ky
k1ky's picture
Good clue - I'll look into that
AE6XE, Thanks for the tip - could explain why some nodes (believe it or not - some Linksys units) that have been running for a year are within 1 second. I have a few other AREDN Ubiquiti devices that are on time and some that are off as much as a few minutes - they have been powered up for more than 2-3 months or so.  I'll check the running processes and the restart of the ntpclient that you suggested.  It's possible that the internet was interrupted long enough for this to fail and not restart.  If so, I see an easy "fix" for a future firmware release.... Where this comes into play is MeshChat appears to get it's timestamp from the node that it is running on, so it's possible for the logs to get a little out of whack.  This came to a head this evening when I was chatting with N2MH on two different nodes in our system and my replies to him showed up in the logs "before" his entries by a few minutes timestamp.
Top
Wed, 02/01/2017 - 07:13
(Reply to #4)
N2MH
N2MH's picture
Ahead of Your Time

Tom, I always thought you were ahead of your time. Now I know! :-)  Mark, N2MH

Top
Tue, 01/31/2017 - 20:26
k1ky
k1ky's picture
MESHCHAT / NODE TIME
Upon further research it appears that MESHCHAT grabs the time from the local computer that is originating a message.  Time Zone translation does occur based upon the TZ Set on the local computer.  I have found that some nodes over time quit running the ntpclient service apparently if they lose internet. I have some nodes that have been running up to a year and their ntpclient is still running and the clock is right on.  The procedure listed above from AE6XE above will restart the time service on a node, or you can simply reboot the node and it will restart the ntpclient and update if internet is available.  MESHCHAT users should check for proper time synchronization on their computers before operating in time-critical event logging and just in case check their nodes as well.
 
Top

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer