ntpd on CentOS 5 not working - maybe authentication?

Hi.

If it can't use any servers, then your system time will indeed not be sync'd with anything.

What does ntpq -p show you?   In particular the "Reach" values.   my guess is they are stuck at zero.
(Also shown at the top of the  "ntpq -c peer -c as -c rl"  output)

Idealy, you should use time servers close to you (in network terms.)   Your ISP or network provider should have some time servers, if not try the ntp pool project servers.  

http://www.pool.ntp.org/en/

You should select at least 3 external servers, 4 would be better.

http://www.pool.ntp.org/en/use.html   shows how.

Remember to use the ones in your own country/teretory, or as nearby (in network terms) as you can find.  Sadly, forget mobile internet or satelite links, the latency is just too long and variable for NTP to work well, but in that case, you can setup your own GPS disiplined NTP server if needed.

Regards

DaveB

The reach values are rotating over time (not stuck at zero).

I am using several external servers.  I have 3 pool servers and 4 or 5 other open ones from the list.  I tried to find ones that were geographically close, but kind of ended up with a number of different ones from across the US.

I'm on a wired cablemodem broadband connection with plently of speed so I shouldn't be having issues with latency problems.

That is what is really frustrating me about this issue, the reach values rotate and it appears I'm getting time information down, so I just don't understand why I have the 'reject' with flash=400 across every server.

Grabbed a snapshot of the statuses...

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 47075  90f4   yes   yes  none    reject   reachable 15
  2 47076  90f4   yes   yes  none    reject   reachable 15
  3 47077  90f4   yes   yes  none    reject   reachable 15
  4 47078  90f4   yes   yes  none    reject   reachable 15
  5 47079  90f4   yes   yes  none    reject   reachable 15
  6 47080  90f4   yes   yes  none    reject   reachable 15
  7 47081  90f4   yes   yes  none    reject   reachable 15
  8 47082  90f4   yes   yes  none    reject   reachable 15
  9 47083  90f4   yes   yes  none    reject   reachable 15
assID=0 status=c0f5 sync_alarm, sync_unspec, 15 events, event_clock_reset,
version="ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1)",
processor="i686", system="Linux/2.6.18-194.32.1.el5", leap=11,
stratum=16, precision=-7, rootdelay=0.000, rootdispersion=61.635,
peer=0, refid=STEP,
reftime=00000000.00000000  Wed, Feb  6 2036 22:28:16.000, poll=4,
clock=d119ca2d.a142a687  Thu, Mar  3 2011  0:05:01.629, state=4,
offset=0.000, frequency=8.747, jitter=418.975, noise=7.812,
stability=0.000, tai=0

So after letting the server sit for a few days it seems to be keeping the clock in sync the way it ought to but still is reporting errors.  Here is what the ntp looks like...

ntpq -c peer -c as -c rl
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 packman-ha.isc. 131.107.13.100   2 u   39   64  377   22.334  117999. 13390.3
 ip-173-201-38-8 198.153.152.52   2 u   45   64  377   19.708  116873. 12898.4
 time.nist.gov   .ACTS.           1 u   26   64  377   40.663  107502. 7926.08
 mailserv1.phoen .LCL.            1 u  181 1024    1   29.892  113197.   7.812
 louie.udel.edu  128.4.1.1        2 u   39   64  377   69.109  106574. 8453.43
 ns.unc.edu      204.34.198.40    2 u   62   64  377  118.644  115810. 12198.1
 ntp-3.cns.vt.ed 198.82.247.164   2 u   47   64  377   87.920  111419. 9217.98
 ntp-2.cns.vt.ed 198.82.247.164   2 u   40   64  377   66.546  104742. 9054.28
 clock.isc.org   .GPS.            1 u   58   64  367   12.086  116027. 14631.7

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 47075  90f4   yes   yes  none    reject   reachable 15
  2 47076  90f4   yes   yes  none    reject   reachable 15
  3 47077  90f4   yes   yes  none    reject   reachable 15
  4 47078  90f4   yes   yes  none    reject   reachable 15
  5 47079  90f4   yes   yes  none    reject   reachable 15
  6 47080  90f4   yes   yes  none    reject   reachable 15
  7 47081  90f4   yes   yes  none    reject   reachable 15
  8 47082  90f4   yes   yes  none    reject   reachable 15
  9 47083  90f4   yes   yes  none    reject   reachable 15
