I personally would recommend using as many time servers as possible, because NTP does such a smart job of analyzing both the connections and latency and consistency of response of each time server, and then rates them against each other, and maintains increasingly accurate ratings and comparative factors between them.  If you have at least 3 time servers assigned, then you can select the median time value, and know that you are very probably extremely close to the most accurate value.

 

Consider a set of 3 time servers.  You request and receive a time value from the first, then get a time value from the second that is 13 milliseconds earlier than the first value, then get a value from the third time server that is 650 milliseconds in the future, compared to the first value.  You would naturally want to select a value somewhere between the 2 values that seem to agree the most, and selecting the median value puts you very close to that, and also effectively discounts the outlier.  Now you continually take additional readings from these servers, and determine that the first provides a value that is consistently plus or minus 20 milliseconds of a particular time value, and the second is plus or minus 25 milliseconds, and the third is only plus or minus 10 milliseconds of its outlying value, the lowest 'jitter' of all.  NTP can now determine a pretty good 'best value', and knows how much to trust each server if the others do not respond to a time query, and can calculate a factor to apply to each servers response.  Even though it is the outlier, the third is probably the closest to you, and will give you the most consistent response.  If NTP requests time values, and only the outlier (the 'wacky' one) responds (perhaps the others are too busy this time), it applies the calculated factor (eg. -651 milliseconds), and still has a relatively accurate time reading to compare with the local clock.

 

It is NTP that decides when it needs a lot of queries or only a rare one to the time servers.  It has algorithms built in, to tell it when it has sufficient confidence in its knowledge of how much the local clock strays.  And that depends partly on how consistent the local clock drifts.  If the value is large, but always the same amount, then it does not take long to determine, but if the value keeps fluctuating, then it will take longer to determine an average drift value.

 

If you are interested, there is more good reading in the reference part of the NTP topic.  What I have said above is based on my memory, of the reading I did over a year ago, so the above may contain an inaccurate representation of some parts of how NTP works.  NTP is actually much more complex than I have made it out to be, and is able to deal with many different sources of error, but requires very little of the user.  I found the NTP project to be fascinating to read about, an impressive effort.

Narrowing it to one NTP didn't make a difference either.  Here's a recent snap shot of the syslog:

 

Nov 2 22:39:12 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 2 22:46:45 Tower ntpd[28250]: no servers reachable

Nov 2 22:49:55 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 2 22:54:14 Tower ntpd[28250]: time reset +2.330141 s

Nov 2 22:54:44 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 2 23:10:46 Tower ntpd[28250]: time reset +2.329763 s

Nov 2 23:12:02 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 2 23:26:46 Tower ntpd[28250]: time reset +2.296956 s

Nov 2 23:27:24 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 2 23:37:01 Tower ntpd[28250]: no servers reachable

Nov 2 23:38:07 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 2 23:43:29 Tower ntpd[28250]: time reset +2.341530 s

Nov 2 23:46:07 Tower emhttp: shcmd (241): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 2 23:46:07 Tower emhttp: shcmd (242): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 2 23:46:27 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 2 23:46:27 Tower emhttp: shcmd (243): /usr/sbin/hdparm -y /dev/sda >/dev/null

Nov 2 23:59:24 Tower ntpd[28250]: time reset +2.284957 s

Nov 2 23:59:55 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 3 00:15:50 Tower ntpd[28250]: time reset +2.314074 s

Nov 3 00:18:08 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 3 00:32:02 Tower ntpd[28250]: time reset +2.292592 s

Nov 3 00:33:33 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 3 00:47:30 Tower ntpd[28250]: time reset +2.211280 s

Nov 3 00:47:47 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 3 01:03:45 Tower ntpd[28250]: time reset +2.319225 s

Nov 3 01:04:23 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 3 01:20:23 Tower ntpd[28250]: time reset +2.324623 s

Nov 3 01:23:33 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 3 01:31:06 Tower ntpd[28250]: no servers reachable

Nov 3 01:33:13 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

Nov 3 01:36:29 Tower ntpd[28250]: time reset +2.308685 s

Nov 3 01:37:13 Tower ntpd[28250]: synchronized to 208.80.96.96, stratum 3

 

 

My settings started out with the defaults that UnRaid setups up.

I then moved to using 3 Canadian NTP servers

I then went to one Canadian NTP server

 

This time, I am using the one's Joe L. is said he was using ( at least a year ago when he made the post ):

us.pool.ntp.org

north-america.pool.ntp.org

pool.ntp.org

 

