Re: [ntp:questions] Questions from people whose return address is gmail, googlemail, Yahoo, etc.
with lufm3e$s06$5...@dont-email.me William Unruh wrote: *SKIP* people who use google as their news servers, Since google doesn't provide news on port 119 how it can possibly be 'server'? It's not, it's web-centered news client. May I ask you to set your terminology right? *CUT* -- Torvalds' goal for Linux is very simple: World Domination Stallman's goal for GNU is even simpler: Freedom ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Difficulties on a Xen vm
I'm having a great deal of trouble maintaining a stable time on a Xen vm. It will repair the offset on initial start-up and then allow the clock to drift quite dramatically (hardware clocks on VM's being more than a little screwy). This is FreeBSD 8.1-RELEASE-p1. I'm running with what is primarily a stock freebsd ntp.conf with the exception that I'm peering with my other machines: [snip] # 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 # Probably important to make sure that all our own machines peer with # each other peer smtp3.mydomain.com iburst maxpoll 9 peer smtp2.mydomain.com iburst maxpoll 9 peer fw.mydomain.com iburst maxpoll 9 [snip] I have read that use of maxpoll is discouraged by non-cognoscenti; so in this case, I'm bowing to the FreeBSD authors. Because of iburst, a sync is performed when ntpd is started. The ntpdc session below shows the drift increasing over about 30 minutes when, finally, a server is chosen from which to sync. Shortly thereafter, the sync server is dropped. Running a tcpdump shows ntp traffic back and forth to the other servers. However the packets leaving this machine include: Leap indicator: clock unsynchronized (192), Stratum 0, poll 6s, precision -17 The other 3 peering machines list this one as: stratum 16, poll 64, reach 0 Eventually, it starts syncing with bindcat again and allows the peers to sync again. Usually it will be happy for several days; but then a similar cycle will begin again. I have seen it drift as far as 110 seconds. Meanwhile my Nagios is in alarm state. I would love to have this be stable. I am stumped. ** r...@smtp4 ** ~ ** Thu Sep 30 11:28:03 # ntpdc ntpdc peers remote local st poll reach delay offsetdisp === =mail.freerip.co 208.86.227.252 3 64 37 0.06601 1.972097 0.66312 +75-150-112-177- 208.86.227.252 3 64 76 0.0 2.764889 0.66237 +75-150-112-180- 208.86.227.252 3 64 77 0.0 2.694973 0.43567 =dnscache1.izoom 208.86.227.252 2 64 37 0.05040 2.226106 0.66289 +static-141-149- 208.86.227.252 3 64 36 0.0 2.688963 0.96884 =bindcat.fhsu.ed 208.86.227.252 2 64 77 0.06332 2.126619 0.43546 ntpdc peers remote local st poll reach delay offsetdisp === =mail.freerip.co 208.86.227.252 3 64 377 0.08252 4.591225 0.03081 +75-150-112-177- 208.86.227.252 3 64 377 0.0 4.567796 0.03688 +75-150-112-180- 208.86.227.252 3 64 376 0.0 4.358072 0.03452 =dnscache1.izoom 208.86.227.252 2 64 377 0.05496 4.563476 0.03096 +static-141-149- 208.86.227.252 3 64 376 0.0 4.407265 0.03770 =bindcat.fhsu.ed 208.86.227.252 2 64 377 0.06410 4.543536 0.03094 ntpdc peers remote local st poll reach delay offsetdisp === =mail.freerip.co 208.86.227.252 3 64 377 0.06604 7.595356 0.03088 +75-150-112-177- 208.86.227.252 2 64 357 0.03517 7.695750 0.03362 +75-150-112-180- 208.86.227.252 3 64 377 0.0 7.622695 0.03357 =dnscache1.izoom 208.86.227.252 2 64 377 0.04883 7.607783 0.03064 +static-141-149- 208.86.227.252 3 64 377 0.0 7.671774 0.03705 =bindcat.fhsu.ed 208.86.227.252 2 64 377 0.06372 7.698156 0.03065 ntpdc peers remote local st poll reach delay offsetdisp === =mail.freerip.co 208.86.227.252 3 64 377 0.06653 7.807234 0.03099 +75-150-112-177- 208.86.227.252 2 64 357 0.03517 7.695750 0.03362 +75-150-112-180- 208.86.227.252 3 64 377 0.0 7.943508 0.03384 =dnscache1.izoom 208.86.227.252 2 64 377 0.04715 7.817454 0.03061 +static-141-149- 208.86.227.252 3 64 376 0.0 7.671774 0.03705 =bindcat.fhsu.ed 208.86.227.252 2 64 377 0.06372 7.698156 0.03065 ntpdc peers remote local st poll reach delay offsetdisp === =mail.freerip.co 208.86.227.252 3 64 377 0.06602 10.379082 0.03099 +75-150-112-177- 208.86.227.252 2 64 377 0.03528 10.381183 0.03099 +75-150-112-180- 208.86.227.252 3 64 377 0.03360 10.224393 0.03198 =dnscache1.izoom 208.86.227.252 2 64 377 0.04733 10.352269 0.03082 +static-141-149- 208.86.227.252 3 64 377 0.0 10.300544 0.03810 =bindcat.fhsu.ed 208.86.227.252 2 64 377 0.06337 10.381435 0.03064 ntpdc peers remote local st poll reach delay offsetdisp
Re: [ntp:questions] Help needed
Hi, There is no response when run ntpd -gN, should there be an output ? Regards, Eric Magutu On Mon, Jul 13, 2009 at 3:14 PM, Danny Mayer ma...@ntp.org wrote: Eric Magutu wrote: Hi, I am having a problem with ntp. The previous sys admin installed ntp from source on Freebsd 7.0 I am unable to correct the time on the server, everytime I change the time it goes back to its original time. I can't find where the ntp.conf file is located. Here is the result of ntpq -p remote refid st t when poll reach delay offset jitter == weyoun.cord.de 193.189.251.42 2 u 220 256 17 11.310 919348. 61.566 wikisquare.de 129.69.1.153 2 u 217 256 17 10.335 919419. 110.597 alpha.rueckgr.a 94.23.200.1113 u 219 256 17 10.245 919315. 65.508 unknown.nifelhe 143.93.99.2522 u 218 256 174.075 919279. 91.419 It is stuck 15 min behind time. Any help will be greatly apprectiated Are you running ntpd -gN? What does you command line look like? You need the -g in case the time is off by too large an amount. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Help needed
Hi, I am having a problem with ntp. The previous sys admin installed ntp from source on Freebsd 7.0 I am unable to correct the time on the server, everytime I change the time it goes back to its original time. I can't find where the ntp.conf file is located. Here is the result of ntpq -p remote refid st t when poll reach delay offset jitter == weyoun.cord.de 193.189.251.42 2 u 220 256 17 11.310 919348. 61.566 wikisquare.de 129.69.1.153 2 u 217 256 17 10.335 919419. 110.597 alpha.rueckgr.a 94.23.200.1113 u 219 256 17 10.245 919315. 65.508 unknown.nifelhe 143.93.99.2522 u 218 256 174.075 919279. 91.419 It is stuck 15 min behind time. Any help will be greatly apprectiated -- Regards, Eric Magutu ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
On Tue, 10 Feb 2009 23:38:07 -0500, Richard B. Gilbert rgilber...@comcast.net wrote for the entire planet to see: Danny Mayer wrote: Eric wrote: The only mitigation I can think of here is for NTP to not respond to excessive rate queries at all, or very infrequently, after the KOD. - Eric That's what the latest code does. Danny If ntpd responds to such DOS attacks with the WRONG YEAR or random date-times, it might discourage the perpetrators. Not really. If it's really a DDoS attempt the source address won't belong to an NTP server and the packet will be discarded, sooner or later. It's value is just to clog the pipes. And anyway, there seems to be a general consensus that sending the wrong time is wrong. Just don't send it, or simply mark it invalid or KOD or all zeros, or all three. No need to attempt to confound the requester. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
On Mon, 9 Feb 2009 14:07:26 -0800 (PST), jlevine jlev...@boulder.nist.gov wrote for the entire planet to see: In the last few days I have seen an increasing number of systems that are requesting the time in NTP format several times per second. Have you considered the possibility that they are spoofed queries from a botnet? There are some records of which IPs are the current/past targets. There have been a number of recent DDoS attacks using spoofed UDP packets. The usual attack uses port 53 (DNS) and attempts to get 'amplification' of a small query into a large response towards the victim IP. NTP packets are the same size both ways, but might still be used to help with a flood. The only mitigation I can think of here is for NTP to not respond to excessive rate queries at all, or very infrequently, after the KOD. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
On Sun, 20 Jan 2008 17:50:41 GMT, Unruh [EMAIL PROTECTED] wrote for the entire planet to see: [EMAIL PROTECTED] (David Woolley) writes: In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] wrote: snip I would assume that ntp is giving these samples with long round trip very low weight, or even eliminating them. Note: if these spikes are positive, they may be the result of lost ticks. Don't think so. I think they are 5-10ms transmission delays. The delays disappear if I run at maxpoll 7 rather than 10, so I suspect the router is forgetting the addresses and taking its own sweet time about finding them if the time between transmissions is many minutes. chrony has a nice feature of being able to send an echo datagram to the other machine if you want (before the ntp packet), to wake up the routers along the way. There are several related effects here that I have experienced in my NTP network. First is the possible ARP resolution overheads. If the IP addresses of your host and of the destination or default gateway are not passing traffic frequently the ARP cache in your host or the local router can time out and need to be reloaded on each poll. These can be on the order of 5-10ms and will affect only one side of the transaction's transmission delay. Unfortunately ARP often uses a 15 minute TTL, and default NTP uses a 17 minute poll interval. Then there is the whole problem that many routers all along the path experience extra overhead on the first packet of a flow. Route table look ups are done by destination IP of course, but generally have to be installed into the cache, or FIB, the first time a new source/dest IP pair shows up. This is often a 1-3ms overhead. And that entry doesn't last forever either. Then there is the MAC cache in your switches, which generally purge after 1-5 minutes. This can often be adjusted higher, but that can sometimes cause issues for others when they are reconfiguring part of the network. Another issue is NATing or statefull firewalls. There is often outbound (or inbound) connection setup time. Without special configuration this often times out before twenty minutes, leading to more asymmetric delay. I think the suggestion of a pre-poll ICMP echo is kinda interesting. It might be possible to limit the packet TTL to five hops or so, just warming up your side of the network. It might also be better to make it a mostly standard UDP NTP packet so it matches whatever rules the intermediate devices are applying (and you want them to remember). QoS and policy routing are both sensitive to port numbers, and certainly most firewalls are protocol sensitive, so matching the initial packet attributes to the desired high-performance packet attributes would probably help this technique work. To mitigate some of these effects it might not have to be done that often. In many hierarchical network topologies it might serve just to send one extra packet every 3-5 minutes using the same source IP/port that NTP normally uses, to any configured server. And it could still have a limited TTL if desired. That would at least keep the switch and ARP caches fresh and depending on the design, the policy and NAT caches as well. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
On Mon, 28 Jan 2008 19:19:12 +, David L. Mills [EMAIL PROTECTED] wrote for the entire planet to see: Eric, Many years ago the Proteon routers dropped the first packet after the cache timed out; that was a disaster. That case and the ones you describe are exactly what the NTP burst mode is designed for. The first packet in the burst carves the caches all along the route and back. The clock filter algorithm tosses it out in favor of the remaining packets in the burst. No ICMP is needed or wanted. Dave I agree about ICMP. UDP would be better. And BURST / IBURST are nice, but conventional wisdom has it that BURST really shouldn't be used towards servers that you don't administer, and IBURST will of course not handle the ongoing case. In considering this more, I think a great option or tinker value would be one that simply sends an extra packet, rather than eight of them, and only if the previous poll for that association was sent more than x seconds ago. In other words, as long as the poll value is say 7 or less, nothing new is needed. When the poll exceeds 7, then ten seconds before a poll is due to be sent an explorer poll is sent (and any response would likely be discarded). EBURST, or maybe PAVE. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
On Mon, 28 Jan 2008 21:39:17 + (UTC), Rick Jones [EMAIL PROTECTED] wrote for the entire planet to see: Eric [EMAIL PROTECTED] wrote: Of course, different manufacturers may have different methods of detecting the cache miss and recovering from that, so it would be hard to eliminate that effect from consideration entirely. It's the smallest effect of all the ones I've dealt with. Just to be certain, you are talking about MAC's being aged out of a switch's forwarding tables right? I interpreted it that way based on the previous text discussing ARP caches. Yup. And I see that in the simple case the packet just floods, isn't delayed on its original path/port, and the MAC cache update is handled overlapped in time with the packet transfer. But, there may be more complicated cases; you mentioned STP, and of course flooding causes its own delays to some degree. Then it might be that the switch firmware takes a slow path on the cache miss, causes an interrupt, gets scheduled into a timeslice, updates the MAC Cache, and then redrives the packet forwarding process. Not ideal, if that ever happens. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
On Mon, 28 Jan 2008 22:09:11 +, David L. Mills [EMAIL PROTECTED] wrote for the entire planet to see: snip However, you give me an idea. Why not shut down the burst when the clock filter delivers the first sample? Gotta think about that. Dave Hi Dave - I'm pleased to know I've provoked some new thoughts. If I understand your post, burst mode was intended to get enough (lousy) samples into and through the clock filters to allow for initial sync. Once the pipeline is loaded no more extra polls are needed. But the rest of this sub-thread was about poll intervals that get so large that the intervening equipment forgets about the flow and always, from then on, gives lousy performance on the one and only poll in that interval. I guess we could kill two birds with one stone and shut down burst as you suggest, until the interval gets longer, when it could make a reappearance, perhaps as only a pair of packets. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
On Mon, 28 Jan 2008 17:44:08 -0500, Richard B. Gilbert [EMAIL PROTECTED] wrote for the entire planet to see: I thought that burst sent eight packets two seconds apart at each poll interval. It's not apprropriate for most situations. It was designed for systems making infrequent dialup connections like twice or three times daily. My confusion. IBURST for the Initial loading of the buffer. BURST for the very, very infrequent connection to reload the entire buffer each time. But what about the idea that IBURST is nice for fast startup, BURST is helpful if there hasn't been a poll for a very, very long time, and now the new idea for an explorer packet (only one extra) that would be nice to smooth the network path when the polling interval goes over a couple of minutes. It turns each of them into virtually the same case, classified by when the polling interval currently in effect. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance of NTP under Windows Vista?
On Wed, 14 Nov 2007 06:26:48 GMT, David J Taylor [EMAIL PROTECTED] wrote for the entire planet to see: Does anyone have any measurements of NTP running under Windows Vista? In particular, the Meinberg foehr 1520 version? Hi David - I'll let you know when my first PC is upgraded to Vista, oh in five or six years maybe. Win2K is still on almost all my windows boxen. One or two are running XP. Good luck. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
