Re: [ntp:questions] Accuracy of NTP - Advice Needed
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Again, were do you see the word few in what I wrote? That makes the statement so meaningless. Every distance can be measured in feet. Of couse, nobody at Cern would even think of doing that, but that is another matter. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 12/25/2011 5:49 AM, Rob wrote: j...@specsol.spam.sux.comj...@specsol.spam.sux.com wrote: Again, were do you see the word few in what I wrote? That makes the statement so meaningless. Every distance can be measured in feet. Of couse, nobody at Cern would even think of doing that, but that is another matter. How many feet in a light year?? ;-) That should keep you out of trouble for a little while! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Again, were do you see the word few in what I wrote? That makes the statement so meaningless. Every distance can be measured in feet. If I had written exactly the same thing with the exception of using the word meters instead of the word feet, would you then get the point or would it still go whooshing over your head? -- 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?
You might look at the peerstats file and also look at the roundtrip time. I might be that occasionally one of the paths from wireless to computer gets shorter ( clearer signal?) and ntpd will then take that as a good value, and an earlier value, and try to correct for that offset- - which it does by stepping the frequency. This comment raises an interesting issue. There is a large, significant, and negative correlation between Delay and Offset. The larger the delay, the more toward minus infinity the offset tends. Recall that in the regression equation Y = BX + A, B is the correlation between the variables X and Y. So if the correlation is significant, this implies that there is a relation between them. I can't think of a physical relation between delay and offset, so if NTP finds a relation, there has to be something wrong. Charles Elliott -Original Message- From: questions-bounces+elliott.ch=verizon@lists.ntp.org [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of unruh Sent: Saturday, December 24, 2011 1:18 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps? On 2011-12-24, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Folks, I've recently been testing NTP 4.2.7p241 on a variety of Windows systems with almost uniformly excellent results. For me, it's the best version of NTP to date - thanks Dave Hart! However, it has now revealed a couple of issues which may be fundamental to NTP, or may be artefacts of the Windows implementation: - 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. Question: would you expect the reported jitter to increase over the first 30 minutes or so? Could be somone switched on a vacuum cleaner for example. - this same PC shows a frequency value which was steady around +1.7 ppm on the LAN connection. With the Wi-Fi connection, approximately every 90 minutes, the frequency offset takes a sudden negative step of about 0.4 ppm, which prevents NTP reaching the +1.7 ppm value it may be aiming for. There is nothing from NTP in the Event Log at the time of these jumps. These jumps in frequency do correspond to spikes in the offset values. That is now ntp works. All it knows is the current offset, and tries to get rid of it by changing the frequency. It does not know that there is a sudden step. I does not remember the old offset values. You might look at the peerstats file and also look at the roundtrip time. I might be that occasionally one of the paths from wireless to computer gets shorter ( clearer signal?) and ntpd will then take that as a good value, and an earlier value, and try to correct for that offset- - which it does by stepping the frequency. Question: why would the frequency show such a sudden step? Shouldn't there be some smoothing somewhere? - another PC working off the same Wi-Fi connection also shows steps in the frequency, but both negative and positive steps, and not at quite the same intervals. Comparing today's graphs, the steps are not occurring at the same time in the two PCs. One PC is showing negative spikes in the offset, the other both positive and negative. Question: why would Wi-Fi give rise to these offset spikes, and why is NTP so sensitive to them? I suppose the answer to how the spikes arise could be simply that's how Wi-Fi is, with transmission uncertainties and the possibility of interference. I had expected a greater variation to the offset with Wi-Fi, but not the spikes. Perhaps NTP is sensitive because I have minpoll 5 and maxpoll 5, perhaps widening the loop bandwidth? Cheers, David ___ 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] Windows and Wi-Fi - starts well, frequency steps?
On 2011-12-25, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@invalid.ca wrote in message news:KHoJq.2272$zj4.1...@newsfe03.iad... [] Question: would you expect the reported jitter to increase over the first 30 minutes or so? Could be somone switched on a vacuum cleaner for example. No. I've seen something like this behaviour before, with the initial few tens of minutes producing a more stable results than a full run. That is now ntp works. All it knows is the current offset, and tries to get rid of it by changing the frequency. It does not know that there is a sudden step. I does not remember the old offset values. This behaviour seems wrong to me. Unless it's known that the frequency can suddenly change, NTP should not be altering it in crash-bang steps, or it should take a more long-term view before doing so. ntpd does NOT take a long term veiw. The decision made in designing it wasw that it would be a short term Markovian feedback loop. It does not have any memory If the offset is positive speed up the clock, if negative, slow it down. If you want a program with a different design philosophy, get chrony. It remembers up to 64 of the last measurements and uses them to determine what the best estmate is of the actual offset and rate error in the local clock is. (It uses linear regression, corrects past measurements for current offset and rate changes, and tests to make sure that a linear fit is a good estimate, decreasing the number of remembered items if it is not.) You might look at the peerstats file and also look at the roundtrip time. I might be that occasionally one of the paths from wireless to computer gets shorter ( clearer signal?) and ntpd will then take that as a good value, and an earlier value, and try to correct for that offset-- which it does by stepping the frequency. I can imagine an occasional longer delay, but not a shorter one. I haven't been collecting peerstats data. Signal strength is high and unlikely to drop, although I accept that's not impossible. Sure it can. HIgh noise levels with occasional bursts of low noise. The ntpd algorithm saves the last 8 offsets and roundtrip times, and uses only the one with the smallest roundtrip, on the theory that is the best with smallest assymetry in out and in trips. This is not a good estimate if there is generally noise but occasionally a clear spell which affects one of the paths but not the other. Cheers, David ___ 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 2011-12-26, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@invalid.ca wrote in message news:OLMJq.5774$sg3.2...@newsfe11.iad... [] ntpd does NOT take a long term veiw. The decision made in designing it wasw that it would be a short term Markovian feedback loop. It does not have any memory If the offset is positive speed up the clock, if negative, slow it down. If you want a program with a different design philosophy, get chrony. It remembers up to 64 of the last measurements and uses them to determine what the best estmate is of the actual offset and rate error in the local clock is. (It uses linear regression, corrects past measurements for current offset and rate changes, and tests to make sure that a linear fit is a good estimate, decreasing the number of remembered items if it is not.) I would be interested to try a Windows port of chrony, if it can be managed at least to the extent of obtaining the offset with an SNMP call, or a simple program. My present monitoring uses a Perl script to parse the output of an ntpq -c rv request. Unfortunately no windows port exists. Linux, BSD only for now. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
unruh un...@invalid.ca wrote in message news:OLMJq.5774$sg3.2...@newsfe11.iad... [] ntpd does NOT take a long term veiw. The decision made in designing it wasw that it would be a short term Markovian feedback loop. It does not have any memory If the offset is positive speed up the clock, if negative, slow it down. If you want a program with a different design philosophy, get chrony. It remembers up to 64 of the last measurements and uses them to determine what the best estmate is of the actual offset and rate error in the local clock is. (It uses linear regression, corrects past measurements for current offset and rate changes, and tests to make sure that a linear fit is a good estimate, decreasing the number of remembered items if it is not.) I would be interested to try a Windows port of chrony, if it can be managed at least to the extent of obtaining the offset with an SNMP call, or a simple program. My present monitoring uses a Perl script to parse the output of an ntpq -c rv request. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
