[ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
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. Question: would you expect the reported jitter to increase over the first 30 minutes or so? - 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. 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
Re: [ntp:questions] Accuracy of NTP - Advice Needed
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. -- 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 2011-12-24, David J Taylor david-tay...@blueyonder.co.uk wrote:
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?
Please remove the {min|max}poll and see if that makes a difference.
--
Steve Kostecke koste...@ntp.org
NTP Public Services Project - http://support.ntp.org/
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
On 2011-12-24, David J Taylor wrote:
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?
Please remove the {min|max}poll and see if that makes a difference.
--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/
Excellent suggestion, Steve, thanks. I've been using those tight limits
for some time, as a means of keeping the offset down to the levels I like
to have. With the changes in 4.2.7p241 it will be interesting, if nothing
else, to see what the difference is. Test now in progress, and I'll
revisit it tomorrow and report back unless it's a complete disaster!
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-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
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 2011-12-24, John Hasler jhas...@newsguy.com 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. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
unruh writes: 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. The NOvA detector is not in a mine so it should be possible to site the GPS receiver directly above it and drop a cable straight down. The same should be possible at the Fermi end. You could set up both timing chains at Fermilab (using indentical components including cable lengths if you want to be fanatical), calibrate them against each other for delay from antenna to output, and then pack one up and ship it up north (of course there may be good reasons not to do it this way). The surveying should be easier than in Europe: there's no mountain range in the way. -- 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] Accuracy of NTP - Advice Needed
John Hasler jhas...@newsguy.com wrote: unruh writes: 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. The NOvA detector is not in a mine so it should be possible to site the GPS receiver directly above it and drop a cable straight down. The same should be possible at the Fermi end. You could set up both timing chains at Fermilab (using indentical components including cable lengths if you want to be fanatical), calibrate them against each other for delay from antenna to output, and then pack one up and ship it up north (of course there may be good reasons not to do it this way). The surveying should be easier than in Europe: there's no mountain range in the way. That's the common misconception of the geology. Basically the lab is in a tunnel in the side of a mountain and is no more a km underground than is the lobby of a 20 story hotel 20 stories underground. -- 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
On 2011-12-24, j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com wrote: unruh writes: 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. The NOvA detector is not in a mine so it should be possible to site the GPS receiver directly above it and drop a cable straight down. The same should be possible at the Fermi end. You could set up both timing chains at Fermilab (using indentical components including cable lengths if you want to be fanatical), calibrate them against each other for delay from antenna to output, and then pack one up and ship it up north (of course there may be good reasons not to do it this way). The surveying should be easier than in Europe: there's no mountain range in the way. That's the common misconception of the geology. Basically the lab is in a tunnel in the side of a mountain and is no more a km underground than is the lobby of a 20 story hotel 20 stories underground. But it is a few km inside the mountain. Is a mine in Denver not underground just because Denver is 1600 m above sea level? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 2011-12-24, John Hasler jhas...@newsguy.com wrote: unruh writes: 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. The NOvA detector is not in a mine so it should be possible to site the GPS receiver directly above it and drop a cable straight down. The same should be possible at the Fermi end. You could set up both timing chains at Fermilab (using indentical components including cable lengths if you want to be fanatical), calibrate them against each other for delay from antenna to output, and then pack one up and ship it up north (of course there may be good reasons not to do it this way). The surveying should be easier than in Europe: there's no mountain range in the way. Surveying is done by GPS, as is timing so mountain ranges do not really matter. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
unruh un...@invalid.ca wrote: On 2011-12-24, j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com wrote: unruh writes: 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. The NOvA detector is not in a mine so it should be possible to site the GPS receiver directly above it and drop a cable straight down. The same should be possible at the Fermi end. You could set up both timing chains at Fermilab (using indentical components including cable lengths if you want to be fanatical), calibrate them against each other for delay from antenna to output, and then pack one up and ship it up north (of course there may be good reasons not to do it this way). The surveying should be easier than in Europe: there's no mountain range in the way. That's the common misconception of the geology. Basically the lab is in a tunnel in the side of a mountain and is no more a km underground than is the lobby of a 20 story hotel 20 stories underground. But it is a few km inside the mountain. Is a mine in Denver not underground just because Denver is 1600 m above sea level? The issue is that most people don't seem to be able to understand how to get an accurate position of a location that is vertically under a km or so of dirt, yet horizontally feet from wide open sky and GPS signals. -- 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
unruh writes: Surveying is done by GPS, as is timing so mountain ranges do not really matter. The OPERA team had to survey a traverse through the Gran Sasso highway tunnel to get to suitable benchmarks. You're right though: they did not survey the entire distance. -- 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] Accuracy of NTP - Advice Needed
Jim Pennino writes: The issue is that most people don't seem to be able to understand how to get an accurate position of a location that is vertically under a km or so of dirt, yet horizontally feet from wide open sky and GPS signals. The open sky nearest the OPERA detector is straight up through 1400m of rock. -- 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] Accuracy of NTP - Advice Needed
John Hasler jhas...@newsguy.com wrote: Jim Pennino writes: The issue is that most people don't seem to be able to understand how to get an accurate position of a location that is vertically under a km or so of dirt, yet horizontally feet from wide open sky and GPS signals. The open sky nearest the OPERA detector is straight up through 1400m of rock. And the easiest open sky to get to is horizontally down the tunnel to the entrance which is next to a freeway. -- 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
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. -- 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 Sat, Dec 24, 2011 at 18:18, unruh un...@invalid.ca wrote: On 2011-12-24, David J Taylor david-tay...@blueyonder.co.uk.invalid 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. NTP is like VoIP in this regard, dropping the traffic is likely better than unbounded delay for retransmission. I wonder if the 90 minute periodicity to the -0.4 PPM shifts aligns with some WiFi security renegotiation. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
John Hasler jhas...@newsguy.com 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. -- 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
unruh un...@invalid.ca wrote: On 2011-12-24, j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: unruh un...@invalid.ca wrote: On 2011-12-24, j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com wrote: unruh writes: 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. The NOvA detector is not in a mine so it should be possible to site the GPS receiver directly above it and drop a cable straight down. The same should be possible at the Fermi end. You could set up both timing chains at Fermilab (using indentical components including cable lengths if you want to be fanatical), calibrate them against each other for delay from antenna to output, and then pack one up and ship it up north (of course there may be good reasons not to do it this way). The surveying should be easier than in Europe: there's no mountain range in the way. That's the common misconception of the geology. Basically the lab is in a tunnel in the side of a mountain and is no more a km underground than is the lobby of a 20 story hotel 20 stories underground. But it is a few km inside the mountain. Is a mine in Denver not underground just because Denver is 1600 m above sea level? The issue is that most people don't seem to be able to understand how to get an accurate position of a location that is vertically under a km or so of dirt, yet horizontally feet from wide open sky and GPS signals. A few feet? I assume that was a misprint for a few km. Where do you see the words few feet in what I wrote? The bottom line is that the only thing that is relevant is the path to the GPS antenna with a clear view of the sky. Everything else is bloviation. -- 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
On 2011-12-25, j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com 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. Yes. 5km away horizontally or 1.5km away vertically. Everything else is bloviation. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
unruh un...@invalid.ca wrote: On 2011-12-25, j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com 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. Yes. 5km away horizontally or 1.5km away vertically. Distance is not automatically a metric of ease. But bloviate away. -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] [ntp:announce] NTP 4.2.6p5 Released
Redwood City, CA - 2011/12/24 - The NTP Public Services Project (http://support.ntp.org/) is pleased to announce that NTP 4.2.6p5, a Point Release of the NTP Reference Implementation from the NTP Project, is now available at http://www.ntp.org/downloads.html and http://support.ntp.org/download. File-size: 4202539 bytes MD5 sum: 00df80a84ec9528fcfb09498075525bc ntp-4.2.6p5.tar.gz Focus: Bug fixes Severity: Medium This is a recommended upgrade. This release updates sys_rootdisp and sys_jitter calculations to match the RFC specification, fixes a potential IPv6 address matching error for the nic and interface configuration directives, supresses the creation of extraneous ephemeral associations for certain broadcastclient and multicastclient configurations, cleans up some ntpq display issues, and includes improvements to orphan mode, minor bug fixes and code clean-ups. New features / changes in this release: ntpd * Updated nic and interface IPv6 address handling to prevent mismatches with localhost [::1] and wildcard [::] which resulted from using the address/prefix format (e.g. fe80::/64) * Fix orphan mode stratum incorrectly counting to infinity * Orphan parent selection metric updated to includes missing ntohl() * Nonprintable stratum 16 refid no longer sent to ntp * Duplicate ephemeral associations suppressed for brodcastclient and multicastclient without broadcastdelay * Exclude undetermined sys_refid from use in loopback TEST12 * Exclude MODE_SERVER responses from KoD rate limiting * Include root delay in clock_update() sys_rootdisp calculations * get_systime() updated to exclude sys_residual offset (which only affected bits below sys_tick, the precision threshold) * sys.peer jitter weighting corrected in sys_jitter calculation ntpq * -n option extended to include the billboard server column * IPv6 addresses in the local column truncated to prevent overruns Please report any bugs, issues, or desired enhancements at http://bugs.ntp.org/. The NTP (Network Time Protocol) Public Services Project, which is hosted by Internet Systems Consortium, Inc. (http://www.isc.org/), provides support and additional development resources for the Reference Implementation of NTP produced by the NTP Project (http://www.ntp.org/). ___ announce mailing list annou...@lists.ntp.org http://lists.ntp.org/listinfo/announce ___ 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: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. 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. 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?
Dave Hart wrote in message news:CAMbSiYD0cY27Ft9cadBzV4ravKcz- [] 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. NTP is like VoIP in this regard, dropping the traffic is likely better than unbounded delay for retransmission. I wonder if the 90 minute periodicity to the -0.4 PPM shifts aligns with some WiFi security renegotiation. Cheers, Dave Hart Thanks for that, Dave. Initial results with no min/maxpoll=5 are showing an offset value which initially oscillated a lot, but is now steadier at 10-14 ms, the frequency has steadied after an initial period at a rising 0.85 to 0.95 ppm (whereas the LAN-sync value was ~1.7 ppm), and the jitter is now slowly dropping (currently 7 ms) from a peak of about 27 ms. It seems that with min/maxpoll=5, 32 seconds, it was much more likely that NTP would be triggered into poor behaviour (stepping the frequency) than with the poll at 1024 seconds which it has now reached. Of course, setting such short poll times over a noisy link is not a good idea, although why NTP seems to settle with a higher offset and different frequency isn't currently clear to me! Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