assID=0 status=c0f5 sync_alarm, sync_unspec, 15 events, event_clock_reset,
version="ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1)",
processor="i686", system="Linux/2.6.18-194.32.1.el5", leap=11,
stratum=16, precision=-7, rootdelay=0.000, rootdispersion=78.525,
peer=0, refid=STEP,
reftime=00000000.00000000  Wed, Feb  6 2036 22:28:16.000, poll=4,
clock=d11d51b0.e89f86b3  Sat, Mar  5 2011 16:20:00.908, state=4,
offset=0.000, frequency=8.747, jitter=878.651, noise=7.812,
stability=0.000, tai=0


As you suggested I performed some pings out to various places.  The big names (yahoo, google) have very low (10 ms or less) times and ttl around 55.  Some of the servers I've got configured are around 20 ms with ttl around 55 while some of them are around 100 ms and ttl around 200s.  None of that seems too extreme to be able to get a decent result - after all, this stuff used to work over dialup speed connections.  And as I understand it, ntpd ought to figure out the best servers and select one even if I do have one or two that are less than optimal, right?

I'm still trying to find out if my ISP has servers I can use, but as was said, it's kind of hard to get people that actually know what I'm even asking for.

If anyone can help me get to the bottom of this I would greatly appreciate it.

Hi.
Back after a long time out, with poor wifi access, of little use other then plain un-secure browsing.

The "Big servers" you are pinging are OK to see if your WAN access is working, but they are not time servers.

Though your servers are showing a "Reach" of 377, their offset and jitter are rather extreme to say the least.

You obviously called your ISP and asked about NTP servers, bet they said something along the lines of "we do (or do not) have any news servers".  (NNTP of course.)

They almost certainly will have some time servers (2 or three at least) but may not advertised them for "public" use.  Try asking on any user forums there are for your ISP.  You'r looking for "NTP Time Servers"  Not SNTP.

Do you still have the original setup papers for your ISP account?   That often will have (as well as the usual DNS and Gateway IP's etc) details of mail, news and what you need "Time" server addresses/names.  It's that you need.   Your router if it came from them, may be pre-configured to use one or more for it's time keeping.  Try using those addresses in your system as time servers.  (It's unlikley your router will act as one.)

If all else fails, and you have a spare machine lying about (old P3 sub 1G etc) you could try this.....
http://blog.doylenet.net/?p=145

I ended up doing that as my ISP's time servers are wayward to say the least, also the WAN latency is long and variable.  Other than the steep learning curve, it all went exactly as described.  Mind you, I need sub ms stability for what I am doing.

Look also at...
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm

and
http://time.qnan.org/

There are of course a multitude of ways to get basic time sync from a GPS, not needing the accuracy afforded by using the PPS signal some of them provide.

Perhaps that could be of use to you?   You can then sync other machines to that one.

Lastly, again, the real NTP experts are at
nntp://comp.protocols.time.ntp

There are many "News Reader" programs about.

I'm sure there are other NTP experts here too, that know far more about it, *And* linux.

Best Regards.

DaveB.

Yeah I don't need super-accurate time.

I've tried the newsgroup (you may or may not have seen my thread).  There seem to be a fair number of less than friendly people in that forum.  But regardless of that it hasn't lead to any good answers yet.

