Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
In article LWIMq.52547$ee3.24...@newsfe04.iad, unruh un...@invalid.ca wrote: On 2012-01-03, Rod Dorman r...@panix.com wrote: In article jdqcs5$ppn$1...@dont-email.me, David Woolley david@ex.djwhome.demon.invalid wrote: Rod Dorman wrote: But thats my point, it says nothing about transport layer protocols. I'm just trying to understand Dave Hart's statement As it says nothing about them, it means that all transport protocols get the same resilience, other things being equal (UDP opens the possibility of multicast). which appears to claim the UDP over WiFi is guaranteed which I've never seen stated before. In a network with a WiFi element, the WiFi element is the most likely one to lose packets and force retransmissions, and therefore cause NTP packets to arrive with large delays. To a large extent it does guarantee delivery compared with what would happen if it didn't retransmit. I take guaranteed delivery when mentioning a transport protocol to mean end-to-end, not just that one hop of it will retransmit. The network IS hop to hop. Only if the WAP is the NTP server. If its some other host in your LAN or if its out in the WAN then theres going to be more that one hop and any router along the route could decide to drop the UDP packet. And we are getting really far away from the original question. The answer seems to be that wireless can typically have large, assymetric delays, which plays havoc with ntp. Esp if some link which typically has a delay, suddenly has a shorter delay (due to typical retransmission, and suddenly none on some packet). (the ntp filter algorithm tends to throw away packets with longer delays, but grabs and uses packets with shorter delays. Thus if there is an occasional longer delay, that does not matter, but if there is only an occasional shorter asymmetric delay, ntp will use that.) I've got no issues with that, my only objection was the implied claim that if WiFi was involved the UDP transport protocol was suddenly redefined to be guaranteed. -- -- Rod -- rodd(at)polylogics(dot)com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
In article jdqcs5$ppn$1...@dont-email.me, David Woolley david@ex.djwhome.demon.invalid wrote: Rod Dorman wrote: But thats my point, it says nothing about transport layer protocols. I'm just trying to understand Dave Hart's statement As it says nothing about them, it means that all transport protocols get the same resilience, other things being equal (UDP opens the possibility of multicast). which appears to claim the UDP over WiFi is guaranteed which I've never seen stated before. In a network with a WiFi element, the WiFi element is the most likely one to lose packets and force retransmissions, and therefore cause NTP packets to arrive with large delays. To a large extent it does guarantee delivery compared with what would happen if it didn't retransmit. I take guaranteed delivery when mentioning a transport protocol to mean end-to-end, not just that one hop of it will retransmit. -- -- Rod -- rodd(at)polylogics(dot)com ___ 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 2012-01-03, Rod Dorman r...@panix.com wrote: In article jdqcs5$ppn$1...@dont-email.me, David Woolley david@ex.djwhome.demon.invalid wrote: Rod Dorman wrote: But thats my point, it says nothing about transport layer protocols. I'm just trying to understand Dave Hart's statement As it says nothing about them, it means that all transport protocols get the same resilience, other things being equal (UDP opens the possibility of multicast). which appears to claim the UDP over WiFi is guaranteed which I've never seen stated before. In a network with a WiFi element, the WiFi element is the most likely one to lose packets and force retransmissions, and therefore cause NTP packets to arrive with large delays. To a large extent it does guarantee delivery compared with what would happen if it didn't retransmit. I take guaranteed delivery when mentioning a transport protocol to mean end-to-end, not just that one hop of it will retransmit. The network IS hop to hop. And we are getting really far away from the original question. The answer seems to be that wireless can typically have large, assymetric delays, which plays havoc with ntp. Esp if some link which typically has a delay, suddenly has a shorter delay (due to typical retransmission, and suddenly none on some packet). (the ntp filter algorithm tends to throw away packets with longer delays, but grabs and uses packets with shorter delays. Thus if there is an occasional longer delay, that does not matter, but if there is only an occasional shorter asymmetric delay, ntp will use that.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
In article jdmht9$jc2$1...@synge.maths.tcd.ie, David Malone dwmal...@walton.maths.tcd.ie wrote: r...@panix.com (Rod Dorman) writes: I dont see anything to support the claim that UDP is treated as guaranteed by WiFi It says unicast frames are retransmitted - that's as close as you'll get. But thats my point, it says nothing about transport layer protocols. I'm just trying to understand Dave Hart's statement In article CAMbSiYDKdnWenOK=sqwo_zrs9u0d02a8m5qeaj+rvcxcjfr...@mail.gmail.com, Dave Hart davehart_gmail_exchange_...@davehart.net wrote: ... 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. which appears to claim the UDP over WiFi is guaranteed which I've never seen stated before. -- -- Rod -- rodd(at)polylogics(dot)com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
Rod Dorman wrote: But thats my point, it says nothing about transport layer protocols. I'm just trying to understand Dave Hart's statement As it says nothing about them, it means that all transport protocols get the same resilience, other things being equal (UDP opens the possibility of multicast). which appears to claim the UDP over WiFi is guaranteed which I've never seen stated before. In a network with a WiFi element, the WiFi element is the most likely one to lose packets and force retransmissions, and therefore cause NTP packets to arrive with large delays. To a large extent it does guarantee delivery compared with what would happen if it didn't retransmit. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
r...@panix.com (Rod Dorman) writes: I dont see anything to support the claim that UDP is treated as guaranteed by WiFi It says unicast frames are retransmitted - that's as close as you'll get. 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?
In article jdirbv$20dh$1...@synge.maths.tcd.ie, David Malone dwmal...@walton.maths.tcd.ie wrote: r...@panix.com (Rod Dorman) writes: Isn't 802.11 a physical layer specification? Why would it be defining transport layer behaviour? No - it's a MAC and PHY layer. It doesn't care about TCP or UDP, only MAC layer things like unicast and multicast, and the required management/control glue to make it all work. Have a look at section 6.1.1.3, which notes that most unicast traffic is ACKed, but broadcast and multicast is not. Section 9 describes a good bit of the MAC, and 9.2.8 the ACKing procedure. But that is discussing MAC level acks and retransmits. I dont see anything to support the claim that UDP is treated as guaranteed by WiFi -- -- Rod -- rodd(at)polylogics(dot)com ___ 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 Fri, Dec 30, 2011 at 20:01, Rod Dorman r...@panix.com wrote: I dont see anything to support the claim that UDP is treated as guaranteed by WiFi It's treated the same as all unicast, as has been said repeatedly. Which means it is ACKed at the MAC layer and if the ACK is missing, the frame is retransmitted repeatedly until ACKed. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
In article CAMbSiYBj7LTCceUvsqVGc9U9WthW5h5_j6=l4a4b6dcxk5s...@mail.gmail.com, Dave Hart davehart_gmail_exchange_...@davehart.net wrote: On Fri, Dec 30, 2011 at 20:01, Rod Dorman r...@panix.com wrote: I dont see anything to support the claim that UDP is treated as guaranteed by WiFi It's treated the same as all unicast, as has been said repeatedly. Which means it is ACKed at the MAC layer and if the ACK is missing, the frame is retransmitted repeatedly until ACKed. But that only guarantees the access point will recieve it and the same can be said for TCP and any other transport layer protocol. It says nothing about UDP packets reaching the destination IP address. -- -- Rod -- rodd(at)polylogics(dot)com ___ 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 daveh...@gmail.com wrote: On Wed, Dec 28, 2011 at 21:54, David Malone dwmal...@walton.maths.tcd.ie wrote: Modern hardware that supports 802.11e (or 802.11n, which requires much of the QoS part of 11e) can control things like the number of retries, and you could hack the driver to inspect the packets and if it is NTP to reduce the number of retires. I recognize I'm suggesting a layer violation in wishing 802.11 devices treated UDP differently from TCP, or even worse in terms of layer violation, UDP 123 differently from UDP 53. It's not pretty, but it would make a positive difference. The ideal number of retries for NTP may be zero, assuming the radio layer loss rates are less than 87.5% in practice. When NTP wants special treatments of its packets, it should set the TOS/DiffServ field, e.g. to LOWDELAY or EF. Of course when that IP traffic is sent over untagged (not 802.1q) ethernet that information is lost anyway. But a directly connected 802.11 device could possibly look at it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
In article CAMbSiYDM=aokmtrqnh-vfxa7-ty0uppd+cgtxa-rh0te5vm...@mail.gmail.com, Dave Hart davehart_gmail_exchange_...@davehart.net wrote: On Wed, Dec 28, 2011 at 18:58, Rod Dorman r...@panix.com wrote: Is this defined in an RFC or some other standards document? http://standards.ieee.org/about/get/802/802.11.html I did a quick scan of 802.11-2007.pdf and didn't see any requirement that UDP is treated as guaranteed by WiFi. Could you give a page number or section reference? -- -- Rod -- rodd(at)polylogics(dot)com ___ 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 Thu, Dec 29, 2011 at 19:35, Rod Dorman r...@panix.com wrote: I did a quick scan of 802.11-2007.pdf and didn't see any requirement that UDP is treated as guaranteed by WiFi. Could you give a page number or section reference? My belief is 802.11 treats all unicast datagrams equally, and all multicast/broadcast datagrams equally, in terms of the ack/retransmit behavior. I'm not making any statement about standards compliance -- I am unfamiliar with 802.11 specs. My peanut gallery idea is perhaps UDP in general or NTP specifically would benefit from 802.11 not attempting retransmission. Cheers, Dave Hart ___ 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 daveh...@gmail.com writes: I recognize I'm suggesting a layer violation in wishing 802.11 devices treated UDP differently from TCP, or even worse in terms of layer violation, UDP 123 differently from UDP 53. It's not pretty, but it would make a positive difference. The ideal number of retries for NTP may be zero, assuming the radio layer loss rates are less than 87.5% in practice. All QoS choices that are made at a low layer involve some amount of layering violation, so I don't actually find this objectionable. If the PHY rate selection algorithm is any good, then the loss rate will be less that 87% unless the network is really clogged up with a lot of busy stations and there are a lot of collisions. An alternative would be to use NTP's broadcast mode on a LAN, which would eliminate retries. Right. There is one other cool thing you can do with timing and 802.11 broadcasts. Broadcasts really are broadcasts - you're not seeing copies of a packet as you would on a switch. If you can timestamp the arrival of a broadcast, it should provide you with a common reference point in time between a bunch of devices. It can be a fun way to watch the drift on the clocks on a bunch of devices. (The 802.11 cards often have relatively good time counters on them too, for backoff and TSF calculations. I've a version of the Atheros driver for FreeBSD that can work as the system timecounter. I've still to check how it compares to other hardware.) 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?
r...@panix.com (Rod Dorman) writes: I did a quick scan of 802.11-2007.pdf and didn't see any requirement that UDP is treated as guaranteed by WiFi. Could you give a page number or section reference? Look for the handling of unicast traffic. 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?
In article jdiha8$1sc6$2...@synge.maths.tcd.ie, David Malone dwmal...@walton.maths.tcd.ie wrote: r...@panix.com (Rod Dorman) writes: I did a quick scan of 802.11-2007.pdf and didn't see any requirement that UDP is treated as guaranteed by WiFi. Could you give a page number or section reference? Look for the handling of unicast traffic. I'm still not finding it. Isn't 802.11 a physical layer specification? Why would it be defining transport layer behaviour? -- -- Rod -- rodd(at)polylogics(dot)com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
r...@panix.com (Rod Dorman) writes: Isn't 802.11 a physical layer specification? Why would it be defining transport layer behaviour? No - it's a MAC and PHY layer. It doesn't care about TCP or UDP, only MAC layer things like unicast and multicast, and the required management/control glue to make it all work. Have a look at section 6.1.1.3, which notes that most unicast traffic is ACKed, but broadcast and multicast is not. Section 9 describes a good bit of the MAC, and 9.2.8 the ACKing procedure. 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?
In article CAMbSiYDKdnWenOK=sqwo_zrs9u0d02a8m5qeaj+rvcxcjfr...@mail.gmail.com, Dave Hart davehart_gmail_exchange_...@davehart.net wrote: On Wed, Dec 28, 2011 at 00:51, Danny Mayer ma...@ntp.org 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. Is this defined in an RFC or some other standards document? -- -- Rod -- rodd(at)polylogics(dot)com ___ 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 18:58, Rod Dorman r...@panix.com wrote: Is this defined in an RFC or some other standards document? http://standards.ieee.org/about/get/802/802.11.html Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
Danny Mayer ma...@ntp.org writes:
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.
\begin{ramble}
All unicast MAC layer traffic is retransmitted on WiFi if not
recieved correctly, probably for the same reason that Ethernet also
retransmits packets that collide. If NTP can handle 10base2 Ethernet,
then it should be able to handle WiFi.
The maximum number of retries depends somewhat on the hardware
(usually between 7 and 11 tries), and is subject to backoff, in a
similar way to traditional Ethernet. Determining if a packet was
successful depends on on a MAC-layer ACK, because you can't easily
do collision detection in the same way as Ethernet. The reason that
only unicast packets are retransmitted is because it's tricky to
figure out who sends the ACK if it is multicast or broadcast. I
suspect that if the 802.11 guys could figure it out, multi-/broadcast
traffic would also be retransmitted as needed.
Modern hardware that supports 802.11e (or 802.11n, which requires
much of the QoS part of 11e) can control things like the number of
retries, and you could hack the driver to inspect the packets and
if it is NTP to reduce the number of retires. An alternative would
be to use NTP's broadcast mode on a LAN, which would eliminate
retries. However, I suspect that bufferbloat and asymetric delays
on DSL is probably a much bigger problem for NTP than 802.11 retries.
\end{ramble}
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 Wed, Dec 28, 2011 at 21:54, David Malone dwmal...@walton.maths.tcd.ie wrote: Modern hardware that supports 802.11e (or 802.11n, which requires much of the QoS part of 11e) can control things like the number of retries, and you could hack the driver to inspect the packets and if it is NTP to reduce the number of retires. I recognize I'm suggesting a layer violation in wishing 802.11 devices treated UDP differently from TCP, or even worse in terms of layer violation, UDP 123 differently from UDP 53. It's not pretty, but it would make a positive difference. The ideal number of retries for NTP may be zero, assuming the radio layer loss rates are less than 87.5% in practice. An alternative would be to use NTP's broadcast mode on a LAN, which would eliminate retries. Right. However, I suspect that bufferbloat and asymetric delays on DSL is probably a much bigger problem for NTP than 802.11 retries. Absolutely. Nearly every consumer broadband connection has bufferbloat issues. Local loop asymmetry is extreme with ADSL. And most NTP clients in the wild are using NTP servers reached over an asymmetric WAN connection. Reverse and forward delay will frequently be slightly different, introducing apparent offset error. Cheers, Dave Hart ___ 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 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. 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] Windows and Wi-Fi - starts well, frequency steps?
On Wed, Dec 28, 2011 at 00:51, Danny Mayer ma...@ntp.org 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] Windows and Wi-Fi - starts well, frequency steps?
-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: Sunday, December 25, 2011 4:46 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps? On 2011-12-25, Charles Elliott mailto:elliott...@verizon.net elliott...@verizon.net wrote: 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 That says that the noise is occuring in one of the paths, rather than the other. 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. ntp assumes that the outgoing and incoming trips are the same time. If not, you get an offset. Thus if the return trip takes 10 min and the outgoing 1ms, ntp is going to say that the remote clock is five minutes further behind than it is. On a wireless I could easily imagine that the trip times are not the same, and that one way of the other is preferentially got a higher jitter than the other. That's true. But that the offset becomes more negative as the delay increases implies that the response trip always takes longer than the request trip. Isn't that somewhat unlikely? Why would not the request and response times be equal on average? That is, on average why don't the path asymmetries cancel each other out? ___ 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, Charles Elliott elliott...@verizon.net wrote: -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: Sunday, December 25, 2011 4:46 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps? On 2011-12-25, Charles Elliott mailto:elliott...@verizon.net elliott...@verizon.net wrote: ntp assumes that the outgoing and incoming trips are the same time. If not, you get an offset. Thus if the return trip takes 10 min and the outgoing 1ms, ntp is going to say that the remote clock is five minutes further behind than it is. On a wireless I could easily imagine that the trip times are not the same, and that one way of the other is preferentially got a higher jitter than the other. That's true. But that the offset becomes more negative as the delay increases implies that the response trip always takes longer than the request trip. Isn't that somewhat unlikely? Why would not the request and response times be equal on average? That is, on average why don't the path asymmetries cancel each other out? Why is it unlikely? And even if it is, why could it not be happening to you? the two paths ARE assymetric--in one case it is the modem that is receiving the wireless signal, in the other your machine. If your modem's wireelss is weak or noisier than your machine's it could case an assymetry. But this is irrelevant. Your measurements indictate that this is what is happening. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
The results of removing the min/max poll are here: http://www.satsignal.eu/ntp/2011-12-16-Ystad.html Update: http://www.satsignal.eu/ntp/2011-12-27-Ystad.html 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?
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
[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] 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] 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] 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