Realistically, what are the odds the NTP servers are causing my problems?  Slim to none .. right?

 

NTP setup is basic.  Turn status to "Yes" and input servers.  Not much I can mess up there, so it has to be something else.

 

Is their not a simply way to just tell it to check my main PC's time and sync to it  ( although if it keeps falling out of sync, I guess I am going to continue to have my syslog full of enteries ).

 

Bed time.. losing my mind now 

It might be a dying motherboard battery that is causing the whole problem.  I have had that battery cause a computer to not boot, and if I remember correctly I had to (did just for the hell of it) replace the battery on my Abit Ab9 Pro board when I got it.

It might be a dying motherboard battery that is causing the whole problem.  I have had that battery cause a computer to not boot, and if I remember correctly I had to (did just for the hell of it) replace the battery on my Abit Ab9 Pro board when I got it.

 

It's a brand new board I got specifically for this build, but I guess that doesn't really mean too much.  Manufactures will save a buck or dime, if they can.

 

Even if the battery was completely dead, should it matter if the PC is plugged in and powered up continually ( as it would draw the power from the AC  )?

It might be a dying motherboard battery that is causing the whole problem.  I have had that battery cause a computer to not boot, and if I remember correctly I had to (did just for the hell of it) replace the battery on my Abit Ab9 Pro board when I got it.

 

It's a brand new board I got specifically for this build, but I guess that doesn't really mean too much.   Manufactures will save a buck or dime, if they can.

 

Even if the battery was completely dead, should it matter if the PC is plugged in and powered up continually ( as it would draw the power from the AC  )?

 

Who knows? but it is a simple thing to check and change.  Another thing you can check is that the time in the BIOS is set as close to correct as possible.

What is it going to hurt by just leaving it?

 

Peter

 

Time will have problems syncing if the clock is significantly off.  Always set the time manually to at least within a few minutes of correct.

My settings started out with the defaults that UnRaid setups up.

I then moved to using 3 Canadian NTP servers

I then went to one Canadian NTP server

 

This time, I am using the one's Joe L. is said he was using ( at least a year ago when he made the post ):

us.pool.ntp.org

north-america.pool.ntp.org

pool.ntp.org

 

Realistically, what are the odds the NTP servers are causing my problems?  Slim to none .. right?

 

NTP setup is basic.  Turn status to "Yes" and input servers.  Not much I can mess up there, so it has to be something else.

 

Is their not a simply way to just tell it to check my main PC's time and sync to it  ( although if it keeps falling out of sync, I guess I am going to continue to have my syslog full of enteries ).

 

What problems?  I apologize if I have confused you, as I in no way intended to.  I'm afraid I don't see what ever is making you think there are problems, and causing you to keep making changes.  There are no errors showing, those messages are normal, at least for your clock.  NTP is working hard to keep your system clock correct, and doing a very good job of it.  From that standpoint, it does not matter how many or few, or which time servers you use, it still works to correct your time.  Your local PC could not possibly be anywhere near as accurate as even the most remote of the time servers.  Your ideal setup is 3 Canadian time servers, but realistically, the worst time server config you could come up with would probably cause your clock to be only a second off, probably less than a second.

 

NTP can't fix hardware, it just continuously adjusts your clock to stay as close as possible to the correct time.  Relax ...  Sooner or later, there will be fewer syslog messages.  I thought it would be sooner, but I admit, I was wrong.

 

Time will have problems syncing if the clock is significantly off.  Always set the time manually to at least within a few minutes of correct.

 

Tom has unRAID starting the NTP daemon with the -g option on each boot, to force a one-time huge time correction if needed, so that the time will start as close as possible to the correct current time value.

By the way, for those interested, here is my very crude 'batch' file ntpshow (also attached to this post without carriage returns), that simply displays the current NTP values.  The first line displays the one or more time servers you are currently using, and various parameters for them.  To fully understand them, you will have to look them up in the ntpq docs.  The second line just crudely shows when the drift file was last updated, and the third line shows the current drift value for your machine.  I'm sure someone can 'pretty' it up, with a "Drift value is X, updated last at Y", etc.  An improved version could be added to UnMENU.

 

ntpq -p
ls -l /etc/ntp/drift
cat /etc/ntp/drift

 

Here is the current result on my machine:

root@JacoBack:/boot# ntpshow
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+dns4.rpi.edu    18.26.4.105      2 u   28  256  377   48.212    8.750   0.981
*ntp.your.org    .CDMA.           1 u  146  256  377   59.128    6.138   0.787
+spoot.roan21.ne 140.221.9.6      3 u  287  256  376   46.626    8.066   0.707
-rw-r--r-- 1 root root 9 Nov  3 13:58 /etc/ntp/drift
-155.292

 