What I have learned is that most people seem to blame the linux system clock and the root cause of the system clock being off is that the 'machine' is a VM and (as I'm told) a VM doesn't stand a chance of keeping accurate time.  My retort (which wasn't taken well) was that my windows VMs don't seem to have any issue keeping time.

Regardless of that, there seems to be a disagreement as to whether one can or cannot successfully run ntpd on a VM and have it actually work.  And numerous people keep telling me that the VM should quote 'get' it's time from the host and the host should run time sync, but no one seems to want to answer the question of HOW the guest is suppose to 'get' the time from the host?

So to provide the details (which I got flamed on the newsgroups for not providing up front)...  This is a CentOS VM, running on a Windows 2008 server host, within a Windows Virtual Server VM.  I hadn't called this out as being a VM previously because (a) my experience with VMs in the past was that it didn't matter whether it was a guest or a physical machine and (b) the error code that I thought was the clue to the source of the problem didn't look like it had anything to do with timing.  And by the way in case anyone cares, the host computer keeps time just fine; so if I can get the guest to keep in step with the host, I'd be fine with that.

If anyone has suggestions on how I can get the clock on this thing running smoothly, it would be greatly appreciated.

Ah.  I also hadn't picked up you were running things in a VM.

Yes, I believe that can cause problems, as I am told, the "virtual CPU" doesnt "Run" at a fixed or even known or predictable clock rate, plus the Virtualizing machinery can take whole chunks of real time away from the VM, that it will not ordinarily be aware of.   That I suspect could be causing your problems with the exesive offsets and jitter.  NTPD (among other things) needs a relatively stable CPU clock to work correctly.   Heck it is posible to tell when the heating/air-con kicks in, in a room with a NTP server, by looking at it's statistics files, where the CPU frequency drift is logged!   At home, I can tell when the sun comes up and shines through the room window, just by examining the driftfile logs!

At a guess, if you can get the host "Real hardware" system to make it's time available via NTP or whatever, then configure the VM's to take their time from that, via the virtual LAN, that might work.  I suspect however, that NTP/NTPD will not be the best tool to use in this situation.

I'm making the rash assumption that other tools are available that would work much better in that situation, but I can't think of what exactly for now.

I have to say, other than what they are, I know next to nothing about running VM's, of any sort on any platform.

I have not (yet) spotted your thread on the NTP newsgroup, there again, I've been zapping about the UK for work, so other than like now (sitting in the office with a coffee playing "catch up") little 'net access to speak of, and what has been available, has been highly restrictive.  (Blocked outgoing ports, other than port 80, and VPN blocking too!)

AFIK any Linux is more than good enough to run NTP/NTPD, as many people/companies/ISP's etc do just that, but on a real hardware systems, not on a VM.   FreeBSD seems to be regarded as the best OS for timekeeping by those who know, but again not when run on a VM.  I do not know anything about CentOS.

I even have an old Windows 2000 system running the Meinberg port of NTPD with PPS/GPS, and that is reliable and amazingly stable too (much to everyone's surprise.)  But again, that is on real hardware (an old P1 1G machine) not on a VM.   I also have a FreeBSD based GPS disiplined NTPD timekeeper on another old P1 700M  machine.   But I'm looking for relatively accurate timekeeping, very much sub ms stability tollerance.   Going to all that trouble, as my ISP couldnt provide the sort of relaiblility and stability I need from their ADSL service.

If you could somehow configure the VM CentOS runs on, so that it's virtual CPU runs to a regular tick, then things may be able to work, but how to do that (if it is at all possible) I havent a clue, plus it could of course affect the behaviour of other VM's you have running on the same host.

I'll keep monitoring this, as if a solution is available, it'd be good to know about.   I'll also go look at the newsgroup, and see what happened there, for a more complete picture.

Best Regards.

DaveB

Wanted to thank g8kbv for pointing me to the newsgroup even though that ultimately did not prove fruitful; it did at least lead me to a lot of learning.

I hate to say it but my eventual answer ended up being to upgrade my hardware and move to a Windows 2008 R2 64-bit machines so that I could run Hyper-V and install the VM extensions that keep the clock nicely in sync with the host computer.