Re: [ntp:questions] ntpd[7602]: synchronized to
Date: Thu, 26 May 2011 10:16:16 -0700 From: Florin Andrei flo...@andrei.myip.org Sender: questions-bounces+oberman=es@lists.ntp.org On 05/26/2011 09:49 AM, Chuck Swiger wrote: On May 26, 2011, at 9:28 AM, Florin Andrei wrote: So, basically you're saying the quality of the NTP servers fluctuates for some reason and this machine is flipping back and forth between them? Evidently yes for your case. With only two servers, it may not be possible to find a best intersection via ntpd's variant of Marzullo's algorithm: http://en.wikipedia.org/wiki/Marzullo%27s_algorithm It's kind of what I intuitively expected. I'm a tad reluctant to tell the clients to use the entire fleet of local NTP servers, albeit they are of similar quality. These 3 clients are members of a DB cluster and it's more important to keep them in sync with each other, rather than in sync with some abstract true time. So, if some local NTP servers start wondering off and fracture the cluster time-wise, that's bad. Hence the tendency to keep the config tight and small. Using more ntp servers should greatly lessen the change of time wandering off by fixing the problem you are seeing. Right now you have two servers, If one goes bad and its time is invalid, there is no way for client to tell which is bad and different systems may choose different servers to believe, one of which is bad. This WILL cause your system to start wandering off. You really should have 4 or more servers for robustness. The normally offered good numbers are 4, 6, 7, 8. If you have multiple servers, both systems should be trusting the same set of servers and, if one does start to drift for any reason, your systems will stop trusting it and it will be out-voted by working systems. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IPv6 support for NTP - need ntp.org code archive for it
Date: Thu, 21 Apr 2011 14:19:07 -0700 From: Harlan Stenn st...@ntp.org Sender: questions-bounces+oberman=es@lists.ntp.org Wasim, Most folks use our code in their distribution. The OpenBSD project has forked its own NTP implementation, OpenNTPD. It seems to make liberal use of the standard NTP code, but they have re-done many of the security related parts of the code (or so I'm told). I have never tried OpenNTPD, but it's from the same team that gave the world OpenSSH and OpenBSD, so I trust their attention to security issues if not their ability to keep good time. (But I assume that this is just lifted from the UDel distribution). I might also mention that they have no nptv4 distribution for systems other then OpenBSD at this time. The last portable version was released five years ago. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
From: hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) Date: Thu, 17 Feb 2011 04:52:36 -0600 Sender: questions-bounces+oberman=es@lists.ntp.org In article slrnilckj1.3pd.nom...@xs8.xs4all.nl, Rob nom...@example.com writes: Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote: It would be good if someone (or someones) has actually been collecting rawstats for a long period, to serve as a baseline. Bufferbloat is a relatively new phenomenon. I'll bet it's been there for a long time. (meaning at least several years) I see delays up to 3 seconds, but only when I'm downloading a big file. I assume it's all queued up at the other end of my DSL link, but I can't prove that. When downloading a single big file causes you 3 second delays, you simply have set an insanely large TCP window. I didn't tweak anything. It's possible that my 3 second delay was while using Firefox rather than a simple download. This is a long shot, but DNS timeout is usually 4 seconds. Could there be some DNS issue? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
Date: Mon, 14 Feb 2011 12:01:56 +0100 From: Miroslav Lichvar mlich...@redhat.com Sender: questions-bounces+oberman=es@lists.ntp.org On Mon, Feb 14, 2011 at 08:44:46AM +, Rob wrote: When the users would set their TCP window to a reasonable value, the bufferbloat problem would not exist! When the TCP window is correct for the delay*bandwidth product of a TCP session, there are no packets piling up in buffers halfway, as there is a continous stream of just enough data. How do you control the delay? Do you communicate only with servers located on a circle around you and only with one at a time? What about the other computers sharing the same internet connection? I think you'll get much better results with a large window and traffic shaping configured properly. No, you probably won't. Both theoretical and empirical information shows that overly large windows are not a good thing. This is the reason all modern network stacks have implemented dynamic window sizing. As far as I know, Linux, MacOS (I think), Windows, and BSD (at least FreeBSD) all do this and do it better then it is possible to do manually. N.B. Windows XP probably does not qualify as modern. For a great deal of information on data transfer performance, take a look at http://fasterdata.es.net. It deals with issues most will never carte about as we need to move multi-gigabit flows between continents, but the basic information is appropriate to anyone moving large files using TCP. If you have been there, but not recently, it had a major re-work two weeks ago and is much more easily navigated. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] LTE (4G) to cause problems for GPS?
Article in GPS World on lab tests showing that 4G cell systems can disrupt GPS. http://www.gpsworld.com/gnss-system/news/data-shows-disastrous-gps-jamming-fcc-approved-broadcaster-11029?utm_source=GPSutm_medium=emailutm_campaign=Navigate_01_31_2011utm_content=data-shows-disastrous-gps-jamming-fcc-approved-broadcaster-11029 Detailed test information is in the PDF at: http://www.gpsworld.com/gnss-system/signal-processing/lightsquared-jamming-report-11030 On January 26, the FCC waived its own rules and granted permission for the potential interferer to broadcast in the L Band 1 (1525 MHz-1559 MHz) from powerful land-based transmitters. This band lies adjacent to the GPS band (1559-1610 MHz) where GPS and other satellite-based radio navigation systems operate. The article implies that the cell phone industry is expecting GPS manufacturers to do the filtering, and, if that is the FCC solution, it would require replacing a lot of equipment. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How to keep Linux server in Chicago and Mumbai in sync to within 5 microseconds
From: Richard B. Gilbert rgilber...@comcast.net Date: Tue, 11 Jan 2011 21:17:46 -0500 Sender: questions-bounces+oberman=es@lists.ntp.org On 1/11/2011 4:15 PM, Vikas wrote: The vendors are trying to sell me CDMA time clocks http://www.endruntechnologies.com/time-frequency-reference-cdma.htm $1375 each. Also I would need 2 time clocks one in Chicago and other in Mumbai. Is there is a easier/cost effective way ? Thanks, CDMA should work in Chicago. I'd have to look at an atlas to find out where Mumbai is. While CDMA service is readily available in most of the continental USA, it is far from being universally available. GPS satellites broadcast the time in UTC. The satellites are in line of site for most, if not all, of the world. You can purchase GPS receivers relatively cheaply. Note that you want a GPS TIME receiver! A navigation receiver necessarily knows what time it is but it is not necessarily able to output extremely accurate time. GPS timing receivers are available for $100 and up. GPS satellites broadcast time in TAI, not UTC. Currently the offset between TAI and UTC is 15 seconds. Of course, if synchronization is the issue, this is irrelevant as long as all of the time sources are the same. Most (all?) GPS and CDMA receivers should have the ability to set this offset so that they DO report UTC even though they receive TAI. This gets rather messy, at least for a while, when there is a leap second. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How to keep Linux server in Chicago and Mumbai in sync to within 5 microseconds
From: unruh un...@wormhole.physics.ubc.ca Date: Wed, 12 Jan 2011 19:25:56 GMT Sender: questions-bounces+oberman=es@lists.ntp.org On 2011-01-12, Chuck Swiger cswi...@mac.com wrote: On Jan 12, 2011, at 9:31 AM, Rick Jones wrote: Is there one big CDMA timespace that encompases the planet, or are there really several discrete CDMA timespaces that are more loosely coupled? CDMA cell towers contain GPS receivers, so they are effectively sync'ed to each other. Has anyone done tests on the cdma time signals to see how well they are actually correlated with GPS time? Are they reallywithin a few usec or a few msec or even worse? There is nothing in CDMA that would require very accurate absolute time I presume. Thus there is no real reason why they should deliver absolute time with high precision. GPS HAS to have extremely accurate absolute time to tell you where on the globe you are, and so it is easy for them to then deliver that time to you. Actually, the multiplexing technique requires that CDMA phones be synced to the towers and that the towers, themselves be synced. It's fundamental to CDMA an is why there is a requirement for GPS at every tower. This pre-dates any E911 requirement. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How to keep Linux server in Chicago and Mumbai in sync to within 5 microseconds
Date: Tue, 11 Jan 2011 15:15:31 -0600 From: Vikas kedia.vi...@gmail.com Sender: questions-bounces+oberman=es@lists.ntp.org The vendors are trying to sell me CDMA time clocks http://www.endruntechnologies.com/time-frequency-reference-cdma.htm $1375 each. Also I would need 2 time clocks one in Chicago and other in Mumbai. Is there is a easier/cost effective way ? Easier? Probably not, if there is cellular CDMA available in Mumbai. The clocks just work, but they are not cheap! (We use the Praesis Ct, which is about $200 cheaper.) If you have sky access, you can get a small Garmin GPS for under $100 and plug it into the serial port. It works fine anywhere in the world, but it does require satellite visibility and that is often not available in data centers. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Local clock - sync issue
From: Stephen Vaughan stephen.vaug...@blackboard.com Date: Mon, 8 Nov 2010 10:15:30 -0700 Hi All, Is anyone able to shed some further light on this issue? I plan to remove the LOCAL clock from ntp's configuration, but I'm still keen to know why it's defaulting to the LOCAL clock once network connectivity is down, and then ignoring any of the public NTP servers configured when network connectivity returns. It stays locked to the LOCAL clock for weeks until we actually restart it manually. Cheers, Stephen -Original Message- From: Kevin Oberman [mailto:ober...@es.net] Sent: Wednesday, November 03, 2010 3:00 PM To: Stephen Vaughan Cc: questions@lists.ntp.org Subject: Re: [ntp:questions] Local clock - sync issue From: Stephen Vaughan stephen.vaug...@blackboard.com Date: Tue, 2 Nov 2010 23:13:47 -0700 Sender: questions-bounces+oberman=es@lists.ntp.org Hi, We're having an issue with an NTPD whereby it's defaulting (or whatever the correct terminology is) to the LOCAL clock, this is occurring when one of our servers loses connectivity. We have 4 server's setup and the local clock is also configured: server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 ntpq -p output: remote refid st t when poll reach delay offset jitter == hostname .INIT. 16 u- 102400.0000.000 0.000 hostname .INIT. 16 u- 102400.0000.000 0.000 hostname .INIT. 16 u- 102400.0000.000 0.000 hostname.INIT. 16 u- 102400.0000.000 0.000 *LOCAL(0).LOCL. 10 l9 64 3770.0000.000 0.001 The issue with this is that once it defaults to the LOCAL, it doesn't sync with an external source again, until we manually restart ntpd. I'm sure this is something simple, but I'm hoping someone can assist. Patient: Doctor, it hurts when I do this! Doctor: Then don't do that. Next patient! Why do you have LOCAL in your ntp.conf? It is almost always a REALLY bad idea because it leaves the clock free-running. It is oft discussed on this list why so many software distributions include LOCAL in the default ntp.conf. They really, really should stop doing it and so should you. The real question is why you are not getting to any of the named servers in ntp.conf. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 I have no explanation, but one thing I am not clear about is whether the other serves start responding after network connectivity is restored or whether they respond but local remains the preferred peer. Once the network is restored, does 'ntpq -p SERVER' work? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Local clock - sync issue
From: Stephen Vaughan stephen.vaug...@blackboard.com Date: Tue, 2 Nov 2010 23:13:47 -0700 Sender: questions-bounces+oberman=es@lists.ntp.org Hi, We're having an issue with an NTPD whereby it's defaulting (or whatever the correct terminology is) to the LOCAL clock, this is occurring when one of our servers loses connectivity. We have 4 server's setup and the local clock is also configured: server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 ntpq -p output: remote refid st t when poll reach delay offset jitter == hostname .INIT. 16 u- 102400.0000.000 0.000 hostname .INIT. 16 u- 102400.0000.000 0.000 hostname .INIT. 16 u- 102400.0000.000 0.000 hostname.INIT. 16 u- 102400.0000.000 0.000 *LOCAL(0).LOCL. 10 l9 64 3770.0000.000 0.001 The issue with this is that once it defaults to the LOCAL, it doesn't sync with an external source again, until we manually restart ntpd. I'm sure this is something simple, but I'm hoping someone can assist. Patient: Doctor, it hurts when I do this! Doctor: Then don't do that. Next patient! Why do you have LOCAL in your ntp.conf? It is almost always a REALLY bad idea because it leaves the clock free-running. It is oft discussed on this list why so many software distributions include LOCAL in the default ntp.conf. They really, really should stop doing it and so should you. The real question is why you are not getting to any of the named servers in ntp.conf. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] systems won't synchronize no matter what
From: David J Taylor david-tay...@blueyonder.co.uk.invalid Date: Sat, 30 Oct 2010 07:30:20 +0100 Sender: questions-bounces+oberman=es@lists.ntp.org This is a FreeBSD documentation and FreeBSD comes with a pretty good default ntp.conf, much like several of you have suggested. You can find it at:http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/ntp.conf?rev=1.2.2.1.4.1;content-type=text%2Fx-cvsweb-markup It has mostly comments with just a set of 3 (yeah, I know) pool systems. -- R. Kevin Oberman, Network Engineer Kevin, Yes, I must have edited a file like that when I set up my own FreeBSD system. I would take issue with: - no drift file appears to be specified (although it is mentioned) - I had: driftfile /var/db/ntp.drift That is because FreeBSD does this in the /etc/defaults/rc.conf file (with the ability to change it in /etc/rc.conf). ntpd_flags=-p /var/run/ntpd.pid -f /var/db/ntpd.drift is in this file and can be overridden by defining the variable differently in /etc/rc.conf. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] FreeBSD 7.3, net4501, ntpd gpsd?
From: =?ISO-8859-1?Q?G=F6ran_Sandin?= gsan.n...@mailnull.com Date: Tue, 05 Oct 2010 19:59:07 +0200 Sender: questions-bounces+oberman=es@lists.ntp.org On 2010-10-05 18:48, Kevin Oberman wrote: From: =?ISO-8859-1?Q?G=F6ran_Sandin?=gsan.n...@mailnull.com Date: Tue, 05 Oct 2010 18:15:11 +0200 Sender: questions-bounces+oberman=es@lists.ntp.org On 2010-10-05 16:48, Hans Jørgen Jakobsen wrote: On Sun, 3 Oct 2010 20:29:51 GMT, Goran Sandin wrote: When I start ntpd I get these two comments in /var/log/messages: refclock_newpeer: clock type 28 invalid configuration of 127.127.28.0 failed Clock 28 not compiled into binary. /hjj OK, I suspected something like that. If I check /usr/ports/net/ntp, it shows NTP 4.2.6p1.r5 (i.e. not the same as the package I use). Make showconfig does not reveal any options to include clock 28. How do I tell the port to include clock 28 (if possible)? You need to build ntpd (or the whole port) with REFCLOCK and CLOCK_SHM defined. Thanks Kevin, but still, if I do 'make config', I only see three options; NTPSNMPD, RAWDCF SSL. How do I build the port with other options? /Göran ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions I'm sorry. I guess I was not clear. These are not options settable via the 'make config'. (I'd like it if they were, though.) They are compiler defines. You can do the defines in any of several different ways. I suggest running 'make configure' (not 'make config') and then cd to the work/ntp-VERSION directory and editing the config.h file to uncomment the line for CLOCK_SHM. Then just cd ../.. and make, make install clean -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] FreeBSD 7.3, net4501, ntpd gpsd?
From: =?ISO-8859-1?Q?G=F6ran_Sandin?= gsan.n...@mailnull.com Date: Tue, 05 Oct 2010 19:59:07 +0200 Sender: questions-bounces+oberman=es@lists.ntp.org On 2010-10-05 18:48, Kevin Oberman wrote: From: =?ISO-8859-1?Q?G=F6ran_Sandin?=gsan.n...@mailnull.com Date: Tue, 05 Oct 2010 18:15:11 +0200 Sender: questions-bounces+oberman=es@lists.ntp.org On 2010-10-05 16:48, Hans Jørgen Jakobsen wrote: On Sun, 3 Oct 2010 20:29:51 GMT, Goran Sandin wrote: When I start ntpd I get these two comments in /var/log/messages: refclock_newpeer: clock type 28 invalid configuration of 127.127.28.0 failed Clock 28 not compiled into binary. /hjj OK, I suspected something like that. If I check /usr/ports/net/ntp, it shows NTP 4.2.6p1.r5 (i.e. not the same as the package I use). Make showconfig does not reveal any options to include clock 28. How do I tell the port to include clock 28 (if possible)? You need to build ntpd (or the whole port) with REFCLOCK and CLOCK_SHM defined. Thanks Kevin, but still, if I do 'make config', I only see three options; NTPSNMPD, RAWDCF SSL. How do I build the port with other options? Oops! I just looked at config.h and I am incorrect. The right answer is to uncomment the line and change 'undef' to 'define'. Sorry. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Why does ntp keep changing my conf file?
From: Steve Kostecke koste...@ntp.org Date: 17 Sep 2010 12:34:35 GMT Sender: questions-bounces+oberman=es@lists.ntp.org On 2010-09-16, Daniel Havey dha...@yahoo.com wrote: I want ntpdate, and don't really care about ntpd. Why? ntpd is both an ntp server and an ntp client. I need an ntp server running on one node, and the other nodes connect to the first node with ntpdate ... ntpd continuously disciplines the system clock ntpdate can only apply/initiate an adjustment each time it runs. The system clock will drift in the interim. Worse yet, ntpdate may cause the time to step backwards which really screws up some stuff that makes silly assumptions about the arrow of time. Aside from the fact that ntpdate was deprecated a LONG time ago, it is really a poor way to try to sync time. ntpd or chrony would be a much better choice. Even sntp would work better. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Which version of Linux works best?
From: Chuck Swiger cswi...@mac.com Date: Wed, 10 Mar 2010 09:32:21 -0800 Sender: questions-bounces+oberman=es@lists.ntp.org On Mar 10, 2010, at 7:25 AM, David J Taylor wrote: Yes, I know it's one of those low long is a piece of string questions, but I'm now considering a dual-core Intel Atom system, which is Compatible with Linux according the the very minimal blurb I have right now. If the system is to be used purely for NTP with Linux as a serial-port GPS/PPS stratum-1 server (and, yes, I know dual-core isn't needed for that, but I might want to boot Windows-7 64-bit occasionally), and considering that I know very little about Linux, which version of Linux would the group recommend? Does it make any difference as far as timekeeping is concerned? The hardware you get matters much more than which OS or flavor of Linux you use; tweaking kernel compiler optimization flags matters even less. It would be good to look into the hardware you get in terms of support for HPET, p-state invariant TSC, or how good the ACPI timers are. I'd suggest that you simply run NTP on a uniprocessor. Disable any frequency management in the OS. This eliminates most of the major issues impacting NTP and you really don't need more than one old, slow CPU to do the job. Avoid newer, high performance network cards that do interrupt coalescing or be sure it is disabled. It will shoot the jitter between the server and clients through the roof. FWIW, all of my stratum 1 NTP servers are running FreeBSD 7 on P4 uniprocessors. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
Date: Sat, 27 Feb 2010 23:05:30 -0500 From: Danny Mayer ma...@ntp.org Sender: questions-bounces+oberman=es@lists.ntp.org unruh wrote: On 2010-02-10, David J Taylor david-tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid wrote: David Woolley da...@ex.djwhome.demon.invalid wrote in message news:hksmaf$1c...@news.eternal-september.org... David J Taylor wrote: I remember the flying of caesium or other atomic clocks round the world, and that folks had to invoke relativistic corrections. Were these better than microseconds as well? That's called Navstar (GPS) and GPS position solutions do have to include a general relativity correction to the satellite clocks. Not today's GPS, but some forty or more years ago: http://www.hp.com/hpinfo/abouthp/histnfacts/timeline/hist_60s.html 1964: The highly accurate HP 5060A cesium-beam atomic clocks gain worldwide recognition as the flying clocks when they are flown from Palo Alto to Switzerland to compare time as maintained by the U.S. Naval Observatory in Washington, D.C. to time at the Swiss Observatory in Neuchatel. The atomic clock was designed to maintain accuracy for 3000 years with only one second of error. The cesium-beam standard becomes the standard for international time. I had wondered what accuracy was obtained - i.e. how far was each nation out - and whether relativistic corrections had been needed for these flying clock tests. 1 sec/3000years is 1 part in 10^-11. The gravitational redshift is gh/c^2 (g is gravity acceln on earth, h the height of the flight, and c vel of light) which is 10^-12 -- ie below ( but not by much) the accuracy of the clock. The velocity correction is 1/2 v^2/c^2 which is again about 1 part in 10^12. Ie, both corrections are smaller (but not much) than the uncertainty in the clock rate. If the plane flew at Mach 2, rather than well below Mach 1, you could get that velocity correction up the accuracy and one would have to take special relativity into account. Since the flight probably lasted say 10 hr, which is 10 sec, th eclocks would have been out by about 1usec. Assuming that the clocks could then have been synchronized, that would mean that US and Switzerland time have been out by about 1usec. (Why they would fly from Palo Alto when the time standard is in Washington DC I have no idea). Actually the Time Standards lab for NIST are half-way up a mountain in Colorado. As a result they have to make corrections to the time to account for the difference between where they are and sea level. It's not USNO. A slight exaggeration, I believe. While the elevation of the clock must be taken into account to deal with general relativity, it is hardly halfway up a mountain. It is located in Boulder, Colorado, USA. While I failed to find the exact elevation of the clock, Boulder is at 5430 ft. (1655 m.) above sea level. While this ay sound like it is halfway up a mountain, it is at nearly the same elevation as Denver (5280 ft.) and is actually at the base of the Rocky Mountains. The clock should remain accurate to within a second for about 20 million years (assuming no adjustment is made). When the clock was moved down a floor a year or two ago, the difference in elevation and the strength of the gravitational field had to be adjusted for. Even if it was at the USNO, elevation would need to be taken into account. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Regarding NTP configuration ntp.conf
Date: Thu, 17 Dec 2009 14:24:56 +0800 From: arpit.gu...@emerson.com Sender: questions-bounces+oberman=es@lists.ntp.org Hi, I wish to know that If I am providing 2 server names in ntp.conf without prefer option then with which server my system will sync the time. I googled it I came to know that the server which has less jitter it will sync with. Other thing is both the servers are at same strand value. Can anyone please explain it. I will be thankful to you . I think you probably meant stratum instead of strand. In any case, the algorithm is a bit more complex than jitter, but it is the dominant contributor. I'm not entirely sure what you are asking, though. It sound like you found the answer. I will say that having two servers is probably the worst case. You really want three, five, or seven. Those allow for good servers to out-vote a bad server. If you only have two, there is no indication as to what the best time is. The jitter may be low, but the time may be off by a lot. If you have three servers, if one goes bad, ntp will ignore it and always pick from the servers that have about the sime time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Large offset (200 seconds) during system boot
Date: Mon, 23 Nov 2009 14:02:52 +0100 From: Nottorf, Stefan stefan.nott...@plath.de Sender: questions-bounces+oberman=es@lists.ntp.org Hello, I encountered a somehow strange problem with ntpd after system boots. We powered down a whole HP-Enclosure with HP-Blades, all running ntp 4.2@1.1570 (packaged with RedHat Enterprise Linux Server 5.1 64 bit). All of these Blades use ntp.confs like the following : driftfile /var/lib/ntp/drift server blade0 iburst version 4 peer blade1 peer blade2 peer blade3 peer blade4 peer blade5 peer blade6 The blades were running fine before the shut down, with 6 ms offset as worst synchronization (measured against a Meinberg GPS 167 Radio Clock). After completely shutting down the enclosure and rebooting the blades showed an offset of 211000 ms (+- 1500 ms). ntpq -p showed that all sources had (more ore less) the same offset. After a restart of the ntp demon (via /etc/init.d/ntpd restart) - without changing anything in the config file - everything worked fine again... This also happens if I shut down only a single blade. 1) Has anybody else encountered this behaviour? 2) Has anybody found a workaround (especially with this version of ntp)? 3) Is there a known problem, if many ntpdemons (~16) start at approx. the same time? 4) Is there perhaps some well hidden synchronization mechanism by HP that sets the time in advance (in this case to a time 211 s off...) ? I might also wait for the release of ntp 4.2.6 if this would fix this behaviour, but my customer is quite sensitive about being an early adopter (regardless of how well tested the software is). My current workaround (if it can be called so) is restarting the ntpd after the system has finished booting. Best regards, Stefan Nottorf I don't believe that this has anything to do with NTP, but is the hardware. I suspect that the HP bladeserver has a single hardware clock that is used to set the time for any blade at boot time. Unfortunately, this time is off by about 211 seconds and the system calls that would normally update the hardware clock are not doing so. This is not unreasonable when a single HW clock is used for multiple systems as one system could mess up the time for all of them if it mis-set the time. I am puzzled by one thing...where is the real time coming from? If all systems are off by 211 seconds, ntp is getting the correct time from somewhere, but I don't know where. If you have no external time source, I am confused. You mention a Meinberg, but I don't see any indication of how it fits in. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Monitor of NTP service
From: aluciani aluci...@gmail.com Date: Fri, 20 Nov 2009 05:02:07 -0800 (PST) Sender: questions-bounces+oberman=es@lists.ntp.org Hello Folks. I have several AIX Unix 5.2 serves that point to a Cisco router as the NTP time source. Is there any way I could monitor the time source and against the servers to ensure that they are in sync? Or how are others performing time source/server monitoring? Cisco routers are terrible ntp servers. I mean really, really terrible, as they prioritize the processing of NTP packets below all process switched network traffic and all routing protocols. Jitter is extreme. To directly answer your question, 'ntpq -p' should do what I think you are asking. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Problem running: ntpd -q
From: Piotr Grudzinski pi...@powersmiths.com Date: Fri, 16 Oct 2009 11:05:58 -0400 Sender: questions-bounces+oberman=es@lists.ntp.org try ./ntpd -q -c /etc/ntp/ntp.conf -l /tmp/ntp.log With ntp-dev-4.2.5p234-RC the ./ntpd -q -l /tmp/ntp.log command works fine. No need for -c /etc/ntp/ntp.conf . Do the default location of the configuration file has changed from /etc/ntp/.conf to /etc/ntp/ntp.conf? Or is it looking in both places? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Date: Mon, 03 Aug 2009 07:52:39 -0700 From: Rich Wales ri...@richw.org Sender: questions-bounces+oberman=es@lists.ntp.org My experimental stratum-1 server (using a Garmin GPS as its reference clock) continues to run stably -- albeit with an offset several msec different from the rest of my home LAN (which is synced to Stanford University's time server infrastructure). remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l28 3770.000 -0.001 0.002 PPS(0) .PPS.9 l68 3770.0000.000 0.002 *iknow.richw.org 171.64.7.115 3 u 10 16 376 10.058 -9.249 3.871 I see a couple of things here. First, almost 4 ms. of jitter is excessive for a stable, uncongested network link. I don't know what the path is from your location to Stanford's NTP server, but at 10 ms. delay, it's a few hundred miles. I suspect that the link is congested at some point and, more significantly, I suspect that it is asymmetric. NTP assumes the same delay for the return packet that it had for the request packet. If that is not the case, you will see a fixed offset. The only fix is a 'fudge' of the time for that server. If the path is unstable, even that will not work. If the congestion that is producing the jitter is pretty consistent, it will null out eventually, with a small offset it the congestion is only in one direction (which it usually is). From where I sit in Berkeley, I see the Stanford system 4.5 ms. away and a std. deviation of only .168 ms., so I suspect the congestion may be closer to you. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Local (own site) NTP servers.
From: Danny Mayer ma...@ntp.org USENET newsgroup comp.protocols.time.ntp\) questions.lists.ntp.org List-Unsubscribe: https://lists.ntp.org/mailman/listinfo/questions, mailto:questions-requ...@lists.ntp.org?subject=unsubscribe List-Archive: https://lists.ntp.org/pipermail/questions List-Post: mailto:questions@lists.ntp.org List-Help: mailto:questions-requ...@lists.ntp.org?subject=help List-Subscribe: https://lists.ntp.org/mailman/listinfo/questions, mailto:questions-requ...@lists.ntp.org?subject=subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: questions-bounces+oberman=es@lists.ntp.org Errors-To: questions-bounces+oberman=es@lists.ntp.org X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2009-07-28_09:2009-07-24,2009-07-28,2009-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-081117 definitions=main-0907280208 X-Regulatory-Partner: 1 David Woolley wrote: Richard B. Gilbert wrote: ISTR reading that the Intel 80x86 line was CISC on top and RISC underneath. I couldn't swear to it though. All I ever saw or worked with was the CISC part of it. I think that pretty much defines CISC. CISC machines are normally micro-program driven machines. They didn't used to be. However, with the VAX 8600, for example, the instruction set was implemented in microcode. So were the diagnostics for that matter. True. but that was before the time of most of the readers here. Most CISC processors after about 1972 were micro-engine based. the original PDP-11 was not, but it was soon re-engineered as the PDP-11/20 with a micro-coded processor. The PDP-11 was the last non-micro-coded system from Digital. IBM went to micro-coded systems for their main-frames about the same time as did most others. So, while CISC could be done without a micro-engine, it was onlhy the earliest of the CISC mechines that did so. All VAX systems had micro-engines including the origianl 11/780 and 11/750. Most systems before the late 60's were effectively RISC, although no one called them that. The PDP-8 instruction set was 8 basic commands, AND, TAD, ISZ, DCA, JMS, JMP, IOP, and OPR. The OPR instructions were, effectively, a micro-engine of 19 slightly more complex instructions, but all were implemented in very simple DTL logic and none took more than a single cycle and the full 27 insgtructions were simpler than most RISC processors. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Local (own site) NTP servers.
From: Thomas Laus lau...@acm.org Date: Thu, 23 Jul 2009 09:26:02 -0500 Sender: questions-bounces+oberman=es@lists.ntp.org On 2009-07-23, G8KBV g8kbvd...@googlemail.com wrote: Wonder if this will get posed, or returned to me.. Hi... Been lurking for a while. Also, been messing about trying to get a local (to me) GPS Disciplined NTP server working, based on David Taylor's work with FreeBSD, I think I have one of those configured OK, but I've got other issues with FreeBSD on that machine that sort of prevent me using it for unattended appliance use. It keeps generating system emails for the Root user, and I can't find out why! Other than its something about recovered editor files? Dave: You will probably not find a better timekeeper than using the FreeBSD machine. The resources required are very minimal compared to running any Windows version. You might try logging into the FreeBSD computer as root and reading the mail using the 'mail' command. Select the message number, after the message has been read, press the 'd' key. When all of the messages for root have been read, press the 'q' key to quit. That will clear all of root's unread messages. To redirect your syslog messages to the console instead of a file, edit the '/etc/syslog' file and point all of the entries to 'dev/console'. It is not a good idea to stop the log outputs by directing things to '/dec/null'. You might want to read some of them. The unrecovered editor sessions can be read by starting vi with the '-r' flag. This is really about using FreeBSD for a timekeeper, you really can't go wrong. Your OS related setup questions should really be directed to a FreeBSD newsgroup, they are much better at handling questions and can always point you to a website for more in depth answers. The mail is a result of the daily system cleanup-checking jobs. You can stop the jobs from running by editing /etc/crontab and commenting out the periodic lines. I would not recommend this, though. I'd suggest creating a .forward file in /root containing an e-mail address where the messages should be sent. There are usually one or two messages Sunday through Friday with an extra one every Saturday and on the first of every month. They will give you information on any system problems as well as a very useful security report. (They are pretty boring, but when they are not, it's a big deal.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
From: hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) Date: Thu, 16 Jul 2009 17:18:01 -0500 Sender: questions-bounces+oberman=es@lists.ntp.org One thing you could try would be to put your clock in a thermostatically controlled oven. I'm not talking about something you could bake a pizza in, but rather something that will keep 140 degrees F +/- half a degree. 140 is pretty warm. That will reduce the lifetime of most electronics quite a bit. Hal, I'm not sure what environment you work in, but 60C is not hot or even pretty warm. Most electronics (semiconductors) are speced to run at MUCH higher temperatures. Modern CPUs are speced for continuous operation at 90C. I have not had a laptop in several years that idled at much under 60C and none has run under any real load at under 60C. If the electronics can't handle 60C, it is junk. Real-world tests of operating servers in ambient temperatures of 40C has shown no early failure and no real problems at all. Modern electronics are simply not that delicate. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Can the line audio out of HF radio be used to sync ntp. Trying to get a cheap ($) radio method.
From: Unruh unruh-s...@physics.ubc.ca Date: Thu, 30 Apr 2009 14:24:12 GMT Sender: questions-bounces+oberman=es@lists.ntp.org Nathaniel Homier n...@universal-mechanism.org writes: Hello. I would like to know if one can use the line audio out of any old portable shortwave radio tuned to a time signal and fed via a line audio input. This would be motherboard audio. The primary reason is that I get the impression that ntp radio clocks are for sale at very high prices. The most I have to spend is about $200. I already have very nice Sony 7600G HF portable and that gets the time freq. from 2.5 to 15 very well. My computer is the new pci express and I have no serial port. If you have $200, why not get a GPS 18LVC for about $70 and pay your local radio hobbyist to install an RS232 plug and a USB poser plug. That way you wil get microsecond rather than millisecond accuracy. He says that he lacks a serial port. That leaves USB which is a terrible choice, so... Does the card really lack any serial support? While more and more mobos lack a serial connector, most still have a serial interface. (I have never seen wone that does not.) It is usually presented on a header and you can bring it out to a standard connector, usually one mounted to fit in a card slot, but having no card, so it just replaces a blank panel. There is also often a need to enable the second serial port, either in BIOS or via a jumper or switch on the mobo. The mobo documents should cover this and are a;most certainly available from the manufacturer's web site. If the card really lacks serial support, please post the make and model so people can avoid it. (And not just because of NTP.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Stick to PPS, even if the prefer server fails
From: Harlan Stenn st...@ntp.org Date: Sat, 28 Mar 2009 08:48:35 + Sender: questions-bounces+oberman=es@lists.ntp.org In article fojzl.18914$db2.8...@edtnps83, Bill Unruh un...@physics.ubc.ca writes: Harlan Stenn st...@ntp.org writes: From one POV, it seems to me that each instance of a PPS source should come with health information about that PPS instance. This health information should include the current expected precision of the PPS signal. Bill Not sure what the health info would be. The health of PPS is either Bill great, (if the seconds is good) or attrocious (if the second is bad), Bill and the driver presumably does not know this or it would have Bill corrected the seconds (remember that this is like the date being a Bill month out, if your accuracy was a second). There are at least two issues here. In one case, there can be a GPS device that may deliver a PPS second but that PPS is not really sync'd. The GPS device in this case will usually have this information ([do not] believe the PPS signal) in there. In another case, the Stanford Research PRS10 rubidium frequency standard has an RS-232 output port that has diagnostic info, including letting you know if the device is in its warming up state, which means during those 6 or 7 minutes the pulse is not yet as accurate as it should be. I suspect there are other, similar situations with other devices. Some PPS devices are stand-alone while others are combined with, say, a GPS signal. For the former case, it makes sense to treat them as separate sources of time. For the latter, it makes sense to treat the PPS signal as an adjunct device. Bill Well, I would say that the GPS is the adjunct device since the PPS is Bill far far more accurate (4 orders of magnitude). That may be, but the smarts for the driver are in the GPS side of things, not on the PPS side of things. We'd probalby want the config file to say things like I'm an XYZ refclock that has a PPS signal, instead of I'm a PPS signal that comes from an XYZ device. If the final code can handle this either way I don't care. But I figure there is a good chance it will not be that way. See http://support.ntp.org/bin/view/Dev/GettingNtpdItsConfiguration for more information. The bottom line is we need to figure out what else needs to be done to make the state of affairs with PPS sources even more generally useful. Bill Clearly the PPS needs something auxilliary to determine the Bill seconds. On the other hand, once that second lock is obtained it is Bill hard to lose it. The system clock on most computers is not going to Bill drift by 500,000 PPM (especially not most time servers). For me, the issues for a PPS source is how much can we believe the PPS signal arrives at the instant of the stroke of the second. That is a separate issue from about what time is it. Bill Now maybe I am not imaginative enough to think of what could go wrong. I know I'm not. -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions This has been a real issue for us. We have about 26 ntp servers scattered across our network using CDMA clocks. There are a few places where the signal is poor and clock will lose sync. When this happens, the PPS continues, but will slowly drift with respect to actual time. Unfortunately, even though the time from the clock is marked as unsynced and ntpd stops using that time, it continues train the time with the drifting PPS signal, so the time slowly drifts away from where it should be. Ideally, if the source of the time being trained by the PPS is bad, the PPS also should be considered bad and kernel PPS should be disabled. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Stick to PPS, even if the prefer server fails
From: Unruh unruh-s...@physics.ubc.ca Date: Sun, 29 Mar 2009 04:16:23 GMT Sender: questions-bounces+oberman=es@lists.ntp.org ober...@es.net (Kevin Oberman) writes: From: Harlan Stenn st...@ntp.org Date: Sat, 28 Mar 2009 08:48:35 + Sender: questions-bounces+oberman=es@lists.ntp.org In article fojzl.18914$db2.8...@edtnps83, Bill Unruh un...@physics.ubc.ca writes: Harlan Stenn st...@ntp.org writes: From one POV, it seems to me that each instance of a PPS source should come with health information about that PPS instance. This health information should include the current expected precision of the PPS signal. Bill Not sure what the health info would be. The health of PPS is either Bill great, (if the seconds is good) or attrocious (if the second is bad), Bill and the driver presumably does not know this or it would have Bill corrected the seconds (remember that this is like the date being a Bill month out, if your accuracy was a second). There are at least two issues here. In one case, there can be a GPS device that may deliver a PPS second but that PPS is not really sync'd. The GPS device in this case will usually have this information ([do not] believe the PPS signal) in there. In another case, the Stanford Research PRS10 rubidium frequency standard has an RS-232 output port that has diagnostic info, including letting you know if the device is in its warming up state, which means during those 6 or 7 minutes the pulse is not yet as accurate as it should be. I suspect there are other, similar situations with other devices. Some PPS devices are stand-alone while others are combined with, say, a GPS signal. For the former case, it makes sense to treat them as separate sources of time. For the latter, it makes sense to treat the PPS signal as an adjunct device. Bill Well, I would say that the GPS is the adjunct device since the PPS is Bill far far more accurate (4 orders of magnitude). That may be, but the smarts for the driver are in the GPS side of things, not on the PPS side of things. We'd probalby want the config file to say things like I'm an XYZ refclock that has a PPS signal, instead of I'm a PPS signal that comes from an XYZ device. If the final code can handle this either way I don't care. But I figure there is a good chance it will not be that way. See http://support.ntp.org/bin/view/Dev/GettingNtpdItsConfiguration for more information. The bottom line is we need to figure out what else needs to be done to make the state of affairs with PPS sources even more generally useful. Bill Clearly the PPS needs something auxilliary to determine the Bill seconds. On the other hand, once that second lock is obtained it is Bill hard to lose it. The system clock on most computers is not going to Bill drift by 500,000 PPM (especially not most time servers). For me, the issues for a PPS source is how much can we believe the PPS signal arrives at the instant of the stroke of the second. That is a separate issue from about what time is it. Bill Now maybe I am not imaginative enough to think of what could go wrong. I know I'm not. -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions This has been a real issue for us. We have about 26 ntp servers scattered across our network using CDMA clocks. There are a few places where the signal is poor and clock will lose sync. When this happens, the PPS continues, but will slowly drift with respect You mean the cdma clock will continue to deliver a PPS signal running it off an internal drifting clock? A PPS is simply a pulse every second. How does it deliver the information that it is bad? Or you know it is bad because it starts to drift with respect to other clocks you trust more? And why do you trust them more? Yes. The clock free runs and continues to deliver PPS and time from it's internal oscillator (which is quite a bit more accurate than most PC oscillators, but still drifts over a period of days). It marks the time as unsynchronized and ntpd treats it as such. It does not use it. I know it is bad because I have 25 clocks to compare with. Of those, 20 are stratum 1, so it's pretty obvious when the others show time within a few microseconds and this one is off by milliseconds after a couple of weeks or so. to actual time. Unfortunately, even though the time from the clock is marked as unsynced and ntpd stops using that time, it continues train the time with the drifting PPS signal, so the time slowly drifts away from where it should be. What refclock driver are you using? TrueTime (5) and PPS (22). The clock is an Endrun Technologies Præcis Ct. http
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
Date: Mon, 16 Feb 2009 09:38:25 -0500 From: Danny Mayer ma...@ntp.org Sender: questions-bounces+oberman=es@lists.ntp.org Uwe Klein wrote: Danny Mayer wrote: Be warned that ping uses ICMP and not UDP so the costs are different. Danny, we are looking at the physical transport layer i.e. physical link layer which does not care about protocol. Latencies on a DSL line are impacted by packet size, effective datarate, lookahead error correction and some ancilary stuff _per_ direction. Aditionally depending on configuration up and down stream utilisation can have impact on the opposite path. uwe Yes, I know all that. Nevertheless routers and the like also treat ICMP packets differently from UDP and TCP. There are lots of reasons to do so but we are getting far afield from the original question at this point. Routers treat ICMP differently when destined to the router processor, supervisor or routing engine. (These are similar things in different routers.) I know of no commercial router with hardware based forwarding that treats transit ICMP any different from transit UDP or anything else. It is possible to use CoS and multiple hardware queues to do such a thing, but I doubt it is common practice as there is little reason to do so and it is fairly complex to set up (depending on the particular router involved). But we are digressing badly from the topic at hand. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
From: cmad...@hiwaay.net (Chris Adams) Date: Wed, 11 Feb 2009 08:26:39 -0600 Sender: questions-bounces+oberman=es@lists.ntp.org Once upon a time, Richard B. Gilbert rgilber...@comcast.net said: My bet would be that there is an asymmetry in your ADSL link! If I'm not mistaken, the A in ADSL stands for asymmetric! The asymmetry in ADSL is in bandwidth, not path or latency. More frequency space is used for downstream (ISP-end user) communication than for upstream, but both travel the same path. Depending on the difference in bandwidth, that does impact latency. ntp assumes that the time from message transmission to message receipt is the same in both directions. If the packet takes longer on the wire, that is an asymmetric latency. Also, the jitter on your time is extremely high for PPS which should be 1 us. I suspect that this is a system problem, but I can't be sure. I never see this much jitter on any of our PPS synced reference clocks (of which we have about 25 scattered across the US). If the jitter on any of my reference clocks using PPS exceeds .005, I consider this a big problem. I use FreeBSD which has excellent PPS support. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
From: dhavey dha...@gmail.com Date: Mon, 29 Dec 2008 12:07:25 -0800 (PST) Sender: questions-bounces+oberman=es@lists.ntp.org Garmin specs say: The rising edge of the signal is aligned to the start of each GPS second. This means edge on assert right? So flag2 should be 0? What is going on here? On my clock (EndRun, not Garmin) the PPS is low true, so the rising edge is NOT the assert, but the rising edge at the end of the pulse. There is a difference between leading and rising. (I had to talk to an engineer at EndRun to confirm this was the case and it may not be for the Garmin.) For EndRun, flag2 is 1. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
From: alkope...@googlemail.com alkope...@googlemail.com Date: Wed, 17 Dec 2008 08:09:24 -0800 (PST) Sender: questions-bounces+oberman=es@lists.ntp.org Hi I have 2 ntp servers running Linux with LinuxPPS patch. Number one uses a Meinberg PCI511 v1.00 as time source, number two uses a Meinberg GPS170PCI v1.10. On both machines ntp is configured to use the Meinberg refclock (127.127.8.0) and furthermore the Meinberg PPS outputs are connected to the serial interfaces and use the atom driver (127.127.22.0). The strange thing is, that there is always a delay of 1-4 ms between the refclock and the pps signal. In my opinion they should arrive at the exact same time. Here is an example graph of the dcf card: http://img-up.net/img/dcf-delayY6wXrh.png Here is an example graph of the gps card: http://img-up.net/img/gps-delayHbRmW6U.png And here the ntp conf entries: DCF: # meinberg dcf server 127.127.8.0 prefer mode 2 fudge 127.127.8.0 time1 -0.003 fudge 127.127.8.0 refid DCFi # meinberg dcf-pps server 127.127.22.0 GPS: # meinberg gps server 127.127.8.0 prefer mode 7 fudge 127.127.8.0 refid GPSi # meinberg gps-pps server 127.127.22.0 Does anybody else experience this problem or know how I can fix it? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions What you see is typical and the reason you use the PPS signal. The time to process the time string from the clock is long and fairly slow. The PPS is short and fast. As the documentation states, the PPS signal trains the clock. While it is normal and not a real problem, you can use a fudge to correct this a bit, but, as long as you leave the system up and configure it reasonably, it should work fine. You should also set the GPS and PPS servers with minpoll 4 maxpoll 4. This will result in much faster convergence. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpolads4COJc.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
From: Terje Mathisen [EMAIL PROTECTED] Date: Sun, 07 Dec 2008 11:44:18 +0100 Sender: [EMAIL PROTECTED] Maarten Wiltink wrote: Unruh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] What should I be doing to get 20 us? Buy all new computers with gigabit Ethernet? I suspect buying better switches. And it looks to me like you should definitely NOT go to gigabit Ethernet if you want good timing. Seeing as how gigabit Ethernet uses jumbo frames to reach decent throughput, I suspect it's subject to higher jitter at the network level. NTP frames are short, but if it's contending with a large download, there will be a relatively large unpredictable delay on the line. I wrote a very similar msg, then I started to consider the math: 100 Mbit uses 1.5 kB packets, while Gbit jumbo frames are typically 9 kB, right? The thing is that as long as the jumbo frames are less than 10 times the size of regular packets, the wire will be busy for a shorter time than for a 1.5 K packet on 100 Mbit! Hybrid interrupt/polled hardware drivers are a much more likely culprit: If the hardware waits a little bit before interrupting, hoping to be able to bunch up several packets in a single task, then jitter will suffer badly. Before this gets too far off track, standards compliant Ethernet uses frames of 1500 bytes, regardless of speed. This is true for 10M or 10G Ethernet. Most modern cards have support for jumbo frames. These are, by definition, non-standard, and are available only when specifically configured. Unless you turn them on, frames are 1500 data bytes plus framing of up to 22 bytes. When jumbos are enabled, the size currently recommended by the US federal Joint Engineering Team is 9000 bytes to allow the transmission of 8K of actual user data when allowing for framing, VLAN and MPLS tags and such with a comfortable margin over that. (Most modern systems page memory in 8K chunks, so this optimizes performance.) So, if you have not set your card to use jumbo frames, you are not using them. You are using 1500 byte MTUs. (On a Unix system, ifconfig(1) should show the MTU.) Interrupt coalescing is available on many modern 1G or faster Ethernet interfaces. It is probably universal in any PCI-e 10G interface. It requires driver support, but is available on most modern systems. It will delay interrupts for a defined time so that only a single interrupt is needed for multiple packets. For 10GE cards, a default of about 30-60 microseconds is normal, although this is usually controllable in around 1 microsecond units. 1G cards based on Intel chips may support coalescing in similar increments, but the default delay is highly variable. This could explain some of the jitter. But the jitter introduced should be fairly low, so I doubt it can explain what is seen here. Out network uses Intel based 1G interfaces and we do not see any excessive jitter on FreeBSD. But the interrupt delay for coalescing is driver controlled and other OSes my use a greater delay. In FreeBSD, the delay defaults to 0 and may be adjusted with a sysctl. On other OSes, you will need to read the documentation to see what, if any, delay is being used. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp ports
Date: Sun, 9 Nov 2008 10:49:15 + (GMT) From: Melanie Pfefer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi What ports need to be opened if my ntp servers are inside a firewall? 123/udp -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Preffered OS for a GPS based stratum 1
From: Terje Mathisen [EMAIL PROTECTED] Date: Fri, 31 Oct 2008 08:59:06 +0100 Sender: [EMAIL PROTECTED] Spiffed wrote: I've dug up an Oncore GT+ GPS receiver, matching antenna, and PPS stretching converter box. WinOncore shows a 'Time Solution one sigma' of 38ns, so it seems to be an acceptable ref clock for my purposes. After surveying the computing hardware available, a Sun Ultra10 seems to keep the best time and is otherwise unused. What OS do you recomend for the Ultra? Off the top of my head, I'm considering Solaris (is there PPS support in Solaris 10?), FreeBSD or NetBSD. My understanding is Linux 2.6 PPS support is rough at best. FreeBSD is the canonical OS for a PPS box, search for some of phk's articles on this subject! Seconded. FreeBSD has taken ntp and timing as a priority for a very long time. I know that back in the days when BSD was still being developed at Berkeley, they counted the instructions used by the PPS kernel code and then used the clock frequency to correct the time for that delay. N.B., with any system, don't expect really good time if the CPU uses power management tools that change the frequency of the CPU while NTP is running. Your probably better off with a single CPU system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpWC4mesD4jo.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Wrong Time-settings for Australia?
Date: Tue, 07 Oct 2008 10:40:58 +0200 From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Dear Sir or Madam, Could it be possible, that the settings for the australian-region are momentarily not correct? With my Siemens Gigaset C470IP (IP-phone) i choosed Australia/Melbourne and DaylightSaving. But the Australians are a little bit earlier these days with the daylight saving. So the time differs currently by one hour! Wrong time on my C470IP : 18:39 Right time in Australia : 19:39 Could you please check your settings on the server for this region? Thomas, I'm afraid you are confused about the operation of NTP. NTP has no concept of time zones or local time. While it could, in theory, be synchronized to any time, effectively, it only knows about UTC (also, often called GMT). It is up to the local system to translate this into local time. Both Windows and Unix platforms (including MacOS) support this, but they require that the systems have accurate time zone information. You need to talk to your system admin people to get this taken care of. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
From: David McConnell [EMAIL PROTECTED] Date: Tue, 30 Sep 2008 14:04:18 +0100 Sender: [EMAIL PROTECTED] Hi We are using Linux ntpd with GPS/PPS reference clock to discipline the time on our systems. Our application requires good time accuracy (better than 5ms) but it also needs to get there quickly (as quickly as possible, but ideally taking no more than about 15 minutes). (The Linux/ntpd is running on a remote embedded device that is frequently restarted - possibly once a day or so - so we cant wait hours for convergence). Currently ntpd can take hours to achieve the desired acuracy. So, the question is simple - is there any way to significantly speedup the convergence of ntpd (using GPS/PPS reference clock)? We would be prepared to compromise somewhat on accuracy and jitter. (Currently accuracy and jitter values are excellent with jitter as low as 1 microsecond and accuracy better than 10 uS but it can take a day or two to get there). It does not seem unreasonable to expect that the ntpd could achieve the required accuracy within 15 minutes or so - but nothing we have tried seems to work. Have tried modifying some of the tinker values, but we dont really understand what they all do - and have not really had any success. So to summarise: 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference clock)? 2) If so, how - and what are the tradeoffs? Most important is to start ntpd at boot time with the -g option so that it will immediately set the time. Then adjust your ntp.conf to set the maxpoll and minpoll to 4 for your reference clock. minpoll 4 maxpoll 4 This will get the time synced to close to correct, hopefully a few microseconds, within a couple of minutes, depending on your hardware. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpvDhnJbdizH.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
From: David McConnell [EMAIL PROTECTED] Date: Tue, 30 Sep 2008 14:04:18 +0100 Sender: [EMAIL PROTECTED] Hi We are using Linux ntpd with GPS/PPS reference clock to discipline the time on our systems. Our application requires good time accuracy (better than 5ms) but it also needs to get there quickly (as quickly as possible, but ideally taking no more than about 15 minutes). (The Linux/ntpd is running on a remote embedded device that is frequently restarted - possibly once a day or so - so we cant wait hours for convergence). Currently ntpd can take hours to achieve the desired acuracy. So, the question is simple - is there any way to significantly speedup the convergence of ntpd (using GPS/PPS reference clock)? We would be prepared to compromise somewhat on accuracy and jitter. (Currently accuracy and jitter values are excellent with jitter as low as 1 microsecond and accuracy better than 10 uS but it can take a day or two to get there). It does not seem unreasonable to expect that the ntpd could achieve the required accuracy within 15 minutes or so - but nothing we have tried seems to work. Have tried modifying some of the tinker values, but we dont really understand what they all do - and have not really had any success. So to summarise: 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference clock)? 2) If so, how - and what are the tradeoffs? Sorry for the dup for everyone on the mailing list, but I need to send it unsigned to make it to the news group. Most important is to start ntpd at boot time with the -g option so that it will immediately set the time. Then adjust your ntp.conf to set the maxpoll and minpoll to 4 for your reference clock. minpoll 4 maxpoll 4 This will get the time synced to close to correct, hopefully a few microseconds, within a couple of minutes, depending on your hardware. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1222806547_81119P Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFI4owTkn3rs5h7N1ERAmQBAJ4hJZT+g/g867Jcijg6bPrhrzT9AQCeN+5k Orv1xQK+MBGU7BWQ8YXnhio= =LqU7 -END PGP SIGNATURE- --==_Exmh_1222806547_81119P-- ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Odd (mis)behavior when reference clock fails
From: Martin Burnicki [EMAIL PROTECTED] Date: Wed, 24 Sep 2008 09:24:43 +0200 Sender: [EMAIL PROTECTED] Kevin, Kevin Oberman wrote: [...] Another thought...could it be PPS that is causing it? After all, the pin on the bulkhead connector is still getting the PPS signal. I am using the kernel PPS implementation, so could that be training the kernel even though ntp is not using it? That's also what I've got in mind when I read you latest posts. Can you disconnect the PPS signal and see what's happening? Martin, We have a winner! It is the PPS. If I take that out, it syncs correctly to all of the other systems. Looks like PPS will train whatever sync source is selected, not just the reference clock. So it was reference clock drifting off time with no input signal, marking the time as inaccurate so that ntpd was ignoring it, but still sending out the PPS such which the system was still listing to via the kernel NTP_SYNC, but was training the clock without paying any attention to the validity or presence of time from the reference clock. It looks like ntpd should be disabling PPS_SYNC when the reference clock is bad, but is not doing so. Note: I am referring ONLY to the kernel using PPS_SYNC. ntpd, itself seems to not pay attention to PPS unless the reference clock is selected for sync. If I get some time, I'm going to look at the PPS code in ntpd and see it this can be done easily. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Odd (mis)behavior when reference clock fails
From: Unruh [EMAIL PROTECTED] Date: Wed, 24 Sep 2008 18:10:24 GMT Sender: [EMAIL PROTECTED] [EMAIL PROTECTED] (Kevin Oberman) writes: From: Martin Burnicki [EMAIL PROTECTED] Date: Wed, 24 Sep 2008 09:24:43 +0200 Sender: [EMAIL PROTECTED] Kevin, Kevin Oberman wrote: [...] Another thought...could it be PPS that is causing it? After all, the pin on the bulkhead connector is still getting the PPS signal. I am using the kernel PPS implementation, so could that be training the kernel even though ntp is not using it? That's also what I've got in mind when I read you latest posts. Can you disconnect the PPS signal and see what's happening? Martin, We have a winner! It is the PPS. If I take that out, it syncs correctly to all of the other systems. Looks like PPS will train whatever sync source is selected, not just the reference clock. So it was reference clock drifting off time with no input signal, marking the time as inaccurate so that ntpd was ignoring it, but still sending out the PPS such which the system was still listing to via the kernel NTP_SYNC, but was training the clock without paying any attention to the validity or presence of time from the reference clock. I at least am confused. What is generating the pps signal. I would have thought it was the hardware clock that you say is misbehaving. If so it should not send out a PPS signal at all. Or is it your computer itself that is sending out a PPS based on its own clock? In that case you certainly should NOT be using it as a source of time. The clock, for better or worse, tags the time it supplies with an accuracy character which indicates accuracy, but the lack of accuracy does not cause the PPS to stop. This includes complete loss of accuracy. The clock keeps running and keeps time, but it is now limited to the accuracy of the internal clock in the reference clock. This is what was drifting, not the system clock. It was simply dragging the system clock along for the ride. It looks like ntpd should be disabling PPS_SYNC when the reference clock is bad, but is not doing so. Note: I am referring ONLY to the kernel If the reference clock is bad it should not be sending out a PPS. Why is it doing so? Because it does. I can contact EndRun about it. I agree that it would be best if the clock stopped the PPS, but ntpd could do the same things and I see no reason that it should enable PPS_SYNC until the PPS is marked as ready and should be disabled when the PPS is no longer marked as valid. It marks the PPS validity in 'ntpq -p', so it knows whether it considers PPS valid. Why should it allow the PPS_SYNC when it has PPS no marked valid?. using PPS_SYNC. ntpd, itself seems to not pay attention to PPS unless the reference clock is selected for sync. If I get some time, I'm going to look at the PPS code in ntpd and see it this can be done easily. If that pps is really not a good pps source coming from an idependent harware time source, it should not be enabled at all. If the clock is getting a good signal, the PPS is valid. If it is not getting a signal, it is only as accurate as the internal clock in the device. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Odd (mis)behavior when reference clock fails
From: Martin Burnicki [EMAIL PROTECTED] Date: Tue, 23 Sep 2008 09:34:06 +0200 Sender: [EMAIL PROTECTED] Unruh wrote: [EMAIL PROTECTED] (Rob Neal) writes: On Tue, 16 Sep 2008, Kevin Oberman wrote: We have a fairly large mesh of NTP servers spread across the US. Almost all have PPS reference clocks and are quite accurate. Recently one of the reference clocks located across the county seems to have failed. Such is life. The problem is that the system's time started drifting and eventually became far enough out of sync with the mesh to be marked as a bad ticker. The only way I could get the clock to slew or step the time was to edit the configuration and comment out the reference clock and PPS. It looks like the system will only use the time from a reference clock when and if the clock is configured, even if it can't be read. Is there any way to fix this? What is it that you consider broken? Please clarify. I've re-read this several times, and don't see the problem. A reference clock broke. It was disregarded because it chimed badly. You expected something different? A hardware clock broke. The computer which was using that hardware clock insisted on using that hardware clock even though it gave no time. It acted as a server, and eventually its time drifted so badly everyone else saw it as a bad chimer. It seems to have had other server lines in the /etc/ntp.conf, but ignored them in favour of a non-working refclock. That is how I interpret what he said, but I may be wrong as well. This is also how I understand this. Maybe the problem occurred because either the refclock did not report its failure state correctly, or ntpd's refclock driver did not pass the fail state on to the NTP kernel, so the refclock was not discarded after it failed. It would be helpful to know the exact NTP version, and which hardware clock and refclock driver was used. Martin, It's 4.2.4p4 running on FreeBSD 7.0. The reference clock is a EndRun Tech CDMA clock using the TrueTime driver. When the system was running, ntpq claimed no successful polls of the reference clock or the PPS. It was getting good responses from other systems, but not syncing to them. The offset started small after the clock failed, about .003, and steadily grew to over 5 ms. The reference clock always showed a zero reachability, delay and offset and .001 jitter. Here is my configuration: server 127.127.5.1 prefer minpoll 4 maxpoll 4 fudge 127.127.5.1 refid CDMA fudge 127.127.5.1 time1 .011 server 127.127.22.1 minpoll 4 maxpoll 4 fudge 127.127.22.1 flag3 1 peer time1-owamp.es.net iburst key 2 peer time2-owamp.es.net iburst key 2 peer time3-owamp.es.net iburst key 2 peer time4-owamp.es.net iburst key 2 peer time5-owamp.es.net iburst key 2 peer time6-owamp.es.net iburst key 2 peer time7-owamp.es.net iburst key 2 peer time8-owamp.es.net iburst key 2 peer time9-owamp.es.net iburst key 2 peer time10-owamp.es.net iburst key 2 peer time11-owamp.es.net iburst key 2 peer time12-owamp.es.net iburst key 2 All peers are identical systems with CDMA clocks. All are firewalled so that they are not publicly visible. Here is the ntpq -p output after restoring the reference clock to the config and letting it run for a few minutes. Drift is already significant! # ntpq -p remote refid st t when poll reach delay offset jitter == TRUETIME(1) .CDMA. 0 l- 1600.0000.000 0.001 PPS(1) .PPS.0 l- 1600.0000.000 0.001 -time1-owamp.es. .PPS.1 u 17 64 1772.058 -10.335 0.038 *time2-owamp.es. .PPS.1 u 49 64 177 24.556 -10.408 0.020 -time3-owamp.es. .PPS.1 u 63 64 176 55.640 -10.337 0.049 +time4-owamp.es. .PPS.1 u 59 64 176 20.770 -10.405 0.058 +time5-owamp.es. .PPS.1 u 45 64 177 23.907 -10.406 0.014 -time6-owamp.es. .PPS.1 u 46 64 177 14.790 -10.340 0.062 -time7-owamp.es. .PPS.1 u 50 64 73 25.160 -10.381 0.022 -time8-owamp.es. .PPS.1 u 27 64 177 27.378 -10.388 0.054 -time9-owamp.es. .PPS.1 u 43 64 177 75.571 -10.118 0.067 +time10-owamp.es .PPS.1 u 47 64 177 24.068 -10.401 0.048 -time11-owamp.es .PPS.1 u 35 64 177 74.542 -10.314 0.035 -time12-owamp.es .PPS.1 u 49 64 1767.224 -10.361 0.036 -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https
Re: [ntp:questions] Odd (mis)behavior when reference clock fails
From: Steve Kostecke [EMAIL PROTECTED] Date: 23 Sep 2008 16:07:44 GMT Sender: [EMAIL PROTECTED] On 2008-09-23, Kevin Oberman [EMAIL PROTECTED] wrote: [---=| Quote block shrinked by t-prot: 40 lines snipped |=---] It would be helpful to know the exact NTP version, and which hardware clock and refclock driver was used. It's 4.2.4p4 running on FreeBSD 7.0. The reference clock is a EndRun Tech CDMA clock using the TrueTime driver. When the system was running, ntpq claimed no successful polls of the reference clock or the PPS. It was getting good responses from other systems, but not syncing to them. The ntpq peer billboard you posted shows that ntpd _has_ chosen another system as the sys_peer. See below. Yes, that is quite clear. The offset started small after the clock failed, about .003, and steadily grew to over 5 ms. The reference clock always showed a zero reachability, delay and offset and .001 jitter. ntpd has not received any data from the ref-clock. That's one problem. You may want to check the CDMA clock to make sure that it is actually working. It is NOT working. That is what started this whole thing. The clock failed and time started drifting even though it had lots of peers with working clocks. (The system in question is about 5000 kilometers away from me.) Except for the time drift, ntp seemed to be working fine. It just is not drifting the systems time and I don't understand why. The increasing drift is another issue. Here is the ntpq -p output after restoring the reference clock to the config and letting it run for a few minutes. Drift is already significant! # ntpq -p remote refid st t when poll reach delay offset jitter == TRUETIME(1) .CDMA. 0 l- 1600.0000.000 0.001 PPS(1) .PPS.0 l- 1600.0000.000 0.001 -time1-owamp.es. .PPS.1 u 17 64 1772.058 -10.335 0.038 *time2-owamp.es. .PPS.1 u 49 64 177 24.556 -10.408 0.020 -time3-owamp.es. .PPS.1 u 63 64 176 55.640 -10.337 0.049 +time4-owamp.es. .PPS.1 u 59 64 176 20.770 -10.405 0.058 Is there something about this system which is different from the other time servers? As stated, all of the servers are identical in terms of hardware and software and configuration. The only differences in the ntp.conf is that each system is missing the entry for itself. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Odd (mis)behavior when reference clock fails
Dave, The gateway chokes on signed mail and all of my mail is signed. As a result, I guess none of my messages will ever make it to the news group. :-( I'm going to TRY to get my mailer to not sign this, but it may not make it either. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From: David Woolley [EMAIL PROTECTED] Date: Fri, 19 Sep 2008 08:08:38 +0100 Sender: [EMAIL PROTECTED] Firstly, the original of this thread root has been demimed out of existence by the mail to news gateway. I thought the official line is that what went out to the mailing list was the same that which went to the newsgroup. All that remains is: [demime 1.01d removed an attachment of type multipart/signed] This can be confirmed on Google groups. Rob Neal wrote: On Tue, 16 Sep 2008, Kevin Oberman wrote: We have a fairly large mesh of NTP servers spread across the US. Almost all have PPS reference clocks and are quite accurate. Recently one of the reference clocks located across the county seems to have failed. Such is life. The problem is that the system's time started drifting and eventually became far enough out of sync with the mesh to be marked as a bad ticker. The only way I could get the clock to slew or step the time was to edit the configuration and comment out the reference clock and PPS. It looks like the system will only use the time from a reference clock when and if the clock is configured, even if it can't be read. That should not be the case. Are you sure that the clock had stopped responding and stopped providing a PPS signal? If it is still providing PPS this will be used, and other clocks only to resolve the second ambiguity. Another thing to check of is whether there was a local clock configured. This can compromise fault recovery. What we really need is the contents of the configuration file and the result of running ntpq peers. We may then ask you for the result of running ntpq rv on the system and on each of its associations. Please reply in plain text, or directly to the newsgroup, otherwise neither I nor the originator of NTP will see your reply. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Odd (mis)behavior when reference clock fails
From: Steve Kostecke [EMAIL PROTECTED] Date: 19 Sep 2008 12:21:19 GMT Sender: [EMAIL PROTECTED] On 2008-09-19, David Woolley [EMAIL PROTECTED] wrote: Firstly, the original of this thread root has been demimed out of existence by the mail to news gateway. I thought the official line is that what went out to the mailing list was the same that which went to the newsgroup. Thank-you so much for your sarcasm. It goes so far in helping to make things work better. All articles which are posted to the news-group are forwarded to the mailing list after MIME stripping (see the further discussion below). All messages which are posted to the mailing list, with a very small number of exceptions, are injected to the news group. All that remains is: [demime 1.01d removed an attachment of type multipart/signed] This occured because the OP insists on digitally signing his mailing list posts. In the past we have received numerous loud complaints which voiced strong objections to certain types of content crossing the gateway from mail to news. Vociferous complaints have been made about virtually every form of content which is not plain text. We have also received numerous complaints about undesireable content (e.g. MI5 complaints) propagating from news to mail. We have made an effort to ensure that _only_ the content and formatting which has been deemed acceptable by the participants in this news group is allowed to propagate from mail to news. Unfortunately in the _very_ few cases that something not been processed correctly we receive more complaints. So far no one, not even _you_, has come forward with any vaguely constructive suggestions. Nor has anyone displayed an interest in doing anything more than mashing their reply button. Please reply in plain text, I have directly contact the OP each time that he sends a signed message and asked that he resend the message without the signature. To this date he has failed to do so. -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions Sorry, but my e-mail system is configured to sign ALL messages. This is simply the policy. I just sent out one that I tried to over-ride that. I don't know if it worked as it's not supposed to be over-rideable. I'm doing the same with this one, so it may or may not go out. I don't deal with Usenet server software and have not for about 15 years, so I can't claim to know what state-of-the-art is, but dumping a message because of it being MIME, a standard that has been supported in most mail software for over 15 years, when the type of the mail part is test/plain, baffles me. If the gateway wants to dump the signature, that's no big deal, but I don't know why it would dump the text/plain part. The whole idea of signed clear-text was that it would just work with all software, whether it knew anything about PGP or even MIME. None the less, it's a volunteer effort and I can't really complain unless I'm willing to do it, myself, and I'm not. I guess I'll just have to live with a lot of folks not seeing my occasional messages. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Odd (mis)behavior when reference clock fails
We have a fairly large mesh of NTP servers spread across the US. Almost all have PPS reference clocks and are quite accurate. Recently one of the reference clocks located across the county seems to have failed. Such is life. The problem is that the system's time started drifting and eventually became far enough out of sync with the mesh to be marked as a bad ticker. The only way I could get the clock to slew or step the time was to edit the configuration and comment out the reference clock and PPS. It looks like the system will only use the time from a reference clock when and if the clock is configured, even if it can't be read. Is there any way to fix this? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpNkTYPUxW3b.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Let ntp server not synchronize time from other servers
From: Steve Kostecke [EMAIL PROTECTED] Date: 28 Aug 2008 15:25:31 GMT Sender: [EMAIL PROTECTED] On 2008-08-28, WANG Cong [EMAIL PROTECTED] wrote: On Aug 28, 12:49 pm, Maarten Wiltink wrote: server 127.127.1.0 fudge 127.127.1.0 stratum 14 Cool! It works! 8-) But there's a little problem, when I changed my ntp.conf, I have to wait for several minutes until it works well, if not, I got: 192.168.90.41: Server dropped: strata too high I googled a bit, and someone said this is due to the time of the server is far from correct, but it is not. See below: No. That's not the problem. Your server needs to be synced before ntpdate will consider it acceptable. The issue here is that with the configuration suggested above the current stable release of ntpd will take almost 3.5 minutes before it decides that it is synced. This is because the default poll interval is 64 seconds and ntpd requires 3 poll periods before it accepts the Undiciplined Local Clock. You may speed this process up by reducing the minpoll to 4. This sets the minumum poll to 16 seconds and reduces the sync time to ~ 50 seconds. If that is not fast enough try the current ntp-dev snap shot which, IIRC, accepts the Undiciplined Local Clock after the first poll. You may also want to try Orphan mode instead of the Undisciplined Local Clock on your server. Enable orphan mode like this: tos orphan N Where 'N' is the stratum that you want your server to operate at. It is considered good practice to use a large number (e.g. 10, or so) to prevent problems when your time-island is connected to other networks. Is there any particular reason why you won't take the time from anyone? Yes, because we want: 1. Configure the time of the server manually, no matter how wrong it is. :) So in this situation, we don't want synchronization, but still need to provide the time service to other PCs. Why do you need to do this? Please keep in mind that NTP is designed to synchronize computers to a common time-base. UTC (via WAN, LAN, or directly attached reference clock) is ubiquitous time-base because, but other time-bases may be used. NTP is not a magic black box which can produce stable clocks with out some sort of stable (usually external) reference. 2. Synchronize the time from other servers and provide service. This is very easy and works well. That is what NTP is designed for. While I'm not at all sure that this is what is wanted, if ntp uses systime_s.c instead of systime.c it will run ntp without ever looking at or adjusting the system time. Just edit the Makefile for libntp to change systime.c to systime_s.c in NTP_SRCS. systime_s.c is the simulation mode version normally used in development and debug. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpWWSozNJ6XC.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Tricking NTP's driftfile
Date: Mon, 23 Jun 2008 18:11:18 -0400 From: Steven [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] System Information: --- At work, I am configuring a system which consists of six servers (master, slave1, ... slave5) networked together but kept isolated from any external network. The ONLY time requirement is that all the systems have the same time, which does NOT need to be accurate, just consistent. All servers run RHEL4 and use ntp-4.2.0.a.20040617-6.el4. All systems: (all files owned by root unless specified) /etc/ntp.conf 644 server 127.127.1.0 server master # LINE NOT INCLUDED ON master driftfile /var/lib/ntp/drift broadcastdelay 0.08 /etc/ntp 755 /etc/ntp/keys 600: Only commented lines /etc/ntpservers644: Default (redhat time servers) /etc/step-tickers 644: slave: master, master: empty /var/lib/ntp/drift 644 (ntp:ntp): 0.0 Problem: While the master goes through its synchronization routine (~10 mins), the slaves cannot obtain the time (see below). Even after the master is responsive, the drift file is not written to. [EMAIL PROTECTED] ~]# ntpdate -d master ... 192.168.1.1: Server dropped: strata too high ... 23 Jun 17:28:33 ntpdate [3343]: no server suitable for synchronization found OK. Why is it taking ~10 minutes to sync? This one I see fairly often and I don't understand it. My systems typically are synced and available for use in 3 minutes. Do you use iburst and -g? If so, that should get the master synced very quickly and your clients should be able to start their own sync, also using iburst. I have not been following this thread, so this my already have been discussed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpp09eEaYpZA.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] question about DST
From: Unruh [EMAIL PROTECTED] Date: Fri, 30 May 2008 20:10:19 GMT Sender: [EMAIL PROTECTED] [EMAIL PROTECTED] (Asrai khn) writes: Note: please reply to me direct as i am not subscribe to mailing list. It is not a mailing list, it is a news group. Keep coming back for information. No. It is both a mailing list and a news group. A great many of us have abandoned usenet and read this via the mail list. I assume Asrai sent his question to the mail list. You read it via the news group. Since you ignored his request to copy him, he will never see your response of: 1. Is it possible to adjust only the ntp server for DST thing and let all other machines automatically get the new time from ntp server? No. NTP knows nothing about DST. It operates in UTC. 1.1. If not do I have to adjust all machine clocks manually? What operating system? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpm2KWNLJaXL.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Getting PPS on a modern rack-mounted server?
Date: Thu, 29 May 2008 15:10:35 -0400 From: John Ioannidis [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] This may sound like an embarrassment of riches, but here is my problem: I have some rack-mounted servers (IBM System x3650 to be precise) that I need to synchronize with a PPS signal. The problem is, of course, that the machines have only one serial port, which I want to use as a serial console, and of course they have no parallel ports. Any suggestions? Can I use a PCI serial card? Will that have acceptable jitter? John, You may not need a PCI serial card. Almost all rack-mount system with a single serial port also have a header for the second serial port. I have many of these, though they are SuperMicro, not IBM. The physical connector is a a bulkhead plate that fits in the same place as a PCI card would be mounted. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpJ3otSGBWKt.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
the system to maximize the time spent in C3 and below by trying to schedule as many tasks as possible at the same time. The power savings can, again, be very significant and server owners are pushing to make this work as well as possible since power (both electrical and cooling) have become the primary expense in collocation facilities. Unfortunately, it looks like this will require some re-thinking of how ntp operates as keeping a server running at higher power levels to keep ntp happy will hit the owners of these systems right in the pocket books. I am not a ACPI guru by any means and I don't fully understand all of the details. I certainly don't understand all of the inner workings of ntp. I just hope this helps clarify what people are talking about. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpc7gVIQJluo.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Cheat Sheet
Dave, Not really strange. The Ct is an old design from EndRun that is very small and allows the server to run additional software. The latter is the reason we continue to deploy the Ct. (Just bought 10 more and are about to order another 10.) The systems to which these clocks are connected need to also run OWAMP http://e2epi.internet2.edu/owamp/, a one-way ping tool. It is only as accurate as the times on the client and server, so we need single digit usec. sync between the systems which are scattered all over the country. It's quite nice to have a tool that tells you that a circuit has moved from working to protect because you can see the propagation time increase by 40 usec. and we can do exactly that. It is a key part of our high performance network monitoring system. That is why we have found the Ct to be the ideal unit for our purposes. It can emulate several different clocks including TrueTime and Trimble Palisade, but, in our testing, we concluded that Either TrueTime or Spectracom emulation with PPS kernel support provided the most accurate and stable time. In any case, thank you for the information. While I've been working with NTP since at least V2 days, I won't claim to really understand all of the gory details and some of the non-intuitive behaviors. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From: David L. Mills [EMAIL PROTECTED] Date: Thu, 08 May 2008 03:21:49 + Sender: [EMAIL PROTECTED] Kevin, Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4 works for you use it. That's a pretty grotty driver with all kinds of bandaids to deal with long forgotten radios; I wonder why EndRun chose that driver... Dave Kevin Oberman wrote: Dave, Thanks for the quick response, but I guess I failed to make one point clear. EndRun supplies only the hardware. It is the Ct which as only a serial interface which is plugged into a standard COM port on the server. They don't provide any software at all. The clock just provides the time string every second (with an offset of about 10 ms. and jitter in the area of 3-5 ms.) and a very accurate PPS which allows us sync within about three usec. (The clock spec is better than ten usec, but three seems the norm.) I am running 4.2.0-a using the stock TrueTime and PPS drivers. The FreeBSD kernel has PPS support included, so any filtering in the TrueTime driver should be of little or no impact. I am assuming than as long as I am using PPS and training the TrueTime source, a minpoll of 4 is reasonable and I just wanted to make sure that I am not wrong in doing this. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions pgpP0MHLiraWr.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Cheat Sheet
Dave, Thanks for the quick response, but I guess I failed to make one point clear. EndRun supplies only the hardware. It is the Ct which as only a serial interface which is plugged into a standard COM port on the server. They don't provide any software at all. The clock just provides the time string every second (with an offset of about 10 ms. and jitter in the area of 3-5 ms.) and a very accurate PPS which allows us sync within about three usec. (The clock spec is better than ten usec, but three seems the norm.) I am running 4.2.0-a using the stock TrueTime and PPS drivers. The FreeBSD kernel has PPS support included, so any filtering in the TrueTime driver should be of little or no impact. I am assuming than as long as I am using PPS and training the TrueTime source, a minpoll of 4 is reasonable and I just wanted to make sure that I am not wrong in doing this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From: David L. Mills [EMAIL PROTECTED] Date: Wed, 07 May 2008 21:38:40 + Sender: [EMAIL PROTECTED] Keven, The TrueTime driver that lives here supports all known TrueTime receivers, including GPS, WWVB and GOES. I strongly suspect one or another of those receivers would not work if the poll interval was tinkered. EndRun apparently has cloned most or all that driver and may have modified it. If they recommend minpoll 4, run that end. Dave Kevin Oberman wrote: From: David L. Mills [EMAIL PROTECTED] Date: Wed, 07 May 2008 19:51:20 + Sender: [EMAIL PROTECTED] Heiko, Be careful when making generalizations about refclocks. Some, including the Spectracom, Austron, Traconex, TrueTime and others using the median filter will not workproperly at other than default poll. Same for the modem and audio drivers. I assume that this is driver, not device specific. server 127.127.5.1 prefer minpoll 4 maxpoll 4 fudge 127.127.5.1 refid CDMA fudge 127.127.5.1 time1 .010 server 127.127.22.1 minpoll 4 maxpoll 4 fudge 127.127.22.1 flag3 1 What about the PPS driver when used with one of these? I use EndRun CDMA clocks emulating TrueTime with PPS and EndRun recommends a MINPOLL and MAXPOLL of 4. Is that bad advice in such a configuration? If it is significant, I use FreeBSD on all of my ntp servers. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions pgpdE5Ur4TpuA.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
From: David Woolley [EMAIL PROTECTED] Date: Wed, 12 Mar 2008 08:11:23 + Sender: [EMAIL PROTECTED] Unruh wrote: that is why there is a proposed file system standard. Log files in /var/log/ntp say. Drift file in /etc/ntp.drift config file in /etc/ntp.conf I think they were referring to the Linux filesystem standard, and one of the things that does is to move things out of /etc. In particular, /etc/ntp.drift would never be allowed, because the file is updated dynamically. Incidentally, a specimen configuration needn't include real server names. Many systems mount root read-only for security reasons (and /etc is in the root partition. As a result, most systems all files that need dynamic writes (like the drift file) to an appropriate place in /var. In the case of FreeBSD, this is done by running ntpd with the command line options of -p /var/run/ntpd.pid -f /var/db/ntpd.drift. No ntp configuration file is distributed with the system, but the drift file is moved to a much better location. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpKH8OXr6N48.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
From: Harlan Stenn [EMAIL PROTECTED] Date: Thu, 06 Mar 2008 06:33:17 + Sender: [EMAIL PROTECTED] iburst is good. burst, very likely not. In general, I agree, but the context is for a connected reference clock. I would set maxpoll to 4 as there is no reason NOT to update from the reference clock on a frequent (16 second) basis, but I'm less certain if iburst is really appropriate. (Nor am I sure that it's inappropriate.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp7qYPwp0j6N.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Leap second functional question
Date: Fri, 22 Feb 2008 17:55:04 -0500 From: Danny Mayer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] David Woolley wrote: Evandro Menezes wrote: Aren't you confusing UTC and GMT? Or maybe I'm the one confusing both... Nearly everyone confuses UTC and GMT. GMT is an obsolete name for UT1, or something close, but the BBC still uses it to, incorrectly, mean UTC. That's actually not true. GMT exists in the UK as the local time zone reference name. GMT was renamed UTC for mostly political reasons. GMT follows UTC but it isn't an incorrect reference. Are you really sure? I've always read that GMT is UT1, not UTC. I just read the article on wikipedia and it seems to agree that GMT is UT1. Of course, UT1 is always within 1 second of UTC. In any case, the definitions in the various Wikipedia articles (UTC, UT, and GMT) all agree with what I learned dealing with timing issues in the past, although both those folks (the ones in Boulder, Colorado) and Wikipedia could be wrong. The article also states that UTC does not always have 86,400 seconds in a day, although POSIX specifies that a day is always 86,400 seconds long. If anyone can provide a reference from one of the real standards specifications, I would appreciate it. (If it does not match with the information I have received form the NIST folks in Boulder, I'll be very surprised.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpu53Lp8C8Fz.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Configuring FreeBSD 6.2 for use with Garmin GPS18 LVC
From: David J Taylor[EMAIL PROTECTED] Date: Sat, 15 Dec 2007 07:20:47 GMT Sender: [EMAIL PROTECTED] Kevin Oberman wrote: [] The idea David Taylor is putting forth is to create a very short kernel config file named PPS containing only the lines: include GENERIC ident PPS-GENERIC options PPS_SYNC Kevin, I wish it were my idea, but it's actually from Harlan Stenn. I've updated my Web page with both your and Harlan's comments. Actually, this general suggestion goes back quite a ways in the FreeBSD community. I know it goes back to at least V4 days as a way of not having to continually edit configuration files as the kernel changes. If was used back in 2002 for SMP kernels. The file is almost identical to the one for PPS except it has options SMP and APIC_IO. There may be even older cases. It's a good idea and the addition of NOPTION and NODEVICE configuration statements make it pretty universally usable. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpGWafb32Pvm.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd crashing on startup
From: Ulrich Windl [EMAIL PROTECTED] Date: Tue, 06 Nov 2007 15:27:23 +0100 Sender: [EMAIL PROTECTED] Steve Kostecke [EMAIL PROTECTED] writes: On 2007-10-10, Rob [EMAIL PROTECTED] wrote: On Tue, 09 Oct 2007 21:32:02 -0400, Rob wrote: When I reboot, my ntpd server now crashes. Here is the ntp.log: 9 Oct 21:16:13 ntpd[3800]: crypto_setup: random seed file //.rnd not found //.rnd would be in your / I have found it helpful to specify the location of the randfile: crypto randfile /dev/urandom Shouldn't it be /dev/random? (Urandom is not truely random AFAIK) /dv/urandom used to be less random, but not pseudo-random. I am not expert on Linux, for FreeBSD has saved entropy across boots for a long time so that you never have /dev/random run out of numbers. On FreeBSD, there is no longer any difference between /dev/random and /dev/urandom. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpAxfz2LrCTU.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] How do I know my GPS-based NTP server is actually working properly?
Date: Wed, 31 Oct 2007 13:19:46 -0400 From: John Ioannidis [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Yes, I know this sounds weird. I've successfully set up my NTP server: an old 850MHz P3 box running FreeBSD 6.2-STABLE (kernel built with option PPS_SYNC), and a Garmin GPS-18LVC hokey puck, powered off the USB port, with its PPS wire connected to the serial port's DCD line (pin 1 on the DB9 connector). /etc/ntp.conf reads: server 127.127.20.1mode 1 prefer fudge 127.127.20.1time1 0.000 flag3 1 refid PPS So far so good. It seems to be keeping time and synchronizing to GPS. But... What's the proper way of telling whether the PPS signal is actually having an effect? That is, what behavior/measurements would show me that the PPS signal is or is not being used? What should I be monitoring (my guess would be offset and jitter from the netq -c rv output), and what kind of statistical analysis would tell me whether PPS is or is not being used? Thanks, /ji PS: the easy way to disable the use of the PPS signal is to set flag3 to 0, right? Reloading a kernel and rebooting is a bit of a pain on antiquated hardware. On FreeBSD for PPS you want something like this: server 127.127.5.1 prefer minpoll 4 maxpoll 4 fudge 127.127.5.1 time1 .010 server 127.127.22.1 minpoll 4 maxpoll 4 You will probably want to add a time fudge once you see how much the processing delays the update of the data from the GPS. It is variable, depending on the speed of the system, but probably around .01 sec. For connected reference clocks the minpoll and maxpoll should be short, hence the value of '4'. The refid should be 'GPS', not 'PPS'. (Actually, it shouldn't be needed at all. It should default to GPS.) Once you have PPS configured, you should see: remote refid st t when poll reach delay offset jitter == +NMEA GPS(1) .GPS.0 l4 16 3770.0000.190 1.929 oPPS(1) .PPS.0 l 12 16 3770.0000.005 0.002 I'm guessing on the content of the 'remote' field for clock 20. The 'o' on the PPS line indicates that it is 'training' the value of the associated clock. Make sure that your ntpd is built to include the needed drivers. By default FreeBSD does not build the drivers. You need to re-build ntpd with CLOCK_NMEA defined. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpdf0X2phnlR.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] How do I know my GPS-based NTP server is actually working properly?
Date: Fri, 02 Nov 2007 12:25:46 -0400 From: John Ioannidis [EMAIL PROTECTED] Thanks for the reply, but this is not answering my question. I wasn't asking how to *configure* the beast (I've already done this successfully), I was asking how to verify that it actually works as documented! What measurements do I have to take that will show the difference between a setup that's actually using the PPS signal from the GPS receiver and one that's not (because, for example, the DCD line on the motherboard is cracked, to give a stupid example). I guess I was not clear. 'ntpq -p' will provide the output I showed and this will tell you whether the PPS is working. (Note: I don't see that it will as your configuration is not correct.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpaYLRWzSPbq.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is it possible to run ntpd server behind a firewall?
But why the following entry exists in /etc/services file? ntp 123/tcp # Network Time Protocol It has been the policy of IANA/ICANN for some time for protocols to be assigned in tcp/udp pairs even if the protocol uses only one of them. This is wasteful of a scarce resource, but eliminates a lot of confusion. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp18PFX15bnu.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] WiFi NTP.
Kevin Oberman wrote: From: Richard B. Gilbert [EMAIL PROTECTED] Date: Thu, 30 Aug 2007 10:45:01 -0400 Sender: [EMAIL PROTECTED] Maarten Wiltink wrote: Guy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Something important I forgot to mention is that my goal is not to have the most precise absolute time but to have the smallest offset as possible on a local network and using a WiFi connection. So I declared one of my devices as an NTP server and the other as a client (syncing to a single time source as a matter of fact). The 'problem' with that is that you are then at the mercy of the stability of your server. The stability of the crystal that ultimately drives a local clock reference isn't great, it's quite temperature- dependent. On the other hand, it _is_ quite predictable - people have produced graphs where it is clearly visible when the airconditioning in the server room started up, or when doors and windows were opened. The lesson as I read it is to make sure your server has a stable environment. If the motherboard temperature is constant, so will be the crystal speed. However, you are surrounded here by some rather hardcore geeks, who read the lesson differently as requiring that you have the One True Time, and stability will naturally follow from it. Groetjes, Maarten Wiltink Let's hear it for The One True Time! And which time is that? UTC, GMT, TAI, ...? UTC! I hate leap seconds!!! Leap seconds do not affect my daily existence. My computer takes care of them. Sorry, but that is beyond the capability of computers. It takes astronomers to determine when one is needed and humans to teach the computers and other equipment. Only your 'one true time', UTC has this problem. GMT continuously adjusts (also ugly) and TAI makes no attempt to stay in sync with the earth. Note that GPS has no concept of the leap second There is a mechanism for handling this, but at some level, it requires human intervention. NTP is nice because it means that YOU don't personally have to deal with them, but some of us do and it is a royal pain. After the last one it was over a month before all of the CDMA and GPS systems I sync against to adjust their times, so I had to adjust my stratum 1s twice, once after the second was inserted and then, one at a time as the carriers got around to them. It is all made worse because POSIX does not do leap seconds. To do it right, a system as to be able to run one 61 second minute and POSIX makes this impossible, so there is no really accurate way of making most computers do leap seconds. Assuming your stratum 1s are properly handling leap seconds, NTP has to drift the time, so it is off by quite a bit for quite a while. As I said, I hate leap seconds. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpy2tPsoWNJC.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] FreeBSD refclock error
Date: Tue, 14 Aug 2007 14:05:40 -0700 From: David Newman [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/07 5:51 AM, Jason Rabel wrote: ACK, thanks also for these tips. Next newbie question: Is .GPS. the correct refid I should see? lancelot# ntpq -p remote refid st t when poll reach delay offset jitter = *time.domain.tld .GPS. 1 u 33 64 3770.746 -40.803 20.547 The 'refid', in this case 'GPS' is the source which time.domain.tld is synced to. If it was synced to another NTP server then it would list its IP there. You really should use more than one server to sync to... 4 is generally the recommended minimum. Thanks. Yet more newbie questions: 1. Is it better to (a) list 4 sources on the box with the GPS receiver attached and just one source on all client boxes that point to it for ntp, or (b) list 4 servers on all boxes? b) It's always best to have 3 (or more) servers for any box running ntp as it allows the detection of broken servers and helps retain stability in the event the stratum 1 server has a problem. 1 is a bad number as it is a single point of failure. 2 is a bad number as it provides no clear way of detecting who is wrong if the time starts drifting on one of the servers. 2. If (b) should I use the prefer directive to query the GPS-based server first? No reason as it is stratum 1 and lower stratum clocks (and 1 is the lowest) are always preferred over stratum 2 or higher. If you have both your GPS and an external stratum 1 server, you might want to prefer the internal one, but it would most likely be preferred anyway as it would likely have lower delay (latency) and jitter. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp4QTstfii6D.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] FreeBSD refclock error
Date: Sun, 12 Aug 2007 17:05:32 -0700 From: David Newman [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/06 10:46 PM, Terje Mathisen wrote: David Newman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Wollman wrote: In article [EMAIL PROTECTED], David Newman [EMAIL PROTECTED] wrote: refclock_newpeer: clock type 26 invalid This is with the stock install of FreeBSD; I didn't install ntp from ports, and I have not recompiled the kernel. (If I do need to recompile the kernel, please let me know what option(s) to use.) You need to recompile ntpd. FreeBSD ships ntpd by default without refclock drivers. - From ports? From source? Either way, where do I spec compile-time option(s), and which option(s) do I need for the 58503A? 'Use the Source, Luke!' I.e. by all means grab the official distribution from http://www.ntp.org/ ! FreeBSD is pretty much _the_ preferred platform for the reference installation. Apologies for what is basically a FreeBSD question: How to ensure that the ISC distro and not the one included with FBSD gets started on boot? Some 11 months after the above thread I finally got around to grabbing the ISC source and building it to support an HP 58503A GPS receiver as a refclock. The good news: The ISC build installs into /usr/local/bin/ntpd and sees the HP receiver just fine. Now the problem: The startup script in /etc/rc.d/ntpd points to the existing binary in /usr/sbin/ntpd. Even if I edit the rc.d file (a bad idea, since I presume the script may be overwritten during upgrades), the script still calls /usr/sbin/ntpd and not the ISC version that's in /usr/local/bin. Again, apologies for the FreeBSD-for-dummies question, but what's the right way to get the ISC version to start each time this system reboots? Do I just take the ntpd_enable out of rc.conf and add my own stuff to rc.local? This is for ntpd 4.2.4p3 on FBSD 6.2-RELENG on i386. If you install the ntp port, you will get 4.2.3p51. It will install all files in /usr/local unless you set up the environment to do otherwise. To make this the ntp that will be run, edit /etc/rc.conf to contain: ntpd_enable=Yes# Run ntpd Network Time Protocol (or NO). ntpd_program=/usr/local/sbin/ntpd # path to ntpd, if you want a different one. That should do the trick. I also recommend marking some high-stratum servers as 'iburst' so your initial time sync will be fast and setting ntpd_sync_on_start=YES in /etc/rc.conf. If you do this, you should not enable ntpdate (which is deprecated). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpXldH7Cg7v6.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
