Re: [ntp:questions] Accuracy of NTP - Advice Needed
Danny Mayer wrote: > On 12/27/2011 8:48 PM, j...@specsol.spam.sux.com wrote: >> Danny Mayer wrote: >>> On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: John Hasler wrote: >> The open sky nearest the OPERA detector is straight up through 1400m of >> rock. > > Jim Pennino writes: >> And the easiest open sky to get to is horizontally down the tunnel to >> the entrance which is next to a freeway. > > Yes, the entrance is next to a freeway. The entrance to the LNGS > facility where the OPERA detector is located is near the middle of the > 10 km long Gran Sasso highway tunnel. The bottom line is that the only thing that is relevant is how easy it is to get to a GPS antenna with an open view of the sky. Everything else is bloviation. >>> >>> GPS is not used for this kind of thing, they are too inaccurate, so it >>> doesn't matter. They use atomic clocks. >>> >>> Danny >> >> How do you measure distance with an atomic clock? >> >> > > That's a complex question. GPS (even the military version) is not > accurate enough. > > Danny No, it is not complex; you can't measure distance with an atomic clock. An atomic clock is used to measure time intervals. As for GPS, it is pretty trivial these days to determine an absolute location to parts of a centimeter for a fixed location. -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server pool advice
On 2011-12-27, Danny Mayer wrote: > On 12/27/2011 1:16 PM, unruh wrote: >> On 2011-12-27, Danny Mayer wrote: >>> On 12/26/2011 11:17 PM, ben slimup wrote: Thanks Danny for your reply, but is it a big problem, if the client round-trip packet comes from a different servers each time? why? >>> >>> Because NTP uses multiple packets to gain data on the round-trip delay, >>> jitter, etc. of each server it gets responses from. The round-trip delay >> >> No it doesn't. It uses one outbound and one inbound packet to get the >> delay time. Ie, one packet arrives at the server, and one exits the >> server. Now if you are talking about statistics, that is different, and >> using many will increase the jitter. If the two machines are "good" then >> their times should agree within the jitter anyway. >> >>> is different if it comes from different systems. In addition each system >>> has its own idea of what the correct time is and at the point that it >>> receives and sends out the reply packet. The resulting data points will >> >> Not if they are all synchronised to UTC. >> > > What UTC is is not necessarily exactly identical. NIST has one idea of > it and NPL (UK) has a slightly different idea. However that is not what The ns scale difference is irrelevant to the synchronization of computers. That is us, not sub ns. > I was referring to. Each server gets its information from different > sources whether it's a refclock, GPS, another server, etc.. As such > these sources differ somewhat from each other and while NTP tries to get > the best answer possible, each server will have a slight different > answer to the question. They may be only milliseconds apart but they > will be different. No. They will be perhaps usec apart if we are talking about computers. ns if we are talking about atomic clocks. And that will simply disappear into the jitter of the network connections. > > Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 2011-12-28, Danny Mayer wrote: > On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: >> John Hasler wrote: The open sky nearest the OPERA detector is straight up through 1400m of rock. >>> >>> Jim Pennino writes: And the easiest open sky to get to is horizontally down the tunnel to the entrance which is next to a freeway. >>> >>> Yes, the entrance is next to a freeway. The entrance to the LNGS >>> facility where the OPERA detector is located is near the middle of the >>> 10 km long Gran Sasso highway tunnel. >> >> The bottom line is that the only thing that is relevant is how easy it is >> to get to a GPS antenna with an open view of the sky. >> >> Everything else is bloviation. > > GPS is not used for this kind of thing, they are too inaccurate, so it > doesn't matter. They use atomic clocks. No they do not. They use GPS. As has been discussed here gps can be made accurate to a few ns. GPS is used by radio astronomers to synchronize very long baseline arrays. (Yes, I also thought that gps was not accurate enough. I was wrong) > > Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 2011-12-28, Danny Mayer wrote: > On 12/27/2011 9:08 PM, John Hasler wrote: >> Danny writes: >>> GPS is not used for this kind of thing, they are too inaccurate, so it >>> doesn't matter. They use atomic clocks. >> >> The requirement is for synchronization. They use common view GPS. > > That's not good enough for experiments like this. In what way is it not good enough? The neutrinos are apparently arriving about 60 nanoseconds early, the distance is known, through GPS to 10's of centimeters, and the time is synchronized, again through GPS (although a second method is used as a double check) to about 1 nanosecond. In what fashion is it 'not good enough'? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
Greg Hennessy wrote: >>> The bottom line is that the only thing that is relevant is how easy it is >>> to get to a GPS antenna with an open view of the sky. >>> >>> Everything else is bloviation. >> >> GPS is not used for this kind of thing, they are too inaccurate, so it >> doesn't matter. They use atomic clocks. > > GPS is indeed used for the measurement of the time of flight in the > CERN and Fermilab experiments. You should read the papers. They use > GPS to get time to the order of nanosecond accuracy. What a concept; someone that actually read the papers instead of just pulling crap out their ass and arm waving. Prepare to be inundated with drivel for actually knowing something. -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
On Wed, Dec 28, 2011 at 00:51, Danny Mayer wrote: > No you don't want to do DNS over TCP if you can avoid it. It would be a > major hit on the resolver servers and with the kind of high volume that > you get as mobile devices make increasing use of such networks. You want > WiFi to drop UDP packets if they are lost rather than attempting to > retransmit them. I do indeed, but UDP is treated as guaranteed by WiFi, and I expect the reason is DNS over UDP otherwise becomes a user experience killer due to extra seconds of wait for each loss. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 12/27/2011 10:39 PM, Greg Hennessy wrote: >>> The bottom line is that the only thing that is relevant is how easy it is >>> to get to a GPS antenna with an open view of the sky. >>> >>> Everything else is bloviation. >> >> GPS is not used for this kind of thing, they are too inaccurate, so it >> doesn't matter. They use atomic clocks. > > GPS is indeed used for the measurement of the time of flight in the > CERN and Fermilab experiments. You should read the papers. They use > GPS to get time to the order of nanosecond accuracy. > You can read some of this here: http://www.wired.com/wiredscience/2011/09/scientists-question-neutrinos/ It's not too technical but describes the basic setup. Yes they did use GPS to get accurate locations of the equipment but it's a rather complex and hard to get right. They then used Cesium atomic clocks for timing the events. The calculations you have to do for all this is mind-boggling and there is a lot of work that has to go into ensuring that they are accurate and nothing got missed. That's the principle reason that it's hard to be sure that an FTL result was obtained. There are lots of scientists pouring over calculations (there were something like 150 authors listed on the paper published in arXiv. Hords of other scientists are also analyzing the data. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
At 10:40 PM 12/27/2011, Danny Mayer wrote... On 12/27/2011 9:08 PM, John Hasler wrote: > The requirement is for synchronization. They use common view GPS. That's not good enough for experiments like this. You say that as if it's a fact. You're on the wrong list to just make such an unsupported statement, there are people here who know better. Support your argument with authoritative references, such as these: http://www.boulder.nist.gov/timefreq/general/pdf/192.pdf http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=278607 http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA508388 http://tf.nist.gov/general/pdf/1379.pdf Here's a representative quote: "When averaged past one day, the time deviation of the multi-channel common-views remains between 1 to 2 ns, while the noise of the single-channel GPS common-view drops below 1 ns for averaging longer than 2 days." ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
>> The bottom line is that the only thing that is relevant is how easy it is >> to get to a GPS antenna with an open view of the sky. >> >> Everything else is bloviation. > > GPS is not used for this kind of thing, they are too inaccurate, so it > doesn't matter. They use atomic clocks. GPS is indeed used for the measurement of the time of flight in the CERN and Fermilab experiments. You should read the papers. They use GPS to get time to the order of nanosecond accuracy. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 12/27/2011 9:08 PM, John Hasler wrote: > Danny writes: >> GPS is not used for this kind of thing, they are too inaccurate, so it >> doesn't matter. They use atomic clocks. > > The requirement is for synchronization. They use common view GPS. That's not good enough for experiments like this. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 12/27/2011 8:48 PM, j...@specsol.spam.sux.com wrote: > Danny Mayer wrote: >> On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: >>> John Hasler wrote: > The open sky nearest the OPERA detector is straight up through 1400m of > rock. Jim Pennino writes: > And the easiest open sky to get to is horizontally down the tunnel to > the entrance which is next to a freeway. Yes, the entrance is next to a freeway. The entrance to the LNGS facility where the OPERA detector is located is near the middle of the 10 km long Gran Sasso highway tunnel. >>> >>> The bottom line is that the only thing that is relevant is how easy it is >>> to get to a GPS antenna with an open view of the sky. >>> >>> Everything else is bloviation. >> >> GPS is not used for this kind of thing, they are too inaccurate, so it >> doesn't matter. They use atomic clocks. >> >> Danny > > How do you measure distance with an atomic clock? > > That's a complex question. GPS (even the military version) is not accurate enough. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
Danny Mayer wrote: > On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: >> John Hasler wrote: The open sky nearest the OPERA detector is straight up through 1400m of rock. >>> >>> Jim Pennino writes: And the easiest open sky to get to is horizontally down the tunnel to the entrance which is next to a freeway. >>> >>> Yes, the entrance is next to a freeway. The entrance to the LNGS >>> facility where the OPERA detector is located is near the middle of the >>> 10 km long Gran Sasso highway tunnel. >> >> The bottom line is that the only thing that is relevant is how easy it is >> to get to a GPS antenna with an open view of the sky. >> >> Everything else is bloviation. > > GPS is not used for this kind of thing, they are too inaccurate, so it > doesn't matter. They use atomic clocks. > > Danny How do you measure distance with an atomic clock? -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
Danny writes: > GPS is not used for this kind of thing, they are too inaccurate, so it > doesn't matter. They use atomic clocks. The requirement is for synchronization. They use common view GPS. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
On 12/24/2011 8:11 PM, Dave Hart wrote: > On Sat, Dec 24, 2011 at 18:18, unruh wrote: >> On 2011-12-24, David J Taylor wrote: >>> - one Netbook PC worked very well on a LAN connection (about 1 ms steady >>> jitter). However, when moving to a Wi-Fi connection after a power-down >>> reboot, the reported jitter gradually built up over about a 30 minute >>> period, ending up with a 5 ms peak, later decaying to a value between 1.3 >>> and 2.5 ms. The offset also appeared to have spikes which because much >>> worse after about 30 minutes. >> >> I would expect wifi to be much worse than a lan for jitter. The signal >> has to be converted, broadcast, reconverted and then sent on down the >> lan. That all takes time, and can have aproblem with dropped bits, >> retransmission, etc. > > Retransmission is the killer issue for NTP performance over 802.11. > For practical interop with software developed on wired networks, WiFi > equipment detects packet loss and triggers retransmission invisibly to > higher layers. I suspect NTP would do better if the 802.11 layer > differentiated its handling of UDP 53 and 123 :) Where dropping DNS > queries has an awful impact on user experience, it would be preferable > for NTP compared to introducing the extra delay and thereby jitter. > I'd love to see more DNS over TCP, so that perhaps one day layer 2 > wireless networks will do better letting UDP drop rather than > retransmit at layer 2. No you don't want to do DNS over TCP if you can avoid it. It would be a major hit on the resolver servers and with the kind of high volume that you get as mobile devices make increasing use of such networks. You want WiFi to drop UDP packets if they are lost rather than attempting to retransmit them. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: > John Hasler wrote: >>> The open sky nearest the OPERA detector is straight up through 1400m of >>> rock. >> >> Jim Pennino writes: >>> And the easiest open sky to get to is horizontally down the tunnel to >>> the entrance which is next to a freeway. >> >> Yes, the entrance is next to a freeway. The entrance to the LNGS >> facility where the OPERA detector is located is near the middle of the >> 10 km long Gran Sasso highway tunnel. > > The bottom line is that the only thing that is relevant is how easy it is > to get to a GPS antenna with an open view of the sky. > > Everything else is bloviation. GPS is not used for this kind of thing, they are too inaccurate, so it doesn't matter. They use atomic clocks. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 12/24/2011 1:11 PM, unruh wrote: > On 2011-12-24, John Hasler wrote: >> I wrote: >>> An upcoming experiment at Fermilab will observe neutrinos at both ends >>> (the far end will be in Minnesota). >> >> unruh writes: >>> Well, no. At best the electrons or muons at one end. >> >> At best the electrical pulse produced by a photomultiplier when struck >> by a photon generated when a muon or electron emitted as a result of a >> neutrino collision interacts with the detector medium (there are a >> variety of detector designs but photomultipliers are almost always >> involved). >> >> However, the use of similar or identical neutrino detectors at both ends >> means that systemic errors in delay estimation will tend to cancel. I >> assume that they will try to match up the timing equipment at both ends >> as well. > > Just saying, it is not the same neutrino that is being detected at both > ends. The detection probability is just too small. Thus again there is > the same inference that the timing at one end measures the same class of > things as teh timing at the other. > > Yes, the timing equipment is a worry. They require ns accuracy in the > timing and m accuracy in the distance. And the timing is not simply gps > ( although they could have gotten that wrong) but then that timing has > to be brought down into the mine a km or so below ground and > horizontally and that also has to be surveyed for the distance. You need a very good atomic clock at both ends that are synchronized to each other. Chances are very good that they have a number of them at each end. Nothing less than an atomic clock will do. Now what has this to do with the original question? Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server pool advice
On Tue, Dec 27, 2011 at 21:53, Terje Mathisen wrote: > Not for just 4 or 6, but if you have a lot and configure them with 'preempt' > then you will end up with a smaller active set, consisting of (mostly) > better servers, right? I haven't experimented with preempt, but I believe you're right as long as more than "tos maxclock" (default 10) are configured. However, that winnowing will be a startup process with a static result over each run of ntpd once enough preempt peers are discarded -- so if one of the 'winners' later goes offline, it will not be replaced to get back to maxclock sources. > However, even without this feature, simply listing all 6/8 servers, from > both ends of the country, will normally result in ntpd figuring out which > servers are better, and then dropping the rest very quickly back to poll > 1024. > > I.e. geographic load balancing without having to setup different ntp.conf > files for each group of clients. ntpd provides two other capabilities supporting common client configuration. manycast uses multicast solicitation by clients to automatically spin up maxclock associations, and can be used in client/server or mesh configurations. The associations thus started are preemptible and unicast client/server after discovery. Starting in ntpd 4.2.7, "pool" associations are implemented in the same way as maycastclient except the discovery of potential servers starts with a DNS round robin name, which could be in your DNS or (for example) pool.ntp.org, rather than with a multicast IP group address listened to by manycast servers. The earlier ntpd implementation of "pool" was a startup-only process of spinning up to the lesser of maxclock or the number of addresses received in the round robin response to the one-time DNS lookup at startup, so it also would not replace servers over time. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server pool advice
On 12/27/2011 1:16 PM, unruh wrote: > On 2011-12-27, Danny Mayer wrote: >> On 12/26/2011 11:17 PM, ben slimup wrote: >>> Thanks Danny for your reply, >>> >>> but is it a big problem, if the client round-trip packet comes from a >>> different servers each time? why? >>> >> >> Because NTP uses multiple packets to gain data on the round-trip delay, >> jitter, etc. of each server it gets responses from. The round-trip delay > > No it doesn't. It uses one outbound and one inbound packet to get the > delay time. Ie, one packet arrives at the server, and one exits the > server. Now if you are talking about statistics, that is different, and > using many will increase the jitter. If the two machines are "good" then > their times should agree within the jitter anyway. > >> is different if it comes from different systems. In addition each system >> has its own idea of what the correct time is and at the point that it >> receives and sends out the reply packet. The resulting data points will > > Not if they are all synchronised to UTC. > What UTC is is not necessarily exactly identical. NIST has one idea of it and NPL (UK) has a slightly different idea. However that is not what I was referring to. Each server gets its information from different sources whether it's a refclock, GPS, another server, etc.. As such these sources differ somewhat from each other and while NTP tries to get the best answer possible, each server will have a slight different answer to the question. They may be only milliseconds apart but they will be different. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server pool advice
Rob wrote: Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: ntp is by design load-balanced: You enter a bunch of servers for each client, the client will then monitor each server and decide which is currently performing best, sync to this one, while keeping the rest as backup/sanity check. This is not load-balancing. This is normally called redundancy or failover or similar. Load-balancing is distributing a large request load evenly over multiple servers, and that is not what ntp is doing when you configure multiple servers. Not for just 4 or 6, but if you have a lot and configure them with 'preempt' then you will end up with a smaller active set, consisting of (mostly) better servers, right? However, even without this feature, simply listing all 6/8 servers, from both ends of the country, will normally result in ntpd figuring out which servers are better, and then dropping the rest very quickly back to poll 1024. I.e. geographic load balancing without having to setup different ntp.conf files for each group of clients. Terje -- - "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] ntp server pool advice
On 2011-12-27, Danny Mayer wrote: > On 12/26/2011 11:17 PM, ben slimup wrote: >> Thanks Danny for your reply, >> >> but is it a big problem, if the client round-trip packet comes from a >> different servers each time? why? >> > > Because NTP uses multiple packets to gain data on the round-trip delay, > jitter, etc. of each server it gets responses from. The round-trip delay No it doesn't. It uses one outbound and one inbound packet to get the delay time. Ie, one packet arrives at the server, and one exits the server. Now if you are talking about statistics, that is different, and using many will increase the jitter. If the two machines are "good" then their times should agree within the jitter anyway. > is different if it comes from different systems. In addition each system > has its own idea of what the correct time is and at the point that it > receives and sends out the reply packet. The resulting data points will Not if they are all synchronised to UTC. > be so uneven if it's coming from the different systems that it will > never select that system as accurate and will almost certainly remove it > from the list of possible candidates. The data for each specific IP ??? > address is collected this way and compared to data from other IP > addresses. Load-balancing breaks that since it's really a different > system that it can get data from. Instead of load balancing you give > each system its own IP address and it can synchronize against those systems. I agree that it is not a good idea, but it is not a disasterous idea assuming your servers are "good" servers. > > Danny >> thank you again >> >>> Date: Mon, 26 Dec 2011 22:39:22 -0500 >>> From: ma...@ntp.org >>> To: "terje.mathisen at tmsw.no"@ntp.org >>> CC: questions@lists.ntp.org >>> Subject: Re: [ntp:questions] ntp server pool advice >>> >>> On 12/22/2011 6:40 AM, Terje Mathisen wrote: >>> > ben slimup wrote: >>> >> >>> >> Dear all, >>> >> >>> >> Thank you very much for support, >>> >> >>> >> i do not have 1000,000 client, i need those ntp servers to serve a >>> >> load between 10 to 100 clients >>> >> over a public network with an accuracy of 100ms >>> >> >>> >> those clients will use dns round robin to resolve 4 external ip, 2 IPs >>> >> on each site. >>> > >>> > DO NOT USE ROUND ROBIN DNS for NTP! >>> >>> You can use round robin dns for NTP. There's nothing wrong with that. >>> It's load balancing that must NOT be used as you would get different >>> answers from different systems each time. >>> >>> Danny >>> ___ >>> 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] ntp server pool advice
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > ben slimup wrote: >> >> Thank Danny and Dave, >> >> Your explanations are nice and clear. >> >> so in that case does it means that ntp protocol cannot be load >> balanced at all?? > > Rather the opposite! > > ntp is by design load-balanced: You enter a bunch of servers for each > client, the client will then monitor each server and decide which is > currently performing best, sync to this one, while keeping the rest as > backup/sanity check. This is not load-balancing. This is normally called redundancy or failover or similar. Load-balancing is distributing a large request load evenly over multiple servers, and that is not what ntp is doing when you configure multiple servers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server pool advice
On Dec 26, 2011, at 11:34 PM, ben slimup wrote: > so in that case does it means that ntp protocol cannot be load balanced at > all?? A load-balancer that provides session affinity based only upon source IP would function to some extent, but keeping track of all that state is vastly more work than generating NTP queries and responses, and going through a load-balancer adds delay that reduces timekeeping quality. Trying to load-balance NTP is like trying to load-balance ICMP pings. It's almost always going to be the wrong approach. > are there any ways to provide load balancing without disturbing ntp roundtrip > proccess? Yes: NTP is already designed with fault-tolerance built in. List multiple NTP servers in the client configuration, and let ntpd handle it from there. If some of the servers go down, or if some are too busy and they drop a query, ntpd on the clients will adjust reachability and continue to work just fine using the other servers. > since i have gotten a lot of devices here , i made a simple design that all > servers have their own public ip adresses. > but my concern is that design is my clients can handle only 4 ntp servers, > and to fit the requirement of 1million synch per poll, > i will need 8 servers at least.. > do you guys have any design idea that can handle such traffic after blackout > for example? Yes, you don't need to do anything. Once ntpd has been running for long enough to have good data, it determines and saves the intrinsic drift of the local clock from "true time" in order to keep the local clock running reasonably well even if all of the servers it was using drop off for a while. My best advice is that you set up a few NTP servers, and run some of your clients against them for a month or two as a trial or test, so that you gain the experience needed to figure out what you need to do for a larger deployment. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server pool advice
ben slimup wrote: Thank Danny and Dave, Your explanations are nice and clear. so in that case does it means that ntp protocol cannot be load balanced at all?? Rather the opposite! ntp is by design load-balanced: You enter a bunch of servers for each client, the client will then monitor each server and decide which is currently performing best, sync to this one, while keeping the rest as backup/sanity check. are there any ways to provide load balancing without disturbing ntp roundtrip proccess? If you have more than 4-6 servers, then you can use round-robin DNS to give each client a unique set of server IPs. Up to this number of servers, which is what you seem to be intending, you should simply let each client poll every server. The polling interval will quickly back off from the starting 64s, most client/server combinations will end up at the maximum (1024s) poll interval. since i have gotten a lot of devices here , i made a simple design that all servers have their own public ip adresses. but my concern is that design is my clients can handle only 4 ntp servers, and to fit the requirement of 1million synch per poll, i will need 8 servers at least.. do you guys have any design idea that can handle such traffic after blackout for example? If you configure minpoll 7, then you will never poll more often than every 128 s, right? With 1M clients, all talking to all servers (or at least all talking to the currently best server), that corresponds to less than 8000 requests/second. 8000 is safely below the 10K limit you have stated that each of your intended ntp servers can handle. However, I would instead leave the default (64 s/minpoll 6) minimum poll interval, but use round-robin DNS to let each client get a random group of 4 out of the 6 or 8 total servers. your help is really appreciated You still haven't told us what you want to do, i.e. what sort of system are you setting up? Terje -- - "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] ntp server pool advice
Danny Mayer wrote: On 12/22/2011 6:40 AM, Terje Mathisen wrote: ben slimup wrote: those clients will use dns round robin to resolve 4 external ip, 2 IPs on each site. DO NOT USE ROUND ROBIN DNS for NTP! You can use round robin dns for NTP. There's nothing wrong with that. It's load balancing that must NOT be used as you would get different answers from different systems each time. Sorry, you are of course correct. I read load-balancer and round-robin in the same message and conflated them. The pool project is a proof by existence that round robin works well for NTP! Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