And my NTP setup:

USE_NTP=yes
NTP_SERVER1=0.us.pool.ntp.org
NTP_SERVER2=1.us.pool.ntp.org
NTP_SERVER3=2.us.pool.ntp.org

 

Pool URLs are not actual time servers, they each redirect to a random time server from the pool associated with its region, whether world, continent, country, etc.  So they are different with each boot, or restart of ntpd.

Rob;

 

Does NTP only do a small correction each time it fires? If so, a clock way way out would take a lot of little adjustments to correct, right?

 

In any case, it's just normal messages so I don't see the problem either, other than the syslog having a lot of the messages.

 

Peter

 

I'm not having any problems, but as you guys said, my syslog is huge because of all the time adjustments.

 

Usually the more technical you guys are , the less likely you are to suggest the "close your eyes, it will go away" approach  ( that's more for us non-super-techs ) 

 

I wonder if I shut it off, how far my server time will drift.  Any real harm in that?

You already know how far your server time drifts. It's displayed in the syslogs you posted here. Use that same value and extend it out over the course of a day, week, or month.

Does NTP only do a small correction each time it fires? If so, a clock way way out would take a lot of little adjustments to correct, right?

 

That is my understanding of it.  Large corrections are stepped, in small steps, to avoid 'disturbing/confusing' time dependent programs.  I thought about mentioning that, but did not think it applied here, because unRAID starts with the -g option, which *should* bring the clock very close to correct, at least at that point in time.  (Plus I did not want to mention any more, because I had already been long-winded enough!)

 

What could be interesting, and relevant here, is if his system clock is drifting so fast, that it is trying to step the corrections and the small steps can't catch up.  However what I initially estimated was about 3.5 minutes a day off, which is quite large, but sounds manageable to me in small steps over a day, so I don't know.

 

I also don't have a good idea as to what is causing so much drift.  I have felt that the largest factor in losing time was the volume of hardware IRQs fired, when 'ticks' could be lost, but that is based on very old hardware knowledge.  If true though, it does suggest troubleshooting all hardware devices, for something faulty.  A bad mouse could generate a lot of unwanted interrupts.  Someone's advice to turn off everything non-essential is also good advice here.  I believe that I have heard that over or underclocking, if badly done, could cause clock issues, but I have no expertise here.

The server is running well ( short of this little NTP issue ), so I don't want to get into area's I am not good at ( IRQ in Linux.. not sure where to even start ).

 

I can unplug the mouse/keyboard and when I get my RMA'ed RAM back, I could replace it, both relatively easy things to do.

 

I checked the motherboard to make sure it has a battery, not a capacitor and it does so I can go but a replacement ( but I still can't figure out what it has to do with it as I mentioned before, if the PC is powered up, what use should it have for the battery at all ? )

Just an info update, but haven't checked BIOS yet ( will do this weekend ).  I hate shutting the server off ( for fear everything doesn't come back up properly ) 

 

I shut the NTP off for the past 3 days and my server has drifted about 9 minutes out, so far.

 

Nov 3 22:58:20 Tower emhttp: shcmd (261): ln -sf /usr/share/zoneinfo/Etc/GMT+5 /etc/localtime-copied-from

Nov 3 22:58:20 Tower emhttp: shcmd (262): cp /etc/localtime-copied-from /etc/localtime

Nov 3 22:58:20 Tower emhttp: shcmd (263): /etc/rc.d/rc.ntpd stop >/dev/null 2>&1

Nov 3 22:58:20 Tower ntpd[28825]: ntpd exiting on signal 15

Nov 3 22:58:04 Tower emhttp: _shcmd: shcmd (263): exit status: 1

Nov 3 22:58:04 Tower emhttp: shcmd (264): date -s '11/3/2009 10:58:04 PM' >/dev/null

Nov 3 22:58:04 Tower emhttp: shcmd (265): hwclock --utc --systohc --noadjfile

Nov 4 04:44:34 Tower emhttp: shcmd (266): /usr/sbin/hdparm -y /dev/sda >/dev/null

Nov 4 04:51:14 Tower emhttp: shcmd (267): /usr/sbin/hdparm -y /dev/sde >/dev/null

Nov 4 04:51:14 Tower emhttp: shcmd (268): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 4 04:51:14 Tower emhttp: shcmd (269): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 4 07:05:05 Tower dhcpcd[1287]: sending DHCP_REQUEST for 172.16.0.103 to 172.16.0.1

Nov 4 07:05:05 Tower dhcpcd[1287]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 4 07:05:05 Tower dhcpcd[1287]: DHCP_ACK received from (172.16.0.1)

Nov 4 09:05:04 Tower emhttp: shcmd (270): /usr/sbin/hdparm -y /dev/sda >/dev/null

Nov 4 09:39:17 Tower emhttp: shcmd (271): /usr/sbin/hdparm -y /dev/sdb >/dev/null

Nov 4 09:39:17 Tower emhttp: shcmd (272): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 4 09:39:17 Tower emhttp: shcmd (273): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 4 12:44:07 Tower emhttp: shcmd (274): /usr/sbin/hdparm -y /dev/sde >/dev/null

Nov 4 12:44:07 Tower emhttp: shcmd (275): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 4 14:07:07 Tower emhttp: shcmd (276): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 4 14:07:18 Tower emhttp: shcmd (277): /usr/sbin/hdparm -y /dev/sde >/dev/null

Nov 4 14:16:59 Tower emhttp: shcmd (278): /usr/sbin/hdparm -y /dev/sda >/dev/null

Nov 4 14:19:09 Tower emhttp: shcmd (279): /usr/sbin/hdparm -y /dev/sdb >/dev/null

Nov 4 15:09:34 Tower emhttp: shcmd (280): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 4 17:36:18 Tower emhttp: shcmd (281): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 4 19:05:05 Tower dhcpcd[1287]: sending DHCP_REQUEST for 172.16.0.103 to 172.16.0.1

Nov 4 19:05:05 Tower dhcpcd[1287]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 4 19:05:05 Tower dhcpcd[1287]: DHCP_ACK received from (172.16.0.1)

Nov 4 21:40:21 Tower emhttp: shcmd (282): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 4 21:45:32 Tower emhttp: shcmd (283): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 5 00:12:42 Tower emhttp: shcmd (284): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 5 01:19:56 Tower emhttp: shcmd (285): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 5 01:20:06 Tower emhttp: shcmd (286): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 5 01:55:40 Tower emhttp: shcmd (287): /usr/sbin/hdparm -y /dev/sdb >/dev/null

Nov 5 07:05:05 Tower dhcpcd[1287]: sending DHCP_REQUEST for 172.16.0.103 to 172.16.0.1

Nov 5 07:05:05 Tower dhcpcd[1287]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 5 07:05:05 Tower dhcpcd[1287]: DHCP_ACK received from (172.16.0.1)

Nov 5 19:05:05 Tower dhcpcd[1287]: sending DHCP_REQUEST for 172.16.0.103 to 172.16.0.1

Nov 5 19:05:05 Tower dhcpcd[1287]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 5 19:05:05 Tower dhcpcd[1287]: DHCP_ACK received from (172.16.0.1)

Nov 6 00:07:40 Tower emhttp: shcmd (288): /usr/sbin/hdparm -y /dev/sda >/dev/null

Nov 6 00:26:11 Tower emhttp: shcmd (289): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 6 00:26:22 Tower emhttp: shcmd (290): /usr/sbin/hdparm -y /dev/sdb >/dev/null

Nov 6 00:31:03 Tower emhttp: shcmd (291): /usr/sbin/hdparm -y /dev/sde >/dev/null

Nov 6 00:31:03 Tower emhttp: shcmd (292): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 6 04:39:19 Tower apcupsd[1530]: UPS Self Test switch to battery.

Nov 6 04:39:27 Tower apcupsd[1530]: UPS Self Test completed: Not supported

Nov 6 07:05:05 Tower dhcpcd[1287]: sending DHCP_REQUEST for 172.16.0.103 to 172.16.0.1

Nov 6 07:05:05 Tower dhcpcd[1287]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 6 07:05:05 Tower dhcpcd[1287]: DHCP_ACK received from (172.16.0.1)

Nov 6 07:12:11 Tower emhttp: shcmd (293): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 6 07:12:21 Tower emhttp: shcmd (294): /usr/sbin/hdparm -y /dev/sdb >/dev/null

Nov 6 07:47:51 Tower unmenu[1679]: gawk: ./08-unmenu-array_mgmt.awk:115: warning: escape sequence `\'' treated as plain `''

Nov 6 08:16:48 Tower unmenu[1679]: gawk: ./08-unmenu-array_mgmt.awk:115: warning: escape sequence `\'' treated as plain `''