Maybe I missed that in some post (if yes, my apologies), but some of the things discussed in here are already in /etc/rc.d/rc.ntpd. Making this executable and putting correct pool servers in the .conf did the trick for me. No problems after that. Just wanted to mention it...

I wiped the hard drive with
installed slackware-14.1 and the minimum corrupted stuff from backup dvd, did the three things to make ntp work, and it works perfectly.

The moral of this story is be cautious about what you copy from a damaged (by powering up when too cold) hard drive.

It stopped working again after a few days.


Later, #tail -f /var/log/syslog showed something like:
A search indicated that this is believed to be a xfce problem, but nobody has a solution.

I did exactly what this page requires: http://support.ntp.org/bin/view/Servers/NTPPoolServers

and commented out the two fudge lines.
Then restarted ntpd.

[code]# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*206.108.0.132 .PPS. 1 u 145 512 377 670.299 40.589 211.399
+142.137.247.109 129.6.15.29 2 u 208 256 237 666.766 30.491 259.206
+67.215.197.149 209.51.161.238 2 u 182 256 377 644.376 18.285 93.287
+206.108.0.131 .PPS. 1 u 263 256 377 665.582 41.813 287.091
bash-4.2#{/code]

So it works.

ntp is not working. Again.
The only thing I did that might have some effect is to use pkgtool to enable the cups server.

What is ntpq -pn showing now that it isn't working?

Zeroes - how I know it's not working:

Well, you can turn on ntpd debug logging via an edit of /etc/rc.d/rc.ntpd on line 6 and adding "-d -d " to the CMDLINE string, but that appears to prevent ntpd from running in the background. You'd also have to redirect stderr to a file, as far as I can tell.

The documentation for the ntpd command line options is a front runner for the most useless that I've ever had the displeasure to read in a very long time.

If I were to guess (and I am), I'd say that you are losing connectivity to the time servers for some reason and that ntpd is not able to re-establish communications.

I think, ntpq beats it. I tried to find out what the display meansby "man ntpq"...

Richard nailed it.

After serveral telephone calls to xplornet tech support and one email, I was told that xplornet had blocked access to ntp on the ntp dedicated port 123 udp. This as a result a a business meeting, and the decision is final.

From the email: "We are taking precautions to eliminate malicious attacks on our networks. This may in turn impact NTP ports due to the potential of NTP packet-amplification DDoS attacks."

So xplornet has responded to an imaginary denial of service attack by denial of a service to their customers.

I have complained to http://www.ccts-cprst.ca/ and wait for a reply. If they can't fix it, next step is a lawsuit. Small claims court (Quebec) will cost me $169.

If anyone can think of a better solution, please tell me.

Yeah: get a different ISP.

Huh? mlslk31 suggested running in debug mode back in April.

We've said all along that port 123 is being blocked.

From May 2014:
May 2014August 2014:Awesome customer service.

It is not imaginary, it has been and continues to be a problem.

Just use a different port with either Chrony or OpenNTPD as was suggested for you to try a long time ago.

Not quite imaginary, as the NTP guys themselves have an eye on it. [The old links are eluding me.] How much your ISP has acutally been hit, that's another matter.

A Garmin GPS can cost way less than $169, and it takes way fewer resources than a radio-driven clock. The GPS18x line should be less than $100:

https://buy.garmin.com/en-US/US/oem/...prod27594.html

The problem is which model you'd want and how it would perform. My experience is with the old GPS18-LVC, whose performance over classic serial may be +/-2us with PPS, +/-3ms without PPS. USB is another matter, though: My only experience with Garmin USB is a GPS60, and its performance was a rather unacceptable +/- 14ms. That stated, serial vs. serial, the GPS18 may be quicker than my handheld units simply because it has no display to update.

ntpd can handle a classic serial connection, using the NMEA driver. There is an ntpd PPS driver (ATOM) as well, but the PPS support has been tested here only on FreeBSD. [At the time it was needed--kernel 2.6?--Linux PPS support was by alpha patchset only.] At least my GPS60 is supported by the Linux kernel garmin_gps kernel module; it is used with gpsd and the ntpd SHM driver.

Last weekend, I got a new GPS18x LVC, and I'd like to amend my previous comment. The serial timecode seems rather jittery: +/-24ms RMS over 12 hours, and it will swing +/- 75ms during those 12 hours. IOW, serial pretty much has to be used with PPS, and the ntp.conf 'tos mindist' directive is useful as well.

PPS is still under investigation. It works fine on FreeBSD. All seems well when running it along the CHU audio driver. For Linux 3.17.0-rc1 and Slackware 14.1, PPS works, but something may re-start the PPS calibration (from +/-9ms) once every few hours. It will take weeks to learn whether ntpd, ntpd+gpsd, or chrony+gpsd present the best option. [Side note: I had to get some old LinuxPPS tools in order to have the timepps.h file that programs seem to want.]

About 3 weeks ago I checked and found that ntp was working. Maybe ccts ( http://www.ccts-cprst.ca/ ) got the attention of the ISP?

11 days ago a microwave link was installed - not happy with the hardware, as the transceiver (?) was installed 200' away on a tree at nose level, and the cable lies on the ground in forest except where I buried it 4" under neighbour's driveway.

Terminated Xplornet satellite service. No reply to email and telephone calls. Think that Xplornet does not love me any more.

New ISP uses pppoe. Faster, cheaper, better, but it does not always connect on boot (put ppoe-start in /etc/rc.d/rc.local).

NTP problem is solved.

Thanks to all for advice.