Re: [ntp:questions] GPS and NTP Server
Hallo Noosh, Yes, it's possible. What sort of GPS receiver do you have? For serious timekeeping, you should have a GPS with a PPS output signal; that can achieve accuracy much better than 1 millisec. Otherwise, you can configure the GPS to send NMEA sentences to the computer. The documentation page http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html gives details of the NTP configuration. You can find more documentation that will help to get you started at http://support.ntp.org/bin/view/Support/WebOrder. What sort of computer and operating system are you using? You may need to configure and compile the source files in order to include support for your refclock. If you ask us specific questions, we can help you better. Paul On Jan 30, 8:16 am, noosh <[EMAIL PROTECTED]> wrote: > Hi > > I Have a GPS and NTP Server. is it possible for NTP server to get time > from GPS if i connecte the server to GPS by serial port? if yes, how > should do it? what should be the ntp.conf ? > > Thanks ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
"Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [...] > I can imagine an RTT of 60-70ms. What I have difficulty imagining is > using such a source to synch with. Pfft. Kids these days. (There's nothing wrong with an RTT of 60 to 70 ms per se. For example, if it were always exactly 65 ms, that would probably be an *excellent* time source. The problem is the jitter, and as the example of the four possible paths along the two possible routes shows, even that can, under the right circumstances, be solved.) Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > "David L. Mills" <[EMAIL PROTECTED]> writes: > > These configurable features are in the current snapshot, so that can > > do the same things. > I'll set one up locally (inside the firewall) and see if I have better > luck with it than with rackety. Configured my own ntpd with avg 15 min 5, I now get KoDs from 127.0.0.1 as expected. I'd like to say in passing that SNTP is one of the neatest and best- documented network protocols I've ever seen :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
"David L. Mills" <[EMAIL PROTECTED]> writes: > Yes. The rackety.udel.edu NTP server has KoD enabled and an average > headway threshold of 16 s. If you send packets at less than 2-s > headway or less tha 16-s average headway, you should get a KoD > RATE. If you are not authenticated, pogo.udel.edu should spit KoD AUTH > at you. But, note that KoDs themselves are rate limited to no more > than two per second. Hmm, I've been sending requests at one-second intervals without getting KoDs back. It might have something to do with being behind a NAT - perhaps rackety doesn't mind as long each request comes from a different port? > These configurable features are in the current snapshot, so that can > do the same things. I'll set one up locally (inside the firewall) and see if I have better luck with it than with rackety. Thanks for your help, DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Maarten Wiltink wrote: > "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > [...] > >>I can imagine an RTT of 60-70ms. What I have difficulty imagining is >>using such a source to synch with. > > > Pfft. Kids these days. > > (There's nothing wrong with an RTT of 60 to 70 ms per se. For example, if > it were always exactly 65 ms, that would probably be an *excellent* time > source. The problem is the jitter, and as the example of the four possible > paths along the two possible routes shows, even that can, under the right > circumstances, be solved.) > > Groetjes, > Maarten Wiltink > > Well, since the maximum error in transmitting time from server to client is one half the round trip delay, it is usually wise to try to minimize that delay. A server in Tokyo might have the time correct to within 50 nanoseconds but that does me little good in New Jersey! The network path would be so long and pass through so many routers and switches that by the time it gets to me, the uncertainty will be a substantial fraction of a second. Usually, the number of possible paths will be far greater than four! The ultimate test is the actual performance under the stated conditions. Based on general principles, the stated conditions are NOT where I would look first for best performance. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Richard B. Gilbert wrote: > Maarten Wiltink wrote: >> "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> [...] >> >>> I can imagine an RTT of 60-70ms. What I have difficulty imagining is >>> using such a source to synch with. >> >> >> Pfft. Kids these days. >> >> (There's nothing wrong with an RTT of 60 to 70 ms per se. For example, if >> it were always exactly 65 ms, that would probably be an *excellent* time >> source. The problem is the jitter, and as the example of the four >> possible >> paths along the two possible routes shows, even that can, under the right >> circumstances, be solved.) >> >> Groetjes, >> Maarten Wiltink >> >> > > Well, since the maximum error in transmitting time from server to client > is one half the round trip delay, it is usually wise to try to minimize > that delay. A server in Tokyo might have the time correct to within 50 > nanoseconds but that does me little good in New Jersey! The network > path would be so long and pass through so many routers and switches that > by the time it gets to me, the uncertainty will be a substantial > fraction of a second. > > Usually, the number of possible paths will be far greater than four! > > The ultimate test is the actual performance under the stated conditions. > Based on general principles, the stated conditions are NOT where I would > look first for best performance. > Which is why NTP prefers the source with the smallest delay. The system I am using has servers whose delays are 51ms to 94. I can't find any closer. On my company LAN, the delays range from 16ms to 87ms. The offsets of all these servers agree to within 9ms. Sure, I am not going to get sub-millisecond from that, but I think it is probably more typical than your set-up. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
"David L. Mills" <[EMAIL PROTECTED]> writes: > These configurable features are in the current snapshot, so that can > do the same things. One question, what is the range of the "monitor" value on a "discard" line in ntp.conf? My understanding is that if "monitor" is e.g. 10%, it will only send out KoD for 10% of offending requests, is that correct? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Brian Utterback wrote: [] > Which is why NTP prefers the source with the smallest delay. The > system I am using has servers whose delays are 51ms to 94. I can't > find any closer. On my company LAN, the delays range from 16ms to > 87ms. The offsets of all these servers agree to within 9ms. Sure, I > am not going to get sub-millisecond from that, but I think it is > probably > more typical than your set-up. > > Brian Utterback Brian, I know this is supposed to happen, but I recall seeing behaviour some time ago where a server with a little more jitter and much more delay was preferred, almost as if it was the jitter/offset which was the measure rather than offset itself. I ended up adding a "prefer" qualifier. Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
David J Taylor wrote: > Brian Utterback wrote: > [] >> Which is why NTP prefers the source with the smallest delay. The >> system I am using has servers whose delays are 51ms to 94. I can't >> find any closer. On my company LAN, the delays range from 16ms to >> 87ms. The offsets of all these servers agree to within 9ms. Sure, I >> am not going to get sub-millisecond from that, but I think it is >> probably >> more typical than your set-up. >> >> Brian Utterback > > Brian, > > I know this is supposed to happen, but I recall seeing behaviour some time > ago where a server with a little more jitter and much more delay was > preferred, almost as if it was the jitter/offset which was the measure > rather than offset itself. I ended up adding a "prefer" qualifier. > > Cheers, > David Doesn't ntpd choose a peer based on stratum also? Maybe that was the issue there. -- Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
Dag-Erling, Well, there's a reason. In the past serveral days 15 rascals have been punished for rate exceed, one of them continuously at 3 others at 11 and 13 s. The problem is that the rate limit of two KoDs per seconds is itself exceeded and the packet is not sent. The system statistics show a total ove about 1000 packets per hour dropped due rate exceeded of about 3 received packets per hour. If you set up a test locally, include the restrict default limited kod line in the configuration file. Dave Dag-Erling Smørgrav wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > >>Yes. The rackety.udel.edu NTP server has KoD enabled and an average >>headway threshold of 16 s. If you send packets at less than 2-s >>headway or less tha 16-s average headway, you should get a KoD >>RATE. If you are not authenticated, pogo.udel.edu should spit KoD AUTH >>at you. But, note that KoDs themselves are rate limited to no more >>than two per second. > > > Hmm, I've been sending requests at one-second intervals without getting > KoDs back. It might have something to do with being behind a NAT - > perhaps rackety doesn't mind as long each request comes from a different > port? > > >>These configurable features are in the current snapshot, so that can >>do the same things. > > > I'll set one up locally (inside the firewall) and see if I have better > luck with it than with rackety. > > Thanks for your help, > > DES ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
David J Taylor wrote: > Brian Utterback wrote: > [] >> Which is why NTP prefers the source with the smallest delay. The >> system I am using has servers whose delays are 51ms to 94. I can't >> find any closer. On my company LAN, the delays range from 16ms to >> 87ms. The offsets of all these servers agree to within 9ms. Sure, I >> am not going to get sub-millisecond from that, but I think it is >> probably >> more typical than your set-up. >> >> Brian Utterback > > Brian, > > I know this is supposed to happen, but I recall seeing behaviour some time > ago where a server with a little more jitter and much more delay was > preferred, almost as if it was the jitter/offset which was the measure > rather than offset itself. I ended up adding a "prefer" qualifier. > > Cheers, > David > > I mis-spoke. It is actually the case that NTP prefers the sample of the eight from any one single source that has the least delay. After the sample is chosen, the samples from all the servers are then subjected to different criteria to determine which will be the final choice. Jitter and stratum both factor in. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Brian Utterback wrote: [] > I mis-spoke. It is actually the case that NTP prefers the sample of > the eight from any one single source that has the least delay. After > the sample is chosen, the samples from all the servers are then > subjected to different criteria to determine which will be the final > choice. Jitter and stratum both factor in. > > Brian Utterback Thanks for that clarification, Brian. David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Brian Utterback wrote: > Richard B. Gilbert wrote: > >> Maarten Wiltink wrote: >> >>> "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message >>> news:[EMAIL PROTECTED] >>> [...] >>> I can imagine an RTT of 60-70ms. What I have difficulty imagining is using such a source to synch with. >>> >>> >>> >>> Pfft. Kids these days. >>> >>> (There's nothing wrong with an RTT of 60 to 70 ms per se. For >>> example, if >>> it were always exactly 65 ms, that would probably be an *excellent* time >>> source. The problem is the jitter, and as the example of the four >>> possible >>> paths along the two possible routes shows, even that can, under the >>> right >>> circumstances, be solved.) >>> >>> Groetjes, >>> Maarten Wiltink >>> >>> >> >> Well, since the maximum error in transmitting time from server to >> client is one half the round trip delay, it is usually wise to try to >> minimize that delay. A server in Tokyo might have the time correct to >> within 50 nanoseconds but that does me little good in New Jersey! The >> network path would be so long and pass through so many routers and >> switches that by the time it gets to me, the uncertainty will be a >> substantial fraction of a second. >> >> Usually, the number of possible paths will be far greater than four! >> >> The ultimate test is the actual performance under the stated conditions. >> Based on general principles, the stated conditions are NOT where I >> would look first for best performance. >> > > Which is why NTP prefers the source with the smallest delay. The system > I am using has servers whose delays are 51ms to 94. I can't find any > closer. On my company LAN, the delays range from 16ms to 87ms. The > offsets of all these servers agree to within 9ms. Sure, I am not > going to get sub-millisecond from that, but I think it is probably > more typical than your set-up. > > Brian Utterback I think NTP uses more than the delay to select a server. ISTR that it's one half the round trip delay plus something else. The resulting quantity is called the "synchronization distance". I have forgotten just what the something else is and I'm too lazy to look it up. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Dennis Hilberg, Jr. wrote: > David J Taylor wrote: >> Brian Utterback wrote: >> [] >>> Which is why NTP prefers the source with the smallest delay. The >>> system I am using has servers whose delays are 51ms to 94. I can't >>> find any closer. On my company LAN, the delays range from 16ms to >>> 87ms. The offsets of all these servers agree to within 9ms. Sure, I >>> am not going to get sub-millisecond from that, but I think it is >>> probably >>> more typical than your set-up. >>> >>> Brian Utterback >> >> Brian, >> >> I know this is supposed to happen, but I recall seeing behaviour >> some time ago where a server with a little more jitter and much more >> delay was preferred, almost as if it was the jitter/offset which was >> the measure rather than offset itself. I ended up adding a "prefer" >> qualifier. Cheers, >> David > > Doesn't ntpd choose a peer based on stratum also? Maybe that was the > issue there. Indeed it does, but IIRC the remote server was at the same or higher stratum. Since using "prefer" and my own GPS-based stratum 1 server I don't see the issue any more. Cheers David David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS ->NTP time server
Rob van der Putten <[EMAIL PROTECTED]> writes: >Hi there >root wrote: >> No GPS NMEA should not do that. The length of the sentence is almost fixed >> length, so the timing on it should vary by perhaps a few msec, as you found, >> certainly not by seconds. It sounds like you have troubles. >> >> You could try using minicom ( assuming you are on Linux) to look at the >> output >> on the serial port. ... >My Garmin was sending to much data, sending a NMEA sentence once per >second. So I put '$PGRMO,,4' in a file and send it to the Garmin. >Now it's at six lines per second; GPRMC, GPGGA, GPGSA and three GPGSV >lines (plus one PGRMT per minute). This is confusing. You first say that one NMEA sentence pers second is too much data, and then that youarranged that it sent 6 sentences per second. Note that only one sentence ( which should take about 140ms at 4800Bd) is allo you need. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Brian Utterback <[EMAIL PROTECTED]> writes: >Unruh wrote: >> "David L. Mills" <[EMAIL PROTECTED]> writes: >> >>> Unruh, >> >>> It would seem self evident from the equations that minimizing the delay >>> variance truly does minimize the offset variance. Further evidence of >>> that is in the raw versus filtered offset graphs in the architecture >>> briefings. If nothing else, the filter reduces the variance by some 10 >>> dB. More to the point, emphasis added, the wedge scattergrams show just >> >> I guess then I am confused because my data does not support that. While the >> delay variance IS reduced, the offset variance is not. The correleation >> between dely and offset IS reduced by a factor of 10, but the clock >> variance is reduced not at all. >> >> Here are the results from one day gathered brom one clock (I had ntp not >> only print out the peer->offset peer->delay as it does in the >> record_peer_stats , but also the p_offset and p_del, the offset and delays >> calculated for each packet. I alsy throw out the outliers ( for some reason >> the system would all of a sudden have packets with were 4ms round trip, >> rather than 160usec. These "popcorn" spikes are clearly bad. The difference >> between the variance as calculated from the peer->offset values, and the >> p_offset values was >> >I do not know your network configuration at all, so I am just guessing, >but My guess is that you are talking about a client connected on the >same subnet with one or more servers, right? Connected by ethernet? Yes, it is on the same submet. Typical round trip is 160usec. I agree that a 4ms in 40 or 400 would not be as noticeable. Those spikes appear to be network switches forgetting the arp entries when the system is at max poll of 10 or more. >In that case, you are talking about a situation where the error >introduced by factors that increase in correlation with the round >trip time is minimal at best. When they do kick in, you see what >looks like huge jumps and filter them. A 4ms increase is just what >you would expect when ethernet timers kick in. Now imagine a RTT of >60-70ms. A 9ms delay from a collision introduces a 4ms change in the >delay value and a 2ms change in the offset, but with a delay might not >perturb the delay value enough to make it obviously an outlyer. Again while I understand the desire for robustness, designing npt so it always assumes very worst case scenario seems like overkill. Very few people are 160msec away from servers. Also the use of "pre" packets ( whether ping or ntp) really would be useful in ntp precisely to wake up switches and reduce these kinds of switch delays. Ie solutions which try to get the best data afre better than solutions which trow away most of the data. (I had a stretch of 15 consecutive data thrown out by the clock filter-- so my hypothetical is absolutely not hypothetical) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Guys, There seems to be widespread misunderstanding about how ntpd ranks the survivors. The sort ranks the survivors first by stratum and then by what the spec calls root distance within the same stratum. Root distance is calculated as one-half the root roundtrip delay plus the root dispersion plus the jitter. This is the maximum error of the client relative to the primary source. Note that jitter usually plays only a small part in the calculation, unless there is some timequake or other dramtic event at the server. Sometimes oneor more of these quantities changes dramatically due to a timequake or maybe the server has lost all its sources for awhile. So, before you conclude ntpd is doing something evil, check each of the contributions to root distance. The result of the sort is usually the first entry on the list, but even that can be temporarily displaced by the anti-clockhop algorithm. Other than this wiggle, it can be truthfully said that the algorithm selects the servers at the lowest stratum and from among those at that stratum the candidate with the lowest maximum error. You may argue this is not your goal; you might want the lowest jitter and disregard all else. Be advised the criteria needs to be stable and not change a lot very fast; otherwise, clockhopping can easily become clockleaping. Dave David J Taylor wrote: > Brian Utterback wrote: > [] > >>Which is why NTP prefers the source with the smallest delay. The >>system I am using has servers whose delays are 51ms to 94. I can't >>find any closer. On my company LAN, the delays range from 16ms to >>87ms. The offsets of all these servers agree to within 9ms. Sure, I >>am not going to get sub-millisecond from that, but I think it is >>probably >>more typical than your set-up. >> >>Brian Utterback > > > Brian, > > I know this is supposed to happen, but I recall seeing behaviour some time > ago where a server with a little more jitter and much more delay was > preferred, almost as if it was the jitter/offset which was the measure > rather than offset itself. I ended up adding a "prefer" qualifier. > > Cheers, > David > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
Dag-Erling, The rate violation is caught in the MRU list, which can be retrieved using ntpdc and the monlist command. When the number of clients is small, the list can be retrieved over the net. When the number of clients is larte, like several hundred, there are many UDP packets and one or more are usually dropped. The solution at present is to run ntpdc on the server machine and pipe the monlist output to a local file. Each time a KoD is sent a counter is increased by one. Once each second the counter is decreased by one. If an offending packet arrives and the counter is less than 2, a KoD is sent; otherwise, the packet is dropped without further action. There probably should be some triage, but not without additional complexity. Dave Dag-Erling Smørgrav wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > >>These configurable features are in the current snapshot, so that can >>do the same things. > > > One question, what is the range of the "monitor" value on a "discard" > line in ntp.conf? > > My understanding is that if "monitor" is e.g. 10%, it will only send out > KoD for 10% of offending requests, is that correct? > > DES ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
On 2008-01-30, Unruh <[EMAIL PROTECTED]> wrote: > Again while I understand the desire for robustness, designing [NTP] > so it always assumes very worst case scenario seems like overkill. > Very few people are 160msec away from servers. Also the use of "pre" > packets ( whether ping or ntp) really would be useful in ntp precisely > to wake up switches and reduce these kinds of switch delays. If you wish to have a specific feature in NTP you can add it yourself using the source which is available for download from: http://www.ntp.org/downloads.html http://support.ntp.org/download If you want someone else to do the work please consider joining the NTP Forum http://ntpforum.isc.org/ to help fund development. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
Unruh wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > >> David, > >> We can argue about the Hurst parameter, which can't be truly random-walk >> as I have assumed, but the approximation is valid up to lag times of at >> least a week. However, as I have been cautioned, these plots are really >> sensitive to spectral lines due to nonuniform sampling. I was very >> careful to avoid such things. > > But the "lines" I am refering to are not artifacts, they are there because > of the way the computer is used. -- the temp fluctuations caused by people > running the machine daily, except on weekends. These are not part of any > "random walk" process. They are real jumps in the drift rate of the > machine, large jumps, and definitely not random. > Well of course. You are running Linux and losing interrupts. FreeBSD and friends don't suffer from that problem. I seem to remember setting HZ=100 mostly eliminates that problem, at the price of rebuilding the kernel. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] why is my pool server's offset so bad
Well, its gotten bad again. I had it working well for a few days. But lately, the offsets are diving down. See http://www.pool.ntp.org/scores/70.184.242.241 Clearly something is wrong. Thanks pat ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] why is my pool server's offset so bad
Pat Farrell wrote: > Well, its gotten bad again. I had it working well for a few days. > But lately, the offsets are diving down. See > http://www.pool.ntp.org/scores/70.184.242.241 > > Clearly something is wrong. > > Thanks > pat Sorry about that. How about supplying some USEFUL information about your server! Knowing what O/S you are running on which hardware platform, what version of ntpd you are running, what reference clock or upstream servers you are using, etc, etc, MIGHT help someone trouble shoot the problem!!! It might be helpful to start with the ntpq -p "banner". It has been my experience that ntpd, when properly configured with good servers and, optionally, a good ref clock, keeps time very well indeed. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] why is my pool server's offset so bad
On Wed, 30 Jan 2008 23:40:17 -0500, Richard B. Gilbert wrote: >> But lately, the offsets are diving down. See >> http://www.pool.ntp.org/scores/70.184.242.241 > Sorry about that. How about supplying some USEFUL information > about your server! Knowing what O/S you are running on which hardware > platform, what version of ntpd I opened it up for general queries so you can ntpq -p and see. Its a debian Etch on a dual Xeon (intel 32) platform. ntpd 4.2.2p4 Its got no real clocks, its just a load sharing device, getting good time from overworked upstream ntp servers and sharing it with the world > It might be helpful to start with the ntpq -p "banner". Don't know what you mean by 'banner' here is ntpq -p [EMAIL PROTECTED]:/etc$ ntpq -p remote refid st t when poll reach delay offset jitter == ntp-2.cns.vt.ed 198.82.247.402 u 31h 640 17.908 -0.296 0.000 ntp-4.cns.vt.ed 198.82.247.164 2 u 31h 640 18.5670.637 0.000 ancalagon.cede. .INIT. 16 u- 102400.0000.000 0.000 prometheus.acm. .. 16 u 31h 6400.0000.000 0.000 time-b.nist.gov .ACTS. 1 u 31h 640 13.5556.162 0.000 > It has been my experience that ntpd, when properly configured with good > servers and, optionally, a good ref clock, keeps time very well indeed. It was my experience that for four or five months, the server scored 20 constantly. Recently, not so much. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] why is my pool server's offset so bad
Pat Farrell wrote: > Well, its gotten bad again. I had it working well for a few days. > But lately, the offsets are diving down. See > http://www.pool.ntp.org/scores/70.184.242.241 > > Clearly something is wrong. > > Thanks > pat saturn:$ ntpq -p 70.184.242.241 remote refid st t when poll reach delay offset jitter ntp-2.cns.vt.ed 198.82.247.40 2 u 32h 640 17.908 -0.296 0.000 ntp-4.cns.vt.ed 198.82.247.164 2 u 32h 640 18.5670.637 0.000 ancalagon.cede. .INIT. 16 u- 102400.0000.000 0.000 prometheus.acm. .Ïôð. 16 u 32h 6400.0000.000 0.000 time-b.nist.gov .ACTS. 1 u 32h 640 13.5556.162 0.000 The reachability column for each upstream server is at zero, indicating that ntpd can't connect to those servers. Your system clock has been wandering for approx. the last 32 hours, which is about the same time your offset history began to take a dive. Have you inadvertently blocked outbound traffic on 123/UDP? I can query your server just fine, so inbound is not a problem. -- Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] why is my pool server's offset so bad
Pat Farrell wrote: > On Wed, 30 Jan 2008 23:40:17 -0500, Richard B. Gilbert wrote: > >>>But lately, the offsets are diving down. See >>>http://www.pool.ntp.org/scores/70.184.242.241 >> > >>Sorry about that. How about supplying some USEFUL information >>about your server! Knowing what O/S you are running on which hardware >>platform, what version of ntpd > > > I opened it up for general queries so you can ntpq -p and see. > > Its a debian Etch on a dual Xeon (intel 32) platform. > ntpd 4.2.2p4 > Its got no real clocks, its just a load sharing device, getting good time > from overworked upstream ntp servers and sharing it with the world > > >>It might be helpful to start with the ntpq -p "banner". > > > Don't know what you mean by 'banner' > here is ntpq -p > > [EMAIL PROTECTED]:/etc$ ntpq -p > remote refid st t when poll reach delay offset jitter > == > ntp-2.cns.vt.ed 198.82.247.402 u 31h 640 17.908 -0.296 0.000 > ntp-4.cns.vt.ed 198.82.247.164 2 u 31h 640 18.5670.637 0.000 > ancalagon.cede. .INIT. 16 u- 102400.0000.000 0.000 > prometheus.acm. .. 16 u 31h 6400.0000.000 0.000 > time-b.nist.gov .ACTS. 1 u 31h 640 13.5556.162 0.000 > The above is what I mean by "banner". Yours says that it has been 31 hours since four of your servers last responded to queries!! It would appear that "ancalagon.cede." has NEVER responded since ntpd was started! I just did my own ntpq -p and it is now claiming 32 hours since anybody responded. Obviously you have not unplugged your network cable but there must be SOME reason why no one will talk to you! Could you have done something so naughty that your servers have sent you the "Kiss Of Death"? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Ultralink 325 WWVB receiver
I recently snagged an Ultralink 325 WWVB receiver off Ebay to use as a refclock with an ntp server, hoping to peer that one and my gps-referenced ntp server together. The unit works fine, and I get good signal (R5) most of the time, as shown in the clockstats file. The behavior is a little odd though, compared to what I'm used to with my with my gps-referenced ntp server: After fudging out an initial offset of about 280 ms, I noticed the offset will travel a 10 ms range towards the negative. For example, if the offset initially starts at say 0.500, it will gradually, in about 0.300 - 0.400 ms steps, make it's way to about -0.500. Once it reaches the low end, it will jump back up to 0.500 and start its decent over. I'm assuming this is fairly typical, as I observed a different WWVB machine and it shows similar stepping behavior within a range. The initial offset changes also. One time it was 280 ms, another time it was 960 ms. The most recent time I didn't use any correction at all initially. All that aside, the machine's offset seems to wander around quite a bit compared to my gps-referenced ntp server. I haven't noticed any specific pattern to it though. I've repeatedly tried to fudge out the offset, but it seems to wander right back to about a 4.5 ms offset compared to my gps-referenced ntp server. Coincidentally (or not), this is also about what I've calculated my propagation delay to be based on information Dave Mills posted in another thread. Do I include the propagation delay in the fudge factor, or is there a separate step for that? The docs say the unit is capable of +- 1 ms accuracy, so perhaps I'm missing something. Are there special steps that need to be taken for WWVB receivers? The unit's user manual, the driver documentation and source code didn't reveal any secrets. Thanks for any help, Dennis -- Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
