Re: [ntp:questions] losing time fast
Yeechang Lee wrote: So everyone should use pool.ntp.org? No 0., 1., 2., or ch., ca., us. prefixes? I don't see any significant reason not to use those, with country / region prefixes. http://www.pool.ntp.org/en/use.html What about the distribution-specific prefixes, like 0.centos.pool.ntp.org? Are they also obsolete? Those are the same as 0.pool.ntp.org AFAIK; they just help the pool track vender usage, and perhaps curtail abuse easier. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Terje Mathisen wrote: Roger wrote:
Rob nom...@example.com wrote:
The pool DNS server, when you use pool pool.ntp.org
or server pool.ntp.org, lookup your IP address in a
location database and give you a server from the country
you are residing in.
I get angry when a statement is made which can easily be shown
to be incorrect. What is your source for that statement?
This might be correct for the US, but definitely not here in Norway:
Its supposed to return geographically relevant servers,
but in practice, they are from all over the world when doing
queries in the US too {tried several corp, and ISP nearby resolvers}.
When pool pool.ntp.org get used, (as opposed to several server
pool.ntp.org),
and hand picked local servers (corporate, ISP MAE, ...) and/or local refclocks,
it seems like after running for a long time, the discarding and grabbing more,
results in the remaining being closer via the net;
Although I can see that might not be the case,
if your server didn't churn through pool servers very often.
If you use the pool command, compare your peerstats log files,
from the first day after a restart, till now.
Look them up with:
http://www.pool.ntp.org/scores?
www.maxmind.com/app/locate_demo_ip?ips=
...
ip4r.origin.asn.cymru.com
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Rob wrote: The pool DNS server, when you use pool pool.ntp.org or server pool.ntp.org, lookup your IP address in a location database and give you a server from the country you are residing in. No need to use uk. or nl. anymore, that is only a leftover from the past. So everyone should use pool.ntp.org? No 0., 1., 2., or ch., ca., us. prefixes? What about the distribution-specific prefixes, like 0.centos.pool.ntp.org? Are they also obsolete? -- URL:http://www.pobox.com/~ylee/ PERTH * ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-13, Fritz Wuehler fr...@spamexpire-201207.rodent.frell.theremailer.net wrote: Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: a) Stop ntpd (as mentioned above) b) check the config file to make sure it's configured to use a drift file, and find the location of it Did that, and everything appeared normal. c1) set both minpoll and maxpoll to 6 (64 seconds) if polling the internet c2) set both minpoll and maxpoll to 4 (16 seconds) or 3 (8 seconds) if polling the LAN or a GPS Did not know about these parameters, will read the man page and adjust. d) delete the drift file (as mentioned above) e) find the startup script for ntpd, which might be in the /etc/init.d or similar folder, is probably named NTP, and see what parameters it uses, and make a backup of it f) edit the startup script with elevated privileges (ie sudo, if applicable) g) insert the parameter (which I cannot remember the letter of) which allows ntpd to step the time at first This is the default but thank you for mentioning it. h) save the startup script i) sync to a national time standard server for his country 3 times in quick succession with ntpdate set to make a step change (In the USA, I would use NIST.) I have been using asia.pool.ntp.org j) start ntpd back up k) let if run several hours l) this should set a valid drift file and reign in the clock speed fairly rapidly m) stop ntpd n) reset the startup script to the way it was unless you want to leave the step command in there o) reset the config file for the original minpoll and maxpoll Was taking the defaults. p) restart ntpd Hopefully after a few more hours of running, the clock will be stable. You can even put the stop ntpd, ntpdate, ntpdate, ntpdate, start ntpd sequence in your own script and run that for greater speed and accuracy of the ntpdate sequences and minimal delay restarting ntpd. Unfortunately, this did not help. I tried all manner of corrections without rebooting the box and I finally decided to do that and I am now syncing to other machines in my network and all is fine. However since those other machines have essentially the same ntp.conf as the one with the problem and since they are all using the exact same server pool I do not understand why rebooting the PC helped. I will revert to my original ntp.conf on the problematic PC and see if it does it again. Thanks for your post. Fritz As I mentioned, one possibility was that for some reason your machine totally screwed u p the calibration of the system clock. That occurs on bootup. So, one possibility is that on bootup now, the system calibrated properly. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-13, E-Mail Sent to this address will be added to the BlackLists Null@BlackList.Anitech-Systems.invalid wrote: unruh wrote: Fritz Wuehler wrote: That's all very nice but it says on the ntp.org page to use a national server if you have one. Mine happens to not be very good but that doesn't mean I shouldn't use it if it was good. No idea where it says that, but if it does it is bad advice in your situation. IF you are a server for a bunch of other machines that really need accurate time (eg stock traders, airlines,etc) then it might be good advice. For a home user who has spent no time trying to figure out what his requirements are who sits on an adsl line say, it is terrible advice, since it clogs up the national server. Geographicly Local Pool Servers (of any stratum): http://www.pool.ntp.org/en/use.html ... BlockQuote As pool.ntp.org will assign you timeservers from all over the world, time quality will not be ideal. You get a bit better result if you use the continental zones (For example europe, north-america, oceania or asia.pool.ntp.org), and even better time if you use the country zone (like ch.pool.ntp.org in Switzerland) - for all these zones, you can again use the 0, 1 or 2 prefixes, like 0.ch.pool.ntp.org. /BlockQuote ... Clearly a total miscommunication. I had thought that you were advocating using a server like nist.org, a national stratum 1 primary timeserver, when you were advocating using the pool local to your own country. I certainly have no objection to the latter. It is good advice ( although some have said it occurs automatically now). So, if that is what you meant, I totally withdraw my objections. Hand configuration of Stratum One Servers (instead of, or in addition to pool servers): http://support.ntp.org/bin/view/Servers/RulesOfEngagement BlockQuote As the load on the hosts supporting NTP primary (stratum 1) time service is heavy and always increasing, clients should avoid using the primary servers whenever possible. Precisely what I was trying to say. In most cases the accuracy of the NTP secondary (stratum 2) servers is only slightly degraded relative to the primary servers, and as a group, the secondary servers may be just as reliable. As a general rule, a secondary server should use a primary server only under the following conditions: The secondary server provides synchronization to a sizable population of other servers and clients on the order of 100 or more. The server operates with at least two and preferably three other secondary servers in a common synchronization subnet designed to provide reliable service, even if some servers or the lines connecting them fail. The administration(s) that operates these servers coordinates other servers within the region, in order to reduce the resources required outside that region. Note that at least some interregional resources are required in order to ensure reliable service. /BlockQuote ... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 12/07/2012 20:56, E-Mail Sent to this address will be added to the BlackLists wrote: I didn't see anything that would allow ntp to runaway. Fritz Wuehler wrote: # Sample /etc/ntp.conf: Configuration file for ntpd. server 0.asia.pool.ntp.org server 1.asia.pool.ntp.org server 2.asia.pool.ntp.org server 3.asia.pool.ntp.org If you use a more recent version Dev 4.2.7p288, (instead of 4.2.4p7 from May 2009); You can replace those 4 lines with something like: pool asia.pool.ntp.org preempt iburst restrict source nomodify NTP will automatically add servers (up to maxclock), and as it drops some, it will add more; eventually, you will likely end up with a clique of servers that have lower offset to you, and are also close in time to each other. [] Two questions (if I may) about the pool command: - is the preempt needed, or is it implicit in the pool command? - can one have multiple pool commands? For example, at the moment on one widely travelled PC I have: server 0.uk.pool.ntp.org iburst server 1.uk.pool.ntp.org iburst server 2.uk.pool.ntp.org iburst server 0.nl.pool.ntp.org iburst How would that best be replaced? Something like the following, perhaps? pool uk.pool.ntp.org iburst pool nl.pool.ntp.org iburst Is ntp clever enough to allocate servers from a mix of the two pool commands? Thanks -- David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-13, Fritz Wuehler fr...@spamexpire-201207.rodent.frell.theremailer.net wrote: unruh un...@invalid.ca wrote: On 2012-07-12, Anonymous nore...@breaka.net wrote: Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: Hi Unruh, I'm glad you like the suggestions. You may be right about the drift file. I don't know for sure what caused the runaway clock I experience in the past. However, it's my understanding that NTP sets the computer clock frequency to what it finds in the drift file at startup. If the drift file is way off, for whatever reason, then the initial clock frequency will be way off. As far as I know, it won't write another drift file for an hour. So, during that hour, particularly if the polling interval is long, the clock can be running so fast or slow that it will drift so far out that NTP might just give up on it. That may have been what happened because the drift file looked normal to me when I checked it but the clock was just getting worse and worse, as if ntp wasn't running. ntpdate sometimes fixed it but it would start drifting very quickly in huge amounts, minutes until it was 45 or more minutes off. Why a national time server? No need for that kind of accuracy. As long as we are all interested in precise and accurate time, every possible improvement that's easy to make should be worthwhile. Unfortunately I live in a country with erratic local time servers so I use the asian pool that has been mostly ok as far as I can tell. Nuts. If you are interested in accurate time, you examine your error budget and find the places to make fixes. You do not impose yourself on others (the national time standards) using up other's scarce resources to make correction which change your error budget not a whit. That's all very nice but it says on the ntp.org page to use a national server if you have one. Mine happens to not be very good but that doesn't mean I shouldn't use it if it was good. No idea where it says that, but if it does it is bad advice in your situation. IF you are a server for a bunch of other machines that really need accurate time (eg stock traders, airlines,etc) then it might be good advice. For a home user who has spent no time trying to figure out what his requirements are who sits on an adsl line say, it is terible dvice, since it clogs up the national server. (No idea what you mean when you say your's is not very good. What evidence do you have for that?) The network variability is factors to 10-1000 times worse than the error you are correcting by using the national time standard. Nobody said it was the cause, since I'm not using it. But I can't tell who you are arguing with, the guy who suggested it or me for agreeing with it, or ntp.org for saying it's a good idea. I guess all three. Anyway, post your /etc/ntpd.conf file so we can see what you are trying to do, instead of having to guess. For example are you using the local server. Posted already, have no idea when the post will arrive though. I saw it and commented. But a clock that goes to fast by thousands of PPM has nothing to do with ntpd. ntpd is absolutely incapable of correcting errors like that or causing errors like that. It is either a hardware problem, a calibration problem, or you are running as a VM. Do not look at ntpd for the problem. It is like trying to clean out your ear cannals, when what you have is an ingrown toenail. Sounds like the voice of experience. But then again you have proven yourself obnoxious and unhelpful in other newsgroups so... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: - can one have multiple pool commands? For example, at the moment on one widely travelled PC I have: server 0.uk.pool.ntp.org iburst server 1.uk.pool.ntp.org iburst server 2.uk.pool.ntp.org iburst server 0.nl.pool.ntp.org iburst How would that best be replaced? Something like the following, perhaps? pool uk.pool.ntp.org iburst pool nl.pool.ntp.org iburst Why don't you drop the country codes from that? It already is questionable if it is a good idea to use them at all, and when you have a travelling PC it almost certainly is better not to try to overrule the location database. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 13/07/2012 08:45, Rob wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: - can one have multiple pool commands? For example, at the moment on one widely travelled PC I have: server 0.uk.pool.ntp.org iburst server 1.uk.pool.ntp.org iburst server 2.uk.pool.ntp.org iburst server 0.nl.pool.ntp.org iburst How would that best be replaced? Something like the following, perhaps? pool uk.pool.ntp.org iburst pool nl.pool.ntp.org iburst Why don't you drop the country codes from that? Because the PC does spend 90% of its time in the UK. It already is questionable if it is a good idea to use them at all, and when you have a travelling PC it almost certainly is better not to try to overrule the location database. Noted and thanks, but I actually omitted some of the country-specific or region-specific addresses I use when travelling. My two questions remain unanswered: - can I have more than one pool entry - is the preempt required? David -- David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 13/07/2012 08:45, Rob wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: - can one have multiple pool commands? For example, at the moment on one widely travelled PC I have: server 0.uk.pool.ntp.org iburst server 1.uk.pool.ntp.org iburst server 2.uk.pool.ntp.org iburst server 0.nl.pool.ntp.org iburst How would that best be replaced? Something like the following, perhaps? pool uk.pool.ntp.org iburst pool nl.pool.ntp.org iburst Why don't you drop the country codes from that? Because the PC does spend 90% of its time in the UK. It already is questionable if it is a good idea to use them at all, and when you have a travelling PC it almost certainly is better not to try to overrule the location database. Noted and thanks, but I actually omitted some of the country-specific or region-specific addresses I use when travelling. The pool DNS server, when you use pool pool.ntp.org or server pool.ntp.org, lookup your IP address in a location database and give you a server from the country you are residing in. No need to use uk. or nl. anymore, that is only a leftover from the past. My two questions remain unanswered: - can I have more than one pool entry - is the preempt required? I know little about ntpd. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 13/07/2012 10:00, Rob wrote: [] The pool DNS server, when you use pool pool.ntp.org or server pool.ntp.org, lookup your IP address in a location database and give you a server from the country you are residing in. No need to use uk. or nl. anymore, that is only a leftover from the past. Thanks, Rob. I just altered the PC to use the pool without the uk., and it seems to me that the selected servers have a greater delay than those I got using uk.pool, and I got two .nl servers. I'll leave it like that for a while, as avoiding the country-specific addresses should be good for that PC, in principle. I wish the pool command was described somewhere where Goggle found it more easily! -- David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Colleagues, I am seeing these experiences since recent times on my two ntp servers: [root@saturn ~]# ntpdc -c kern localhost: timed out, nothing received ***Request timed out [root@saturn ~]# I do not have any restricts in my ntp.conf file. This is confusing me as this was working before this time, although maybe I have changed something. [root@saturn ~]# /usr/local/sbin/ntpd --version ntpd 4.2.7p255@1.2483-o Mon Jul 2 08:52:22 UTC 2012 (1) [root@saturn ~]# My ntp.conf is looking like this (FreeBSD 8.2) [root@saturn ~]# cat /etc/ntp.conf # # $FreeBSD: src/etc/ntp.conf,v 1.2.2.1.6.1 2010/12/21 17:09:25 kensmith Exp $ # # Default NTP servers for the FreeBSD operating system. # # Don't forget to enable ntpd in /etc/rc.conf with: # ntpd_enable=YES # # The driftfile is by default /var/db/ntpd.drift, check # /etc/defaults/rc.conf on how to change the location. # # # The following three servers will give you a random set of three # NTP servers geographically close to you. # See http://www.pool.ntp.org/ for details. Note, the pool encourages # users with a static IP and good upstream NTP servers to add a server # to the pool. See http://www.pool.ntp.org/join.html if you are interested. # # The option `iburst' is used for faster initial synchronisation. # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD. # #server 0.freebsd.pool.ntp.org iburst maxpoll 9 #server 1.freebsd.pool.ntp.org iburst maxpoll 9 #server 2.freebsd.pool.ntp.org iburst maxpoll 9 #server 3.freebsd.pool.ntp.org iburst maxpoll 9 server tock.dhco.org iburst maxpoll 9 server 0.ie.pool.ntp.org iburst maxpoll 9 server 1.ie.pool.ntp.org iburst maxpoll 9 server 2.ie.pool.ntp.org iburst maxpoll 9 server 3.ie.pool.ntp.org iburst maxpoll 9 # -- Sure GPS board on COM1 ... set mode to 16 to force 9600 baud server 127.127.20.1mode 16 minpoll 4 prefer fudge 127.127.20.1flag1 1 flag3 1 refid GPS # # If you want to pick yourself which country's public NTP server # you want sync against, comment out the above servers, uncomment # the next ones and replace CC with the country's abbreviation. # Make sure that the hostnames resolve to a proper IP address! # # server 0.CC.pool.ntp.org iburst maxpoll 9 # server 1.CC.pool.ntp.org iburst maxpoll 9 # server 2.CC.pool.ntp.org iburst maxpoll 9 # # Security: Only accept NTP traffic from the following hosts. # The following configuration example only accepts traffic from the # above defined servers. # # Please note that this example doesn't work for the servers in # the pool.ntp.org domain since they return multiple A records. # (This is the reason that by default they are commented out) # #restrict default ignore #restrict 0.pool.ntp.org nomodify nopeer noquery notrap #restrict 1.pool.ntp.org nomodify nopeer noquery notrap #restrict 2.pool.ntp.org nomodify nopeer noquery notrap #restrict 127.0.0.1 #restrict -6 ::1 #restrict 127.127.1.0 # # If a server loses sync with all upstream servers, NTP clients # no longer follow that server. The local clock can be configured # to provide a time source when this happens, but it should usually # be configured on just one server on a network. For more details see # http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock # The use of Orphan Mode may be preferable. # #server 127.127.1.0 #fudge 127.127.1.0 stratum 10 leapfile /etc/leap-seconds.3535142400 [root@saturn ~]# Maybe one of you is seeing something that I am not? I have two identical servers that are showing this same error. Thanks for the helping hands, Ron ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 13/07/2012 10:00, Rob wrote: [] The pool DNS server, when you use pool pool.ntp.org or server pool.ntp.org, lookup your IP address in a location database and give you a server from the country you are residing in. No need to use uk. or nl. anymore, that is only a leftover from the past. Thanks, Rob. I just altered the PC to use the pool without the uk., and it seems to me that the selected servers have a greater delay than those I got using uk.pool, and I got two .nl servers. I'll leave it like that for a while, as avoiding the country-specific addresses should be good for that PC, in principle. Well maybe I should add it does not work as well when you use DNS servers that are not specific to the provider you use to access the internet. So when you assign everything using DHCP you should be fine, but when you use 8.8.8.8 as a DNS server it might be less optimal. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 13 Jul 2012 09:00:43 GMT, Rob nom...@example.com wrote: The pool DNS server, when you use pool pool.ntp.org or server pool.ntp.org, lookup your IP address in a location database and give you a server from the country you are residing in. I get angry when a statement is made which can easily be shown to be incorrect. What is your source for that statement? Last year you posted: On 21 Apr 2011 16:18:39 GMT, Rob nom...@example.com wrote: When I do a lookup of pool.ntp.org I get three addresses returned that are local to me. It wasn't true for David Taylor or me last year and it isn't true today. I'm in the UK. I gave up after getting 15 different IP addresses, none of them in the UK. I received IP addresses as close as France and Netherlands and as distant as Czech Republic, Slovakia, Sweden, and Switzerland. I see that David Taylor also received none UK addresses today. Again, last year you posted: On 22 Apr 2011 13:58:08 GMT, Rob nom...@example.com wrote: Is your Internet provider a company that is also (or mainly) active in France and Germany? Apparently the IP location service misinterprets your IP adress. That should be fixed. For the addresses I can test it works flawlessly. The IP location service correctly identifies my location as Europe. Where is it stated that the location service should be giving country specific IP addresses? -- Roger ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Roger invalid@invalid.invalid wrote: On 13 Jul 2012 09:00:43 GMT, Rob nom...@example.com wrote: The pool DNS server, when you use pool pool.ntp.org or server pool.ntp.org, lookup your IP address in a location database and give you a server from the country you are residing in. I get angry when a statement is made which can easily be shown to be incorrect. What is your source for that statement? Well actually it is not your own IP address but the IP address of the DNS forwarder you use that is being looked up. Usually you will use the DNS forwarder of your own ISP, and it will be located in the country where you are located yourself. However, as I already wrote, some people use 8.8.8.8 as a DNS forwarder and it will not work quite as well because the local instance of that manycast service can be in a neighboring country. Last year you posted: On 21 Apr 2011 16:18:39 GMT, Rob nom...@example.com wrote: When I do a lookup of pool.ntp.org I get three addresses returned that are local to me. It wasn't true for David Taylor or me last year and it isn't true today. It still is true today for me, and I have tested it at another ISP that I have access to now (and did not have last year), and it works OK there too. I'm in the UK. I gave up after getting 15 different IP addresses, none of them in the UK. I received IP addresses as close as France and Netherlands and as distant as Czech Republic, Slovakia, Sweden, and Switzerland. I see that David Taylor also received none UK addresses today. What DNS forwarder are you using? Is it the address given to you by your ISP (either on paper or via DHCP) or did you decice to use another DNS forwarder? Again, last year you posted: On 22 Apr 2011 13:58:08 GMT, Rob nom...@example.com wrote: Is your Internet provider a company that is also (or mainly) active in France and Germany? Apparently the IP location service misinterprets your IP adress. That should be fixed. For the addresses I can test it works flawlessly. The IP location service correctly identifies my location as Europe. Where is it stated that the location service should be giving country specific IP addresses? The documentation is lacking. It does not tell that it is using a location service at all. But still it does. This has been the case since 2007. Check the archives of the timekeepers mailing list for bits and pieces if information that have appeared there. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
unruh un...@invalid.ca wrote: driftfile /etc/ntp/drift multicastclient broadcastdelay 0.008 Why do you have these? You are getting your time from the pool, and suddenly there is the totally unknown multicast server somewhere that is also feeding in time. Try getting rid (comment out) these two lines. Thanks, as far as I know I have not changed this config from the Slackware defaults except to add the pools nearest to my location. Slackware configs are normally good safe defaults. Could be I blew it this time by not taking the time to understan what was going on. # Don't serve time or stats to anyone else by default (more secure) restrict default noquery nomodify # Trust ourselves. :-) restrict 127.0.0.1 Get rid of this. Which part? I didn't ever use the keys, maybe this could have been the problem? Nope. Thank you. Sorry for my prior note. You were indeed quite helpful. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: a) Stop ntpd (as mentioned above) b) check the config file to make sure it's configured to use a drift file, and find the location of it Did that, and everything appeared normal. c1) set both minpoll and maxpoll to 6 (64 seconds) if polling the internet c2) set both minpoll and maxpoll to 4 (16 seconds) or 3 (8 seconds) if polling the LAN or a GPS Did not know about these parameters, will read the man page and adjust. d) delete the drift file (as mentioned above) e) find the startup script for ntpd, which might be in the /etc/init.d or similar folder, is probably named NTP, and see what parameters it uses, and make a backup of it f) edit the startup script with elevated privileges (ie sudo, if applicable) g) insert the parameter (which I cannot remember the letter of) which allows ntpd to step the time at first This is the default but thank you for mentioning it. h) save the startup script i) sync to a national time standard server for his country 3 times in quick succession with ntpdate set to make a step change (In the USA, I would use NIST.) I have been using asia.pool.ntp.org j) start ntpd back up k) let if run several hours l) this should set a valid drift file and reign in the clock speed fairly rapidly m) stop ntpd n) reset the startup script to the way it was unless you want to leave the step command in there o) reset the config file for the original minpoll and maxpoll Was taking the defaults. p) restart ntpd Hopefully after a few more hours of running, the clock will be stable. You can even put the stop ntpd, ntpdate, ntpdate, ntpdate, start ntpd sequence in your own script and run that for greater speed and accuracy of the ntpdate sequences and minimal delay restarting ntpd. Unfortunately, this did not help. I tried all manner of corrections without rebooting the box and I finally decided to do that and I am now syncing to other machines in my network and all is fine. However since those other machines have essentially the same ntp.conf as the one with the problem and since they are all using the exact same server pool I do not understand why rebooting the PC helped. I will revert to my original ntp.conf on the problematic PC and see if it does it again. Thanks for your post. Fritz ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
unruh wrote: Fritz Wuehler wrote: That's all very nice but it says on the ntp.org page to use a national server if you have one. Mine happens to not be very good but that doesn't mean I shouldn't use it if it was good. No idea where it says that, but if it does it is bad advice in your situation. IF you are a server for a bunch of other machines that really need accurate time (eg stock traders, airlines,etc) then it might be good advice. For a home user who has spent no time trying to figure out what his requirements are who sits on an adsl line say, it is terrible advice, since it clogs up the national server. Geographicly Local Pool Servers (of any stratum): http://www.pool.ntp.org/en/use.html ... BlockQuote As pool.ntp.org will assign you timeservers from all over the world, time quality will not be ideal. You get a bit better result if you use the continental zones (For example europe, north-america, oceania or asia.pool.ntp.org), and even better time if you use the country zone (like ch.pool.ntp.org in Switzerland) - for all these zones, you can again use the 0, 1 or 2 prefixes, like 0.ch.pool.ntp.org. /BlockQuote ... Hand configuration of Stratum One Servers (instead of, or in addition to pool servers): http://support.ntp.org/bin/view/Servers/RulesOfEngagement BlockQuote As the load on the hosts supporting NTP primary (stratum 1) time service is heavy and always increasing, clients should avoid using the primary servers whenever possible. In most cases the accuracy of the NTP secondary (stratum 2) servers is only slightly degraded relative to the primary servers, and as a group, the secondary servers may be just as reliable. As a general rule, a secondary server should use a primary server only under the following conditions: The secondary server provides synchronization to a sizable population of other servers and clients on the order of 100 or more. The server operates with at least two and preferably three other secondary servers in a common synchronization subnet designed to provide reliable service, even if some servers or the lines connecting them fail. The administration(s) that operates these servers coordinates other servers within the region, in order to reduce the resources required outside that region. Note that at least some interregional resources are required in order to ensure reliable service. /BlockQuote ... -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Roger wrote: On 13 Jul 2012 09:00:43 GMT, Rob nom...@example.com wrote: The pool DNS server, when you use pool pool.ntp.org or server pool.ntp.org, lookup your IP address in a location database and give you a server from the country you are residing in. I get angry when a statement is made which can easily be shown to be incorrect. What is your source for that statement? This might be correct for the US, but definitely not here in Norway: C:\nslookup pool.ntp.org Server: DD-WRT Address: 192.168.1.1 Non-authoritative answer: Name:pool.ntp.org Addresses: 63.211.239.58 128.10.254.6 173.44.32.10 C:\nslookup 63.211.239.58 Server: DD-WRT Address: 192.168.1.1 Name:anaheim.capsaic.in Address: 63.211.239.58 C:\nslookup 128.10.254.6 Server: DD-WRT Address: 192.168.1.1 Name:caspak.cerias.purdue.edu Address: 128.10.254.6 C:\nslookup 173.44.32.10 Server: DD-WRT Address: 192.168.1.1 *** DD-WRT can't find 173.44.32.10: Non-existent domain My WRT54GL WiFi router runs DD-WRT, it is using my local Telefiber DNS server: C:\nslookup pool.ntp.org 94.139.66.250 Server: ns1.telefiber.no Address: 94.139.66.250 Non-authoritative answer: Name:pool.ntp.org Addresses: 128.10.254.6 173.44.32.10 63.211.239.58 I.e. I get the same three servers if I query that server directly. None of them seems to be anywhere near .no, I get ping times from 130 to 170 ms. :-( Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-13, Rob nom...@example.com wrote: The documentation is lacking. It does not tell that it is using a location service at all. But still it does. This has been the case since 2007. Check the archives of the timekeepers mailing list for bits and pieces if information that have appeared there. That archive is now located at http://lists.ntp.org/pipermail/pool/ and the list information page is at http://lists.ntp.org/listinfo/pool. It's no longer named the timekeepers mailing list ... -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-13, David Taylor david-tay...@blueyonder.co.uk wrote: I wish the pool command was described somewhere where Goggle found it more easily! Try searching google for site:doc.ntp.org pool e.g. http://www.google.com/search?q=site%3Adoc.ntp.org+pool Or go to http://doc.ntp.org and search for pool ... -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-13, Ron Hahn ron.h...@dhco.org wrote: I am seeing these experiences since recent times on my two ntp servers: [root@saturn ~]# ntpdc -c kern localhost: timed out, nothing received ***Request timed out [root@saturn ~]# I do not have any restricts in my ntp.conf file. This is confusing me as this was working before this time, although maybe I have changed something. [root@saturn ~]# /usr/local/sbin/ntpd --version ntpd 4.2.7p255@1.2483-o Mon Jul 2 08:52:22 UTC 2012 (1) [root@saturn ~]# Mode-7 (ntpdc report was disabled by default in 4.2.7p232 Take a look at the ChangeLog in the ntp-dev source tree or online at http://archive.ntp.org/ntp4/ChangeLog-dev: (4.2.7p232) 2011/11/05 Released by Harlan Stenn st...@ntp.org * Update the NEWS file so we note the default disable of mode 7 requests. Discussion about the pending removal is at http://lists.ntp.org/pipermail/hackers/2011-July/005307.html -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 14/07/2012 04:25, Steve Kostecke wrote: On 2012-07-13, David Taylor david-tay...@blueyonder.co.uk wrote: I wish the pool command was described somewhere where Goggle found it more easily! Try searching google for site:doc.ntp.org pool e.g. http://www.google.com/search?q=site%3Adoc.ntp.org+pool Or go to http://doc.ntp.org and search for pool ... Thanks, Steve, I've bookmarked the documentation archive page. Good to get that site ranked higher in Google - most of the references I picked up with a Google search were implementation specific (multiple Linux variants etc.). My DNS is my local router, which may account for not picking up local servers, so I've reverted to a uk.pool list. Cheers -- David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: Hi Unruh, I'm glad you like the suggestions. You may be right about the drift file. I don't know for sure what caused the runaway clock I experience in the past. However, it's my understanding that NTP sets the computer clock frequency to what it finds in the drift file at startup. If the drift file is way off, for whatever reason, then the initial clock frequency will be way off. As far as I know, it won't write another drift file for an hour. So, during that hour, particularly if the polling interval is long, the clock can be running so fast or slow that it will drift so far out that NTP might just give up on it. That may have been what happened because the drift file looked normal to me when I checked it but the clock was just getting worse and worse, as if ntp wasn't running. ntpdate sometimes fixed it but it would start drifting very quickly in huge amounts, minutes until it was 45 or more minutes off. Why a national time server? No need for that kind of accuracy. As long as we are all interested in precise and accurate time, every possible improvement that's easy to make should be worthwhile. Unfortunately I live in a country with erratic local time servers so I use the asian pool that has been mostly ok as far as I can tell. Thanks. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-12, Anonymous nore...@breaka.net wrote: Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: Hi Unruh, I'm glad you like the suggestions. You may be right about the drift file. I don't know for sure what caused the runaway clock I experience in the past. However, it's my understanding that NTP sets the computer clock frequency to what it finds in the drift file at startup. If the drift file is way off, for whatever reason, then the initial clock frequency will be way off. As far as I know, it won't write another drift file for an hour. So, during that hour, particularly if the polling interval is long, the clock can be running so fast or slow that it will drift so far out that NTP might just give up on it. That may have been what happened because the drift file looked normal to me when I checked it but the clock was just getting worse and worse, as if ntp wasn't running. ntpdate sometimes fixed it but it would start drifting very quickly in huge amounts, minutes until it was 45 or more minutes off. Why a national time server? No need for that kind of accuracy. As long as we are all interested in precise and accurate time, every possible improvement that's easy to make should be worthwhile. Unfortunately I live in a country with erratic local time servers so I use the asian pool that has been mostly ok as far as I can tell. Nuts. If you are interested in accurate time, you examine your error budget and find the places to make fixes. You do not impose yourself on others (the national time standards) using up other's scarce resources to make correction which change your error budget not a whit. The network variability is factors to 10-1000 times worse than the error you are correcting by using the national time standard. Anyway, post your /etc/ntpd.conf file so we can see what you are trying to do, instead of having to guess. For example are you using the local server. But a clock that goes to fast by thousands of PPM has nothing to do with ntpd. ntpd is absolutely incapable of correcting errors like that or causing errors like that. It is either a hardware problem, a calibration problem, or you are running as a VM. Do not look at ntpd for the problem. It is like trying to clean out your ear cannals, when what you have is an ingrown toenail. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
E-Mail Sent to this address will be added to the BlackLists Null@BlackList.Anitech-Systems.invalid wrote: Anonymous wrote: I decided to try to synchronize to my other machines in my network rather than the ntp pool I was using and after restarting the PC with the problem it is fine. I do not know what the problem was since the other boxes are still using the ntp pool and not having any issues so I will revert this PC to its original config to use the ntp pool again and see if it recurs. You don't happen to have the Undisciplined Local Clock Driver 127.127.1.# configured? No, I don't. Here is the ntp.conf I have been using. I left the sample alone except for adding the pools for my zone. Thanks. # Sample /etc/ntp.conf: Configuration file for ntpd. # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server 0.asia.pool.ntp.org server 1.asia.pool.ntp.org server 2.asia.pool.ntp.org server 3.asia.pool.ntp.org # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /etc/ntp/drift multicastclient broadcastdelay 0.008 # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 600 for sure) and define the key number to be # used for making requests. # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. # #keys /etc/ntp/keys #trustedkey 65535 #requestkey 65535 #controlkey 65535 # Don't serve time or stats to anyone else by default (more secure) restrict default noquery nomodify # Trust ourselves. :-) restrict 127.0.0.1 I didn't ever use the keys, maybe this could have been the problem? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
I didn't see anything that would allow ntp to runaway.
Fritz Wuehler wrote:
# Sample /etc/ntp.conf: Configuration file for ntpd.
server 0.asia.pool.ntp.org
server 1.asia.pool.ntp.org
server 2.asia.pool.ntp.org
server 3.asia.pool.ntp.org
If you use a more recent version Dev 4.2.7p288,
(instead of 4.2.4p7 from May 2009);
You can replace those 4 lines with something like:
pool asia.pool.ntp.org preempt iburst
restrict source nomodify
NTP will automatically add servers (up to maxclock),
and as it drops some, it will add more;
eventually, you will likely end up with
a clique of servers that have lower offset to you,
and are also close in time to each other.
multicastclient
broadcastdelay0.008
#keys /etc/ntp/keys
#trustedkey 65535
#requestkey 65535
#controlkey 65535
I don't think multicastclient will work without Auth?
(unless you disabled auth on the commandline?)
{This is likely only useful, if you have several ntp
clients / servers on your LAN that you want to try
and keep synced together, even when internet access is lost.}
e.g. I use something similar to this on all PCs / Devices
# ALL (Clients and/or Servers)
tos cohort 1 orphan 11
restrict default limited kod nomodify notrap
restrict 127.0.0.1
restrict source nomodify
keys /etc/ntp.keys # e.g. contains: 123 M YOUR_MD5_KEY
trustedkey 123
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
multicastclient 224.0.1.1 key 123 preempt
broadcastclient
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Fritz Wuehler wrote: # Trust ourselves. :-) restrict 127.0.0.1 Trusting yourself is only useful if you don't trust others as much! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
unruh un...@invalid.ca wrote: On 2012-07-12, Anonymous nore...@breaka.net wrote: Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: Hi Unruh, I'm glad you like the suggestions. You may be right about the drift file. I don't know for sure what caused the runaway clock I experience in the past. However, it's my understanding that NTP sets the computer clock frequency to what it finds in the drift file at startup. If the drift file is way off, for whatever reason, then the initial clock frequency will be way off. As far as I know, it won't write another drift file for an hour. So, during that hour, particularly if the polling interval is long, the clock can be running so fast or slow that it will drift so far out that NTP might just give up on it. That may have been what happened because the drift file looked normal to me when I checked it but the clock was just getting worse and worse, as if ntp wasn't running. ntpdate sometimes fixed it but it would start drifting very quickly in huge amounts, minutes until it was 45 or more minutes off. Why a national time server? No need for that kind of accuracy. As long as we are all interested in precise and accurate time, every possible improvement that's easy to make should be worthwhile. Unfortunately I live in a country with erratic local time servers so I use the asian pool that has been mostly ok as far as I can tell. Nuts. If you are interested in accurate time, you examine your error budget and find the places to make fixes. You do not impose yourself on others (the national time standards) using up other's scarce resources to make correction which change your error budget not a whit. That's all very nice but it says on the ntp.org page to use a national server if you have one. Mine happens to not be very good but that doesn't mean I shouldn't use it if it was good. The network variability is factors to 10-1000 times worse than the error you are correcting by using the national time standard. Nobody said it was the cause, since I'm not using it. But I can't tell who you are arguing with, the guy who suggested it or me for agreeing with it, or ntp.org for saying it's a good idea. Anyway, post your /etc/ntpd.conf file so we can see what you are trying to do, instead of having to guess. For example are you using the local server. Posted already, have no idea when the post will arrive though. But a clock that goes to fast by thousands of PPM has nothing to do with ntpd. ntpd is absolutely incapable of correcting errors like that or causing errors like that. It is either a hardware problem, a calibration problem, or you are running as a VM. Do not look at ntpd for the problem. It is like trying to clean out your ear cannals, when what you have is an ingrown toenail. Sounds like the voice of experience. But then again you have proven yourself obnoxious and unhelpful in other newsgroups so... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-12, Fritz Wuehler fr...@spamexpire-201207.rodent.frell.theremailer.net wrote: E-Mail Sent to this address will be added to the BlackLists Null@BlackList.Anitech-Systems.invalid wrote: Anonymous wrote: I decided to try to synchronize to my other machines in my network rather than the ntp pool I was using and after restarting the PC with the problem it is fine. I do not know what the problem was since the other boxes are still using the ntp pool and not having any issues so I will revert this PC to its original config to use the ntp pool again and see if it recurs. You don't happen to have the Undisciplined Local Clock Driver 127.127.1.# configured? No, I don't. Here is the ntp.conf I have been using. I left the sample alone except for adding the pools for my zone. Thanks. # Sample /etc/ntp.conf: Configuration file for ntpd. # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server 0.asia.pool.ntp.org server 1.asia.pool.ntp.org server 2.asia.pool.ntp.org server 3.asia.pool.ntp.org # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /etc/ntp/drift multicastclient broadcastdelay0.008 Why do you have these? You are getting your time from the pool, and suddenly there is the totally unknown multicast server somewhere that is also feeding in time. Try getting rid (comment out) these two lines. # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 600 for sure) and define the key number to be # used for making requests. # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. # #keys /etc/ntp/keys #trustedkey 65535 #requestkey 65535 #controlkey 65535 # Don't serve time or stats to anyone else by default (more secure) restrict default noquery nomodify # Trust ourselves. :-) restrict 127.0.0.1 Get rid of this. I didn't ever use the keys, maybe this could have been the problem? Nope. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Dave Hart h...@ntp.org wrote: On Mon, Jul 9, 2012 at 18:14 UTC, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. Stop ntpd using whatever means is normal for your OS. Find the path to the drift file (which preserves an estimate of your system's clock rate error): $ fgrep drift /etc/ntp.conf driftfile /var/lib/ntp/drift Then remove it and restart ntpd. It will synchronize once then spend 1024 seconds (17m) measuring the clock rate error. With any luck it will be an accurate-enough estimate that ntpd will then converge on its own. Dave, thanks for your reply. I did that but it didn't help. I decided to try to synchronize to my other machines in my network rather than the ntp pool I was using and after restarting the PC with the problem it is fine. I do not know what the problem was since the other boxes are still using the ntp pool and not having any issues so I will revert this PC to its original config to use the ntp pool again and see if it recurs. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
Anonymous wrote: I decided to try to synchronize to my other machines in my network rather than the ntp pool I was using and after restarting the PC with the problem it is fine. I do not know what the problem was since the other boxes are still using the ntp pool and not having any issues so I will revert this PC to its original config to use the ntp pool again and see if it recurs. You don't happen to have the Undisciplined Local Clock Driver 127.127.1.# configured? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
pkmaybe you can post your ntp.conf file, so we can take a look. -Original Message- From: questions-bounces+p.kennedy=fugro.com...@lists.ntp.org [mailto:questions-bounces+p.kennedy=fugro.com...@lists.ntp.org] On Behalf Of E-Mail Sent to this address will be added to the BlackLists Sent: Thursday, 12 July 2012 3:42 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] losing time fast Anonymous wrote: I decided to try to synchronize to my other machines in my network rather than the ntp pool I was using and after restarting the PC with the problem it is fine. I do not know what the problem was since the other boxes are still using the ntp pool and not having any issues so I will revert this PC to its original config to use the ntp pool again and see if it recurs. You don't happen to have the Undisciplined Local Clock Driver 127.127.1.# configured? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-09, Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: unruh un...@invalid.ca wrote: On 2012-07-09, Dave Hart h...@ntp.org wrote: On Mon, Jul 9, 2012 at 18:14 UTC, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. Stop ntpd using whatever means is normal for your OS. Find the path to the drift file (which preserves an estimate of your system's clock rate error): $ fgrep drift /etc/ntp.conf driftfile /var/lib/ntp/drift Then remove it and restart ntpd. It will synchronize once then spend 1024 seconds (17m) measuring the clock rate error. With any luck it will be an accurate-enough estimate that ntpd will then converge on its own. If he is losing minutes per hour, this is hopeless. That is 16000PPM. npt cannot correct that. Ssomething is very very wrong. Note to regulars: I'm going to have sporadic internet access for the rest of July, so I won't be as responsive. Your help is welcome. I'll admit to not following this thread too closely. I've been looking at some of the posts. I will also admit to not being an NTP expert. However, I remember once when I was getting a clock error of a few minutes per hour. I think (but wouldn't bet my life on it) that it may have happened after I copied the NTP directory to another system and the drift file was wrong. Therefore, the NTP program was running the system software clock at the wrong rate and the clock was rapidly getting too far out to correct. If he is really loosing minutes par day, then there is no drift file that could do that. But certainly your suggestions are worth trying. I would recommend the following: a) Stop ntpd (as mentioned above) b) check the config file to make sure it's configured to use a drift file, and find the location of it c1) set both minpoll and maxpoll to 6 (64 seconds) if polling the internet c2) set both minpoll and maxpoll to 4 (16 seconds) or 3 (8 seconds) if polling the LAN or a GPS d) delete the drift file (as mentioned above) e) find the startup script for ntpd, which might be in the /etc/init.d or similar folder, is probably named NTP, and see what parameters it uses, and make a backup of it f) edit the startup script with elevated privileges (ie sudo, if applicable) g) insert the parameter (which I cannot remember the letter of) which allows ntpd to step the time at first h) save the startup script i) sync to a national time standard server for his country 3 times in quick succession with ntpdate set to make a step change (In the USA, I would use NIST.) Why a national time server? No need for that kind of accuracy. j) start ntpd back up k) let if run several hours l) this should set a valid drift file and reign in the clock speed fairly rapidly m) stop ntpd n) reset the startup script to the way it was unless you want to leave the step command in there o) reset the config file for the original minpoll and maxpoll p) restart ntpd Hopefully after a few more hours of running, the clock will be stable. You can even put the stop ntpd, ntpdate, ntpdate, ntpdate, start ntpd sequence in your own script and run that for greater speed and accuracy of the ntpdate sequences and minimal delay restarting ntpd. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
unruh un...@invalid.ca wrote: On 2012-07-09, Ron Frazier (NTP) timekeepingntpl...@techstarship.com wrote: unruh un...@invalid.ca wrote: On 2012-07-09, Dave Hart h...@ntp.org wrote: On Mon, Jul 9, 2012 at 18:14 UTC, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. Stop ntpd using whatever means is normal for your OS. Find the path to the drift file (which preserves an estimate of your system's clock rate error): $ fgrep drift /etc/ntp.conf driftfile /var/lib/ntp/drift Then remove it and restart ntpd. It will synchronize once then spend 1024 seconds (17m) measuring the clock rate error. With any luck it will be an accurate-enough estimate that ntpd will then converge on its own. If he is losing minutes per hour, this is hopeless. That is 16000PPM. npt cannot correct that. Ssomething is very very wrong. Note to regulars: I'm going to have sporadic internet access for the rest of July, so I won't be as responsive. Your help is welcome. I'll admit to not following this thread too closely. I've been looking at some of the posts. I will also admit to not being an NTP expert. However, I remember once when I was getting a clock error of a few minutes per hour. I think (but wouldn't bet my life on it) that it may have happened after I copied the NTP directory to another system and the drift file was wrong. Therefore, the NTP program was running the system software clock at the wrong rate and the clock was rapidly getting too far out to correct. If he is really loosing minutes par day, then there is no drift file that could do that. But certainly your suggestions are worth trying. Hi Unruh, I'm glad you like the suggestions. You may be right about the drift file. I don't know for sure what caused the runaway clock I experience in the past. However, it's my understanding that NTP sets the computer clock frequency to what it finds in the drift file at startup. If the drift file is way off, for whatever reason, then the initial clock frequency will be way off. As far as I know, it won't write another drift file for an hour. So, during that hour, particularly if the polling interval is long, the clock can be running so fast or slow that it will drift so far out that NTP might just give up on it. Here's an experiment someone could try if they were inclined to. Warning, doing this will probably really irritate the experimenter, but also provide a learning experience. Find a PC which is running NTP, which no other PC's or critical users or applications depend on for time, and which you don't care if the clock is horribly wrong for a while. Make sure it's using a drift file, and preferably producing clockstats and loopstats error files for tracking. A windows system may be more illustrative than linux, but I'm not sure. Warning, doing the following will probably make the PC's clock run massively fast, necessitating a massive step change backwards later to fix it. Stop NTPD. Go find the drift file and make a backup copy of it. Edit the drift file with elevated privileges if needed. Say it says 6.234. Add a 10, 20, or 30 in front of it, so it's 106.234 or 206.234 or 306.234 then save it. If possible, add a local clock source in ntp.conf on the lan or using gps that you can poll very often. Set that source as noselect and polling every 8 or 16 seconds. Set minpoll for other sources to 12 (1 hour). Restart NTPD. If my thinking, and my memory of my prior experience, is correct, your clock will now be running massively fast. (I assume you could use negative numbers if you want the clock to run slower.) Monitor NTPQ and observe the offset to your local reference clock. You should see the system clock rapidly diverging from the reference clock. You may see NTP give up entirely trying to fix it and never correct it. You can then have loads of fun trying to fix the problem. If you knew what the drift file normally is, you could run ntpdate a few times to get the time close and restore the drift file manually to the correct value. However, it's more
[ntp:questions] losing time fast
I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On Mon, Jul 9, 2012 at 18:14 UTC, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. Stop ntpd using whatever means is normal for your OS. Find the path to the drift file (which preserves an estimate of your system's clock rate error): $ fgrep drift /etc/ntp.conf driftfile /var/lib/ntp/drift Then remove it and restart ntpd. It will synchronize once then spend 1024 seconds (17m) measuring the clock rate error. With any luck it will be an accurate-enough estimate that ntpd will then converge on its own. Note to regulars: I'm going to have sporadic internet access for the rest of July, so I won't be as responsive. Your help is welcome. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 7/9/2012 2:14 PM, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. NTP will only correct for local clock error up to 500 ppm. 1 minute per day is greater than that, so 7 minutes in several hours would be _way_ out. My guess is a hardware issue on the PC has caused the local clock to fall out of the adjustment range, so NTP won't even try to keep it sync'd. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 7/9/2012 2:14 PM, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. You do not mention the direction of the error which *may* be significant! If the clock is slow, it suggests that something may be eating your CPU while running at high priority! If the clock is fast, nothing suggests itself to me! I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
On 2012-07-09, Dave Hart h...@ntp.org wrote: On Mon, Jul 9, 2012 at 18:14 UTC, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. Stop ntpd using whatever means is normal for your OS. Find the path to the drift file (which preserves an estimate of your system's clock rate error): $ fgrep drift /etc/ntp.conf driftfile /var/lib/ntp/drift Then remove it and restart ntpd. It will synchronize once then spend 1024 seconds (17m) measuring the clock rate error. With any luck it will be an accurate-enough estimate that ntpd will then converge on its own. If he is losing minutes per hour, this is hopeless. That is 16000PPM. npt cannot correct that. Ssomething is very very wrong. Note to regulars: I'm going to have sporadic internet access for the rest of July, so I won't be as responsive. Your help is welcome. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] losing time fast
unruh un...@invalid.ca wrote: On 2012-07-09, Dave Hart h...@ntp.org wrote: On Mon, Jul 9, 2012 at 18:14 UTC, Fritz Wuehler wrote: I noticed the clock on my main desktop was off by 28 minutes today and it increased to 45 minutes. I resync'd with ntpdate manually and it has drifted behind again about 7 minutes in the last few hours. I am using ntp version 4.2.4p7 which was installed with Slackware on Linux kernel 2.6.29.6. Until today the clock on this system has always matched the clocks of the other machines on my network. The system has been running for several years essentially unchanged. The only thing that changed (that I know of) is I added a new machine to my network recently. Its clock matches all the other clocks. I don't see any unusual messages from ntpd in my log or messages files on the system with the problem. One system has problems, all others appear to be fine and have synchronized clocks. I realize this isn't much information but I don't know what to look for. Can anyone tell me how to troubleshoot this? Thank you. Stop ntpd using whatever means is normal for your OS. Find the path to the drift file (which preserves an estimate of your system's clock rate error): $ fgrep drift /etc/ntp.conf driftfile /var/lib/ntp/drift Then remove it and restart ntpd. It will synchronize once then spend 1024 seconds (17m) measuring the clock rate error. With any luck it will be an accurate-enough estimate that ntpd will then converge on its own. If he is losing minutes per hour, this is hopeless. That is 16000PPM. npt cannot correct that. Ssomething is very very wrong. Note to regulars: I'm going to have sporadic internet access for the rest of July, so I won't be as responsive. Your help is welcome. I'll admit to not following this thread too closely. I've been looking at some of the posts. I will also admit to not being an NTP expert. However, I remember once when I was getting a clock error of a few minutes per hour. I think (but wouldn't bet my life on it) that it may have happened after I copied the NTP directory to another system and the drift file was wrong. Therefore, the NTP program was running the system software clock at the wrong rate and the clock was rapidly getting too far out to correct. I would recommend the following: a) Stop ntpd (as mentioned above) b) check the config file to make sure it's configured to use a drift file, and find the location of it c1) set both minpoll and maxpoll to 6 (64 seconds) if polling the internet c2) set both minpoll and maxpoll to 4 (16 seconds) or 3 (8 seconds) if polling the LAN or a GPS d) delete the drift file (as mentioned above) e) find the startup script for ntpd, which might be in the /etc/init.d or similar folder, is probably named NTP, and see what parameters it uses, and make a backup of it f) edit the startup script with elevated privileges (ie sudo, if applicable) g) insert the parameter (which I cannot remember the letter of) which allows ntpd to step the time at first h) save the startup script i) sync to a national time standard server for his country 3 times in quick succession with ntpdate set to make a step change (In the USA, I would use NIST.) j) start ntpd back up k) let if run several hours l) this should set a valid drift file and reign in the clock speed fairly rapidly m) stop ntpd n) reset the startup script to the way it was unless you want to leave the step command in there o) reset the config file for the original minpoll and maxpoll p) restart ntpd Hopefully after a few more hours of running, the clock will be stable. You can even put the stop ntpd, ntpdate, ntpdate, ntpdate, start ntpd sequence in your own script and run that for greater speed and accuracy of the ntpdate sequences and minimal delay restarting ntpd. Sincerely, Ron -- Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail. Please excuse my potential brevity. (To whom it may concern. My email address has changed. Replying to former messages prior to 03/31/12 with my personal address will go to the wrong address. Please send all personal correspondence to the new address.) (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new email messages very quickly. If you need a reply and haven't heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT techstarship.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
