Re: [ntp:questions] Keeping NTP Honest
John Hasler wrote: > Unruh writes: >> Actrually I think but am not sure, that chrony can also run on >> FreeBSD but I might be wrong > > FreeBSD is supported as of 1.23. Is there any chance of Windows support, John, or of ref-clock support? David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] solaris 9, ntpdate
Chuck Young wrote:
> Hello,
>
> I've spent quite a bit of time diving both solaris docs and ntp.org docs and
> am unable to come up with answers to what follows.
>
> It's difficult for me to speak authoritatively to exactly what happened as it
> was 2 weeks ago and I've only been recently called in to troubleshoot. In
> summary, 2 solaris 9 servers I help admin recently had a pretty hairy problem
> with clocks. There was a power outage in the data center housing these
> boxes. When they came back up, their clocks got badly mis-set. Around 4
> hours later, the local time server (stratum 2 below) responsible apparently
> got back on track (or further off track?); I believe xntpd quit when the
> remote and local clocks got widely off.
>
> The boxes that failed are enterprise critical DB servers and time is very
> important to our business (revenue). I'm interested in:
>
> 1) Resources to facilitate further research
> 2) More robust failover
> 3) Immediate notification of clock trouble
>
> I can code this in sh or perl myself but would naturally like to do as little
> as possible, leverage existing solutions, etc. These are production boxes
> with no real dev space for me to tinker in so KISS is the order of the day.
> Follows are gory details; sorry for long post.
>
> Here is the rough architecture:
>
> |
> strat 1: NIST | RH
> / \|/ \
> (data center 1) |(data center 2)
> /\ | / \
> strat 2:cisco-1 cisco-2 | cisco-3 cisco-4
> |
> (all clients poll first local then remote strat 2 servers)
>\V/ \V/ \V/| \V/ \V/ \V/
> strat 3: client client client | client client client
>
> (I've pointed out to colleagues that the strat 2 servers should be peered; at
> the time of this meltdown they weren't).
>
> Here is some pertinent info from one host (other is very similar):
>
> [r...@aegir ccy]# uname -a
> SunOS aegir 5.9 Generic_122300-04 sun4u sparc SUNW,Sun-Fire-V440
> [r...@aegir ccy]# ntptrace 192.168.201.117
> cisco-1.mydomain.com: stratum 2, offset -0.004321, synch distance 0.03790
> time-a.nist.gov: stratum 1, offset 0.003697, synch distance 0.0, refid
> 'ACTS'
> [r...@aegir ccy]# ntptrace 192.168.201.119
> cisco-2.mydomain.com: stratum 2, offset -0.000124, synch distance 0.03850
> time-a.nist.gov: stratum 1, offset -0.001194, synch distance 0.0, refid
> 'ACTS'
> [r...@aegir ccy]# cat /etc/inet/ntp.conf
> server 192.168.201.117
> server 192.168.201.119
> server 1.2.3.117
> server 1.2.3.119
> [r...@aegir ccy]#
>
> The saga of the clock breaking can be seen in this sequence
> of /var/adm/messages:
>
> Jun 23 07:53:52 aegir genunix: [ID 936769 kern.info] pm0 is /pseudo/p...@0
> Mar 1 00:04:25 aegir ntpdate[187]: [ID 774510 daemon.notice] step time
> server
> 1.2.3.119 offset -514799367.013772 sec
> Mar 1 00:04:27 aegir xntpd[306]: [ID 702911 daemon.notice] xntpd 3-5.93e Mon
> Sep 20 15:47:11 PDT 1999 (1)
> Mar 1 00:04:28 aegir xntpd[306]: [ID 301315 daemon.notice] tickadj = 5, tick
> = 1, tvu_maxslew = 495, est. hz = 100
> Mar 1 00:04:28 aegir xntpd[306]: [ID 798731 daemon.notice] using kernel
> phase-lock loop 0041
> Mar 1 00:04:33 aegir pseudo: [ID 129642 kern.info] pseudo-device: vol0
> Mar 1 00:04:33 aegir genunix: [ID 936769 kern.info] vol0 is /pseudo/v...@0
> Mar 1 00:08:45 aegir xntpd[306]: [ID 261039 daemon.error] time error
> 514799368.113322 is way too large (set clock manually)
>
> The other box shows similar, but not identical, issues:
>
> Mar 1 00:10:35 sif ntpdate[263]: [ID 774510 daemon.notice] step time server
> 192.168.201.117 offset -514798002.353877 sec
> Mar 1 00:10:38 sif xntpd[497]: [ID 702911 daemon.notice] xntpd 3-5.93e Mon
> Sep 20 15:47:11 PDT 1999 (1)
>
> Note here that ntpdate did the damage; also that the polled date "Sep 20
> 15:47:11 PDT 1999" was not the set date "Mar 1 00:04:27" (year???). 2
> different time servers at two different colos are shown in the respective
> "ntpdate" entries, both with similar horribly wrong offsets (there may have
> been and probably were extant network outages as the boxes came back online).
>
> Here is the pertinent shell code in the stock solaris 9 init script (edited,
> will post the whole script if asked):
>
>
> 'start')
> [ -f /etc/inet/ntp.conf ] || exit 0
>
> ARGS=`/usr/bin/cat /etc/inet/ntp.conf | /usr/bin/nawk '
> BEGIN {
> first = 1
> }
> <...>
> /^server|^peer/ {
> if (first) {
> first = 0
> printf("-s -w")
> }
> printf(" %s", $2)
> next
> }
> '`
> if [ -n "$ARGS" ]; then
>
Re: [ntp:questions] Keeping NTP Honest
> (I have seen it but have no references to give you. Ie, a group altered > ntp to use the computer temperature to predict the rate changes, and > found that they got a significant improvement in the clock discipline > doing that. Some references for this: http://dx.eng.uiowa.edu/dave/ntptemp.php https://lists.ntp.org/pipermail/hackers/2009-March/004046.html http://www.ijs.si/time/temp-compensation/ -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
Evandro Menezes writes: >On Jul 13, 12:04=A0pm, Unruh wrote: >> >> Or use the temperature controlled ntp ( reads the temp and uses that to >> estimate the clock rate changes due to temp variations) >Where can I find this NTP? googleing on "ntp temperature compansation" gave as the first item https://lists.ntp.org/pipermail/hackers/2009-March/004045.html The second http://www.ijs.si/time/temp-compensation/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
Unruh writes: > Actrually I think but am not sure, that chrony can also run on FreeBSD > but I might be wrong FreeBSD is supported as of 1.23. -- John Hasler j...@dhh.gt.org Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
"Richard B. Gilbert" writes: >Evandro Menezes wrote: >> On Jul 12, 3:21 pm, Unruh wrote: >>> The way ntp works, faster polling also means worse rate estimation and >>> more annoyance of the providers of the time. The current setup is done >>> that way to try to minimize the rate error, so if your sconnection to >>> ntp goes down, your system can freewheel with the greatest accuracy. >> >> But that's the issue: NTP allows for good freewheeling if it comes to >> that, provided that the system maintained in STP and in a vacuum. >> >> In the real world, ambient temperature changes frequently even in >> conditioned environments, network load affects packet jitter, etc. >> And all this also affects a system's peers, compounding the issue of >> NTP's slow reaction time. >> >> Thanks. >You are certainly at liberty to write your own version of NTP and have >it behave as you think best. >For most of us, NTP works quite well. I suspect that an NTP equivalent >designed to react instantly to events such as: the opening of the >computer room door, the laser printer starting or finishing a print job, > or the starting and stopping of the refrigerant compressor, would do >the job far worse than we what we have now. Sure. And if you are happy with it, there is no reason to change to anything else. It is a well supported system, and has millions using it. On the other hand if you really want a system which keeps time really well, get a GPS PPS system, and use chrony or get an ntp version which uses the temperature to compensate for rate changes. (I have seen it but have no references to give you. Ie, a group altered ntp to use the computer temperature to predict the rate changes, and found that they got a significant improvement in the clock discipline doing that. The biggest problem is finding which temp on your system is the best proxy for the temp of the clock crystal on the motherboard. Or you could glue a thermistor onto the crystal and interface it to the computer somehow. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
"David J Taylor" writes: >Unruh wrote: >[] >> Use chrony. Much much faster reaction time and better clock control. >> However you must be running Linux (yet another reason to change). >[] >Not much point in changing to Linux if all the applications I run require >a different OS. >For timekeeping, FreeBSD has a good reputation. Not much point in switching to FreeBSD is all your applications require a different OS. (Actrually I think but am not sure, that chrony can also run on FreeBSD but I might be wrong) Yes, I agree. On the other hand, many of the applications have their Linux equivalants. On the other hand, it is just a reason to change, and may not be an overriding reason. Note that FreeBSD just uses ntp AFAIK, and the problems with ntp are designed into ntp. They are not peculiar to some operating system. >David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
Evandro Menezes wrote: > On Jul 12, 3:21 pm, Unruh wrote: >> The way ntp works, faster polling also means worse rate estimation and >> more annoyance of the providers of the time. The current setup is done >> that way to try to minimize the rate error, so if your sconnection to >> ntp goes down, your system can freewheel with the greatest accuracy. > > But that's the issue: NTP allows for good freewheeling if it comes to > that, provided that the system maintained in STP and in a vacuum. > > In the real world, ambient temperature changes frequently even in > conditioned environments, network load affects packet jitter, etc. > And all this also affects a system's peers, compounding the issue of > NTP's slow reaction time. > > Thanks. You are certainly at liberty to write your own version of NTP and have it behave as you think best. For most of us, NTP works quite well. I suspect that an NTP equivalent designed to react instantly to events such as: the opening of the computer room door, the laser printer starting or finishing a print job, or the starting and stopping of the refrigerant compressor, would do the job far worse than we what we have now. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
On Jul 13, 12:04 pm, Unruh wrote: > > Or use the temperature controlled ntp ( reads the temp and uses that to > estimate the clock rate changes due to temp variations) Where can I find this NTP? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
Unruh wrote: [] > Use chrony. Much much faster reaction time and better clock control. > However you must be running Linux (yet another reason to change). [] Not much point in changing to Linux if all the applications I run require a different OS. For timekeeping, FreeBSD has a good reputation. David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
Evandro Menezes writes: >On Jul 12, 3:21=A0pm, Unruh wrote: >> >> The way ntp works, faster polling also means worse rate estimation and >> more annoyance of the providers of the time. The current setup is done >> that way to try to minimize the rate error, so if your sconnection to >> ntp goes down, your system can freewheel with the greatest accuracy. >But that's the issue: NTP allows for good freewheeling if it comes to >that, provided that the system maintained in STP and in a vacuum. >In the real world, ambient temperature changes frequently even in >conditioned environments, network load affects packet jitter, etc. >And all this also affects a system's peers, compounding the issue of >NTP's slow reaction time. Use chrony. Much much faster reaction time and better clock control. However you must be running Linux (yet another reason to change). It now also has harware clock support (shm refclock) in git. Or use the temperature controlled ntp ( reads the temp and uses that to estimate the clock rate changes due to temp variations) >Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
On Jul 12, 3:21 pm, Unruh wrote: > > The way ntp works, faster polling also means worse rate estimation and > more annoyance of the providers of the time. The current setup is done > that way to try to minimize the rate error, so if your sconnection to > ntp goes down, your system can freewheel with the greatest accuracy. But that's the issue: NTP allows for good freewheeling if it comes to that, provided that the system maintained in STP and in a vacuum. In the real world, ambient temperature changes frequently even in conditioned environments, network load affects packet jitter, etc. And all this also affects a system's peers, compounding the issue of NTP's slow reaction time. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp.conf file setup in netbsd
Runa Dahal wrote: > I am using NetBSD 5.0 operating system in a low powered embedded computer > used solely for the purpose of NTP. I have enabled options PPS_SYNC option > in the kernel and rebuilt it. My ntp.conf file has the following set up: > > server 127.127.20.1 > > fudge 127.127.20.1 flag3 1 refid NMEA > > server 127.127.22.1 > > fudge 127.127.22.1 refid PPS > > > I am using com2 to receive data throught the serial sevice. I have also > created symbolic links as follow to point to the serial device. > > > ln -s /dev/tty01 /dev/gps1 > > ln -s /dev/tty01 /dev/pps1 > > > I have also tried using flag1 1 to enable the PPSAPI as fudge 127.127.20.1 > flag1 1 flag3 1 refid NMEA > > > But still my ntp machine is not synchronizing , the delay, offset , jitter > values are still zero. When I run the minicom i am still able to receive > GPZDA string . I know the NMEA/PPS signals are working, because I already > have the GPS connected to a machine running fedora core 4, using gpsd to > populate NMEA and PPS values to shared memory. I have this new low power > system, and would like to move away from gpsd to maximize accuracy. So, I > know the hardware is working, and that the problem is all > software/configuration issues.I have read about using ntpd with PPS signal, > and that NetBSD does not require any patching, just recompiling kernel with > PPS_SYNC to enable kernel PPS discipline. I have see several examples > online, and I do not seem to be missing anything, and yet my system still > refuses to work. I am looking for guidance on this issue. > > When i ran the ntpd in debug mode my output was as follows > > addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled > > addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled > > addto_syslog: Listening on interface #2 re0, 192.168.0.15#123 Enabled > > addto_syslog: Listening on interface #3 re0, fe80::260:e0ff:fe46:c1f1#123 > Enabled > > addto_syslog: Listening on interface #4 lo0, 127.0.0.1#123 Enabled > > addto_syslog: Listening on interface #5 lo0, ::1#123 Enabled > > addto_syslog: Listening on interface #6 lo0, fe80::1#123 Enabled > > addto_syslog: Listening on routing socket on fd #27 for interface updates > > local_clock: time 0 offset 0.00 freq 0.000 state 0 > > addto_syslog: kernel time sync status > 0x2140 > > peer_crypto_clear: at 0 next 0 assoc ID 49312 > > key_expire: at 0 > > peer_clear: at 0 next 1 assoc ID 49312 refid INIT > > refclock_setup fd 5 modem status: 0x7 > > refclock_ioctl: fd 5 flags 0x1 > > refclock_ppsapi: capability 0x1033 version 1 mode 0x1001 kern 0 > > newpeer: 127.0.0.1->127.127.20.1 mode 3 vers 4 poll 6 10 flags 0x1021 0x1 > ttl 0 key > > refclock_ppsapi: capability 0x1033 version 1 mode 0x1001 kern 4 > > peer_crypto_clear: at 0 next 0 assoc ID 49313 > > key_expire: at 0 > > peer_clear: at 0 next 2 assoc ID 49313 refid INIT > > refclock_ppsapi: fd 6 capability 0x1033 version 1 mode 0x1001 > > newpeer: 127.0.0.1->127.127.22.0 mode 3 vers 4 poll 6 10 flags 0x1021 0x1 > ttl 0 key > > refclock_ppsapi: fd 6 capability 0x1033 version 1 mode 0x1001 > > addto_syslog: frequency initialized 20.291 PPM from /var/db/ntpd.drift > > local_clock: time 0 offset 0.00 freq 20.291 state 1 > > report_event: system event 'event_restart' (0x01) status 'sync_alarm, > sync_unspec, 1 event, event_unspec' (0xc010) > > nmea: gpsread 33 $GPZDA,211347.000,09,07,2009,,*51 > > refclock_transmit: at 1 127.127.20.1 > > auth_agekeys: at 1 keys 1 expired 0 > > timer: refresh ts 0 > > timer: interface update > > nmea: gpsread 33 $GPZDA,211348.000,09,07,2009,,*5E > > refclock_transmit: at 2 127.127.22.0 > > peer PPS(0) event 'event_peer_clock' (0x85) status 'unreach, conf, 1 event, > event_peer_clock' (0x8015) > > nmea: gpsread 33 $GPZDA,211349.000,09,07,2009,,*5F > > nmea: gpsread 33 $GPZDA,211350.000,09,07,2009,,*57 > > nmea: gpsread 33 $GPZDA,211351.000,09,07,2009,,*56 > > > I have a couple questions regarding NMEA PPS. If I am using kernel PPS > discipline, then do I not need to specify ntpd atom pps(22) driver? I know I > need to have flag3 1 flag. Can I use ntpd PPS driver instead of kernel PPS > even with NetBSD being compiled PPS_SYNC, so, that I could easily switch > being either for testing. Do I always need to specify flag1 1 since I need > PPS ? > > It would be very helpful if anyone could suggest possible reasons for this. > Thank you. > What version of ntpd are you running? That will help people who may be able to answer your questions. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Help needed
Eric Magutu wrote: > Hi, > I am having a problem with ntp. The previous sys admin installed ntp from > source on Freebsd 7.0 I am unable to correct the time on the server, > everytime I change the time it goes back to its original time. I can't find > where the ntp.conf file is located. Here is the result of ntpq -p > > remote refid st t when poll reach delay offset > jitter > == > weyoun.cord.de 193.189.251.42 2 u 220 256 17 11.310 919348. > 61.566 > wikisquare.de 129.69.1.153 2 u 217 256 17 10.335 919419. > 110.597 > alpha.rueckgr.a 94.23.200.1113 u 219 256 17 10.245 919315. > 65.508 > unknown.nifelhe 143.93.99.2522 u 218 256 174.075 919279. > 91.419 > > It is stuck 15 min behind time. Any help will be greatly apprectiated > Are you running ntpd -gN? What does you command line look like? You need the -g in case the time is off by too large an amount. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd questions - FreeBSD 5.5
David Shoulders wrote: > I have a little file server running in my basement, and since it's the > only machine running all the time, I set it up to run ntpd and provide > clock settings to my other machines. > > The machine is running FreeBSD 5.5. I installed it some years ago, and > have had no reason to upgrade it. > > Initially, I ran ntpd for a day or two to establish a drift value, then > killed it and set up a crontab entry to run "ntpd -q" every 6 hours. > This worked perfectly for 2 or 3 years. Corrections were always small > numbers of msec. > If you are going to use ntpd -q you should use ntpd -qg to allow it a large step if that is necessary. There is in any case no need to stop ntpd. It will keep going correcting your clock as long as it's running and adjusting the drift file as necessary. > Then, a few days ago, a disk failed. I replaced the disk and restored, > and everything was fine -- except that I had lost the drift file. So, I > started ntpd, let it run overnight, and looked at the drift file. It > had an obviously bogus number. The clock corrections were very large > and not getting smaller. So I put a reasonable number in ntp.drift > (based on my vague memory of the old good value -- about 100), restarted > ntpd and let it run a few hours. It seemed to be converging, so I > stopped it and reinstated the crontab/ntpd -q routine -- this time every > 3 hours. > > 12 out of 19 corrections were around 20-30 msec, but the others were > off-the-wall -- hundreds of msec. So I did some arithmetic (on the > reasonable corrections only) and adjusted the drift value. Since then, > most of the corrections have been less than 10 msec, but I'm still > getting some crazy ones -- like 1.7 seconds! > > The wild corrections are all in the same direction (-), so I don't think > the time derived from the servers is wrong. It seems as if the clock in > the PC must be taking off on wild excursions occasionally. Is this > possible? How could replacing a disk have brought this on? What am I > missing? There is no reason to run ntpd -q in a crontab. You can just keep it running and it will maintain synchronization. Do you have a particular reason not to keep it running? Are you on a dialup line to the outside? If so ntpd can keep account of that. Just use ntpd -gN and let it run. (The N is for nice). Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
