SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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...
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.
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.
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.]
Last edited by mlslk31; 08-20-2014 at 10:48 AM.
Reason: clarify 'tos mindist' usage, kernel version
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).