Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 23/12/2012 00:11, Hal Murray wrote: In article kb4hoe$9cm$1...@dont-email.me, David Taylor david-tay...@blueyonder.co.uk.invalid writes: I wonder how I could get the delay figures for my own modem? The only data I can extract is: Latency: ~20 milliseconds, RTP jitter - up: 4 milliseconds, down: ~0.12 milliseconds. You can measure the delays. After the typical client-server exchange you have 4 time stamps. If you assume the network latency is symmetric you can compute the clock offset. If you assume both clocks are accurate you can compute the network delays. If you collect a bunch of data, it's reasonable to assume that the lowest delays are when the queues are empty. Any longer delays are due to queuing. Fascinating to see you have less delay on the slower upstream! The queuing delays depend upon the traffic. You control that. Thanks for that suggestion Hal. I've written a program to do just that, and I am seeing down delays of a moderately consistent 4 ms, and up delays of between 20 and 30 ms. The program was interesting in that measuring times to better than 15 ms resolution on Windows requires interpolation, and I had already developed that from for code I found on the Internet. I think this was it's first use in anger. http://www.satsignal.eu/ntp/TSCtime.html -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 12/23/2012 01:11 AM, Hal Murray wrote: Fascinating to see you have less delay on the slower upstream! The queuing delays depend upon the traffic. You control that. The delays I quoted are fixed delays linked to the modulation, encoding and other parameters used on my VDSL2 line (the physical layer, if you like). Another contributor suggested that the greater downstream delay than the upstream delay may be due to interleaving, and this sounds like a good hypothesis. Queuing delays come on top. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 12/11/2012 12:49 PM, David Taylor wrote: Sorry: catching up. What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. The actual bitrate is not so important. True: it determines the time a packet spends on the wire. But more important is (or can be) the amount of time a packet spends in various queues before actually being sent. This time varies with instantaneous network load, and with the size of the queue. Google for bufferbloat, and apologies if everyone here already knows all of this. Having said that: there can indeed be asymmetrical transmission delays that are linked to the technology being used. My VDSL2 modem tells me that the downstream delay is 14.1ms and the upstream delay is 4.4ms. The ratio of these numbers is not equal to the ratio of the downstream and upstream bitrates (which are 16544 kbit/s and 2056 kbit/s respectively). So note also that the downstream delay is greater than the upstream delay, although the downstream bitrate is higher. HTH, Jan ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 22/12/2012 14:36, Jan Ceuleers wrote: On 12/11/2012 12:49 PM, David Taylor wrote: Sorry: catching up. What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. The actual bitrate is not so important. True: it determines the time a packet spends on the wire. But more important is (or can be) the amount of time a packet spends in various queues before actually being sent. This time varies with instantaneous network load, and with the size of the queue. Google for bufferbloat, and apologies if everyone here already knows all of this. Having said that: there can indeed be asymmetrical transmission delays that are linked to the technology being used. My VDSL2 modem tells me that the downstream delay is 14.1ms and the upstream delay is 4.4ms. The ratio of these numbers is not equal to the ratio of the downstream and upstream bitrates (which are 16544 kbit/s and 2056 kbit/s respectively). So note also that the downstream delay is greater than the upstream delay, although the downstream bitrate is higher. HTH, Jan Jan, yes, I appreciate that it's not the rate as such, I was really trying to show how asymmetrical (10:1) the connection provided by my ISP was. If they are trying to pack in as many customers as possible, who knows what the actual backbone might be like? This is a cable modem connection, by the way, and not ADSL. I wonder how I could get the delay figures for my own modem? The only data I can extract is: Latency: ~20 milliseconds, RTP jitter - up: 4 milliseconds, down: ~0.12 milliseconds. Fascinating to see you have less delay on the slower upstream! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jan Ceuleers jan.ceule...@computer.org wrote: Having said that: there can indeed be asymmetrical transmission delays that are linked to the technology being used. My VDSL2 modem tells me that the downstream delay is 14.1ms and the upstream delay is 4.4ms. The ratio of these numbers is not equal to the ratio of the downstream and upstream bitrates (which are 16544 kbit/s and 2056 kbit/s respectively). So note also that the downstream delay is greater than the upstream delay, although the downstream bitrate is higher. This is caused by interleaving. Packets are not sent back to back sequentially, but they are split into smaller chunks that are interleaved serially. This means a single packet is spread out over time, meaning that a hit of interference takes out a smaller part of each packet. And that again means that the error correction coding that is added to each packet has more chance of recovering the packet. (it is better to hit 8 packets each with a small amount of interference than to hit a single packet with a big blow) This improves the performance for streaming, but it increases the delay because the receiving modem has to wait longer for the packet to be complete. As the downstream with its higher bitrate is more affected by interference, more interleaving is usually applied to it as well. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
David Taylor wrote: On 22/12/2012 14:36, Jan Ceuleers wrote: On 12/11/2012 12:49 PM, David Taylor wrote: Sorry: catching up. What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. The actual bitrate is not so important. True: it determines the time a packet spends on the wire. But more important is (or can be) the amount of time a packet spends in various queues before actually being sent. This time varies with instantaneous network load, and with the size of the queue. Google for bufferbloat, and apologies if everyone here already knows all of this. Having said that: there can indeed be asymmetrical transmission delays that are linked to the technology being used. My VDSL2 modem tells me that the downstream delay is 14.1ms and the upstream delay is 4.4ms. The ratio of these numbers is not equal to the ratio of the downstream and upstream bitrates (which are 16544 kbit/s and 2056 kbit/s respectively). So note also that the downstream delay is greater than the upstream delay, although the downstream bitrate is higher. HTH, Jan Jan, yes, I appreciate that it's not the rate as such, I was really trying to show how asymmetrical (10:1) the connection provided by my ISP was. If they are trying to pack in as many customers as possible, who knows what the actual backbone might be like? This is a cable modem connection, by the way, and not ADSL. I wonder how I could get the delay figures for my own modem? The only data I can extract is: Latency: ~20 milliseconds, RTP jitter - up: 4 milliseconds, down: ~0.12 milliseconds. Fascinating to see you have less delay on the slower upstream! My own usage is more like 15:1 down:up so my 13:1.2 Mbps down:up data rates seem to fit quite well. When on 2 Mbps I had problems with very high latency on uploads and implemented altq traffic shaping which increased my maximum upload speed from around 150 kbps to around 250 kbps. There is also higher priority for icmp, dns and ntp. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 22/12/2012 17:49, David Lord wrote: [] My own usage is more like 15:1 down:up so my 13:1.2 Mbps down:up data rates seem to fit quite well. When on 2 Mbps I had problems with very high latency on uploads and implemented altq traffic shaping which increased my maximum upload speed from around 150 kbps to around 250 kbps. There is also higher priority for icmp, dns and ntp. David I don't have the figures to hand, but for some protocols (FTP?) there are acknowledgement packets sent back every so often, and I think that 10:1 is somewhere near the limit. With a greater up:down ratio the limiting factor in downstream speed is actually the upstream bandwidth! Something like that, anyway. It matters less what your usage is. I just happened to find a page which tells me that in the last 9 days I have downloaded 15 GB and uploaded 6 GB. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jeroen Mostert wrote: negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, You wouldn't expect 1ms ticks. You might get 20 ticks back to back, and then a gap of 20ms, or even larger numbers. VMs generally only get a virtual 1 second per second as a long term average. There has been conflicting advice on running ntpd on VMs, but I suspect the current advice to run it is an easy way of getting coarse timing right. Fine timing should use the host timing and any special VM support for the OS. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
-Original Message- From: questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org [mailto:questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org] On Behalf Of Jeroen Mostert Sent: Wednesday, December 12, 2012 6:30 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Win7: ntpd adjusting time backwards On 2012-12-12 21:58, Jeroen Mostert wrote: Here's some loopstats from a brand new machine running Windows Server 2012: 56273 56211.040 -0.000185248 20.113 0.65610 0.002127 8 56273 57117.052 0.000487392 20.115 0.000245606 0.002073 8 56273 57381.058 0.000771702 20.115 0.000250771 0.001958 8 56273 58424.072 0.000542051 20.118 0.000248229 0.001977 8 56273 59490.107 0.000320045 20.119 0.000245105 0.001903 8 56273 61613.141 0.000101314 20.120 0.000241965 0.001801 8 56273 62411.152 -0.000139791 20.119 0.000241858 0.001691 8 56273 63476.176 -0.000219043 20.118 0.000227966 0.001611 8 56273 65585.223 -0.000361511 20.116 0.000219111 0.001795 8 56273 66112.226 -0.000879125 20.114 0.000274771 0.001787 8 56273 66382.233 -0.000775453 20.113 0.000259625 0.001694 8 56273 66645.246 -0.000818638 20.112 0.000243336 0.001610 8 56273 68744.282 -0.000901985 20.105 0.000229520 0.002861 8 56273 69007.289 -0.000850863 20.105 0.000215455 0.002693 8 56273 69542.304 -0.000541853 20.103 0.000229247 0.002548 8 56273 69801.304 -0.000579627 20.103 0.000214857 0.002391 8 56273 70070.309 -0.000507633 20.102 0.000202585 0.002244 8 56273 70335.311 -0.000527417 20.102 0.000189630 0.002107 8 56273 72431.353 -0.000577564 20.097 0.000178267 0.002512 8 56273 72968.365 -0.000503697 20.096 0.000168786 0.002377 8 This is syncing with Internet time through the NL NTP pool. I've set up four other machines to sync with this server, two virtual and two physical. The virtual machines are running NT 6.0, the physical machines 6.1 (client/server flavors not relevant here). The virtuals do not have the multimedia timer enabled, since I've read that this can negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, ntpd achieves sub- millisecond sync with the local server on all of them almost all of the time. I've registered three spikes on the virtual machines so far, of 2, 5 and 10 ms. VM #1: 56273 85876.796 0.18374 50.694 0.21662 0.002233 4 56273 86004.805 0.08291 50.695 0.20574 0.002119 4 56273 86052.822 0.33144 50.696 0.21156 0.002054 4 56273 86180.829 -0.07628 50.695 0.24483 0.001949 4 56273 86196.829 0.20398 50.696 0.24953 0.001827 4 56273 86260.831 0.05560 50.696 0.23924 0.001713 4 56273 86388.856 0.38796 50.701 0.25276 0.002317 4 VM #2: 56273 85960.089 0.15957 50.623 0.000131482 0.005627 4 56273 86039.794 0.27317 50.625 0.000123056 0.005314 4 56273 86167.801 0.89203 50.636 0.000117169 0.006288 4 56273 86183.801 0.000108884 50.637 0.000109822 0.005911 4 56273 86199.807 0.62115 50.638 0.000104051 0.005539 4 56273 86327.809 0.41898 50.644 0.97593 0.005488 4 56273 86343.811 0.38536 50.644 0.91298 0.005138 4 56273 86375.811 0.47414 50.646 0.85459 0.004833 4 I mean, seriously, wow. This is just begging for some high accuracy timestamp reading. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions [Mischanko, Edward T] I have always read that NTP should not be run Virtual Machines. NTP should only be running on the Real machine with a hardware system clock. If the hardware machine is in synch, then the VM on the hardware machine should also be in synch. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-13 09:08, David Woolley wrote: Jeroen Mostert wrote: negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, You wouldn't expect 1ms ticks. You might get 20 ticks back to back, and then a gap of 20ms, or even larger numbers. VMs generally only get a virtual 1 second per second as a long term average. If your virtualization is that poor, get a refund. :-) However, it's certainly true that you cannot count on high-frequency ticks in a VM. There's simply not enough horsepower on the guest to achieve that, unless you've got a one-to-one mapping between actual and virtual hardware (and then there's not much point to virtualizing). There has been conflicting advice on running ntpd on VMs, but I suspect the current advice to run it is an easy way of getting coarse timing right. Fine timing should use the host timing and any special VM support for the OS. I agree. In the case of Windows on VMWare, however, there doesn't seem to be any. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-13 09:53, Mischanko, Edward T wrote: I have always read that NTP should not be run Virtual Machines. NTP should only be running on the Real machine with a hardware system clock. If the hardware machine is in synch, then the VM on the hardware machine should also be in synch. That can only work if there's some sort of driver or integration patch that makes the guest OS retrieve its time directly from the host's hardware clock. Otherwise, the guest OS maintains its own notion of time based on whatever hardware is being virtualized. In the case of Windows on VMWare (which is what I'm using), Windows simply maintains time just like it does on actual hardware, which is by taking the initial time from the CMOS and then maintaining ticks with timer interrupts. VMWare will simply emulate the interrupts, but Windows keeps its own time. Thus the guest OS clock is subject to losing or gaining ticks depending on the hypervisor's scheduling, which has nothing to do with the host's clock. VMWare has a feature that integrates time synchronization with the guest OS, but this is not meant as an accurate timekeeper, just as a stopgap measure for keeping up the clock if the VM lags behind too far. It will look once every minute to see if the guest is too far behind, and if it is, it will simply step the clock to the correct time. This is far more crude than what ntpd does. It's still important to keep the host clock synchronized as well, to make sure the VM has accurate time if it's turned off or migrated to another host in the cluster, but (at least in the case of VMWare) you cannot count on the host clock to keep the guest clock accurate to the kind of accuracy that NTP can achieve. VMWare has a whitepaper covering it in more detail, see http://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jeroen Mostert wrote: BlackLists wrote: ntpq -c rv0 precision should give a clue how close you can expect to get on a given machine. I assume you mean 'ntpq -c rv 0 precision'. Your command gives me an error. Yes, however it should work with the '' on newer 4.2.7 flavors. I'm not sure that means much. On the physical machines I get precision=-10, which makes sense since the multimedia timer is on and the resolution of GSTAFT is 1 ms. On the virtuals, however, I get -19 (ntpd 4.2.6p5) and -20 (ntpd 4.2.7p310). That may reflect the numerical precision of the interpolated clock, but that doesn't mean actually reading it with that precision is useful. That Precision is supposed to represent the time it takes to read the system clock. So whatever that is, you shouldn't expect a application to be able to get time more often. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-13, E-Mail Sent to this address will be added to the BlackLists Null@BlackList.Anitech-Systems.invalid wrote: Jeroen Mostert wrote: BlackLists wrote: ntpq -c rv0 precision should give a clue how close you can expect to get on a given machine. I assume you mean 'ntpq -c rv 0 precision'. Your command gives me an error. Yes, however it should work with the '' on newer 4.2.7 flavors. I'm not sure that means much. On the physical machines I get precision=-10, which makes sense since the multimedia timer is on and the resolution of GSTAFT is 1 ms. On the virtuals, however, I get -19 (ntpd 4.2.6p5) and -20 (ntpd 4.2.7p310). That may reflect the numerical precision of the interpolated clock, but that doesn't mean actually reading it with that precision is useful. That Precision is supposed to represent the time it takes to read the system clock. It is also supposed to reflect the time between changes of the system clock. So whatever that is, you shouldn't expect a application to be able to get time more often. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-13, Jeroen Mostert jmost...@xs4all.nl wrote: On 2012-12-13 09:08, David Woolley wrote: Jeroen Mostert wrote: negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, You wouldn't expect 1ms ticks. You might get 20 ticks back to back, and then a gap of 20ms, or even larger numbers. VMs generally only get a virtual 1 second per second as a long term average. If your virtualization is that poor, get a refund. :-) However, it's certainly true that you cannot count on high-frequency ticks in a VM. There's simply not enough horsepower on the guest to achieve that, unless you've got a one-to-one mapping between actual and virtual hardware (and then there's not much point to virtualizing). There has been conflicting advice on running ntpd on VMs, but I suspect the current advice to run it is an easy way of getting coarse timing right. Fine timing should use the host timing and any special VM support for the OS. I agree. In the case of Windows on VMWare, however, there doesn't seem to be any. Perhaps you should follow the advice you gave in the first sentence of you response. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-14 00:25, Jeroen Mostert wrote: I'm an engineer. I don't pay bills, I just foot new ones Ugh. Of course I'm not footing the new ones either. Current system uptime is 19.5 hours; wizard needs sleep, badly. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-14 00:06, unruh wrote: On 2012-12-13, Jeroen Mostertjmost...@xs4all.nl wrote: On 2012-12-13 09:08, David Woolley wrote: Jeroen Mostert wrote: negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, You wouldn't expect 1ms ticks. You might get 20 ticks back to back, and then a gap of 20ms, or even larger numbers. VMs generally only get a virtual 1 second per second as a long term average. If your virtualization is that poor, get a refund. :-) However, it's certainly true that you cannot count on high-frequency ticks in a VM. There's simply not enough horsepower on the guest to achieve that, unless you've got a one-to-one mapping between actual and virtual hardware (and then there's not much point to virtualizing). There has been conflicting advice on running ntpd on VMs, but I suspect the current advice to run it is an easy way of getting coarse timing right. Fine timing should use the host timing and any special VM support for the OS. I agree. In the case of Windows on VMWare, however, there doesn't seem to be any. Perhaps you should follow the advice you gave in the first sentence of you response. I'm an engineer. I don't pay bills, I just foot new ones working around the limitations caused by the people paying the bills. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
E-Mail Sent to this address will be added to the BlackLists wrote: That Precision is supposed to represent the time it takes to read the system clock. It is the smallest non-zero difference between two readings of the clock. If the clock is very high resolution, it may be close to the time to read the clock. If the clock is low resolution, it is determined by the resolution of the clock. So whatever that is, you shouldn't expect a application to be able to get time more often. If the clock can only be read to 10ms (no interpolation) you can expect multiple reads. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
David Woolley wrote: BlackLists wrote: That Precision is supposed to represent the time it takes to read the system clock. It is the smallest non-zero difference between two readings of the clock. If the clock is very high resolution, it may be close to the time to read the clock. If the clock is low resolution, it is determined by the resolution of the clock. So whatever that is, you shouldn't expect a application to be able to get time more often. If the clock can only be read to 10ms (no interpolation) you can expect multiple reads. ... without the timestamp changing though. I guess I could have worded it better. Whatever ntpq -c rv 0 precision returns; an application is unlikely to be able to get changing timestamps at any higher rate. Better? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 11/12/2012 21:46, David Woolley wrote: David Taylor wrote: On 10/12/2012 21:18, David Woolley wrote: Jeroen Mostert wrote: For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Offsets should be scattered around zero. If they are all the same sign, something is wrong. What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. If there is an actual asymmetry in the delays (the slow uplink may have lower delays, because it is unloaded!), the offsets will still be spread across zero, but zero will not correspond to the true time. So, if the PC also has a stratum-1 clock connected (e.g. PPS), to which it was synced, then the offsets would be spread across the the non-zero difference between computed true time from the Internet and UTC, wouldn't they? In this example: C:\Users\Davidntpq -p narvik remote refid st t when poll reach delay offset jitter == *pixie .PPS.1 u 20 32 3770.1530.371 0.024 +FEENIX .PPS.1 u 25 32 3770.2170.308 0.018 +Stamsund.PPS.1 u 25 32 3770.2210.420 0.050 uk.pool.ntp.org .POOL. 16 p- 102400.0000.000 0.001 -utserv.mcc.ac.u 194.66.31.14 2 u 800 1024 377 23.998 10.566 7.972 -linnaeus.inf.ed 129.215.64.322 u9 1024 377 29.2723.559 3.337 -ntp.uk.syrahost 192.93.2.20 2 u 36 1024 377 27.9574.717 1.551 -cpc2-derb13-2-0 213.248.206.227 2 u 922 1024 377 26.3243.124 3.752 -ntp1.exa-networ 33.117.170.502 u 750 1024 377 42.5604.435 1.156 -ntp2.warwicknet 195.66.241.2 2 u 660 1024 377 22.8194.221 4.440 PC Narvik is synced to a local stratum-1 server, and the WAN servers listed below the POOL entry, mostly have offsets in the 3-4 millisecond region, suggesting (if I understand this correctly) that the delay introduced by the asymmetry of the WAN may be in the 3-4 millisecond region. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-11 12:42, David Taylor wrote: On 10/12/2012 20:17, unruh wrote: [] Since a Linux machine under conditions of use of the internet for time stamps is capable of sub-millisecond synchronization, this seems really bad to me. I thought that clock interrupt went at 1ms intervals, and one should be able to do that well even without interpolation, and with interpolation even better. The latest version of Windows (Win-8) can manage within 5 milliseconds using just Internet servers: http://www.satsignal.eu/ntp/Win-8+Internet.html It returns a more precise clock time, but there still remains one issue which limits its performance (the quantisation of the clock adjustment - it reports it differently from the actual value, sigh!). As you say, Linux timekeeping can do better than Windows, but this is hardly news. Here's some loopstats from a brand new machine running Windows Server 2012: 56273 56211.040 -0.000185248 20.113 0.65610 0.002127 8 56273 57117.052 0.000487392 20.115 0.000245606 0.002073 8 56273 57381.058 0.000771702 20.115 0.000250771 0.001958 8 56273 58424.072 0.000542051 20.118 0.000248229 0.001977 8 56273 59490.107 0.000320045 20.119 0.000245105 0.001903 8 56273 61613.141 0.000101314 20.120 0.000241965 0.001801 8 56273 62411.152 -0.000139791 20.119 0.000241858 0.001691 8 56273 63476.176 -0.000219043 20.118 0.000227966 0.001611 8 56273 65585.223 -0.000361511 20.116 0.000219111 0.001795 8 56273 66112.226 -0.000879125 20.114 0.000274771 0.001787 8 56273 66382.233 -0.000775453 20.113 0.000259625 0.001694 8 56273 66645.246 -0.000818638 20.112 0.000243336 0.001610 8 56273 68744.282 -0.000901985 20.105 0.000229520 0.002861 8 56273 69007.289 -0.000850863 20.105 0.000215455 0.002693 8 56273 69542.304 -0.000541853 20.103 0.000229247 0.002548 8 56273 69801.304 -0.000579627 20.103 0.000214857 0.002391 8 56273 70070.309 -0.000507633 20.102 0.000202585 0.002244 8 56273 70335.311 -0.000527417 20.102 0.000189630 0.002107 8 56273 72431.353 -0.000577564 20.097 0.000178267 0.002512 8 56273 72968.365 -0.000503697 20.096 0.000168786 0.002377 8 This is syncing with Internet time through the NL NTP pool. I've set up four other machines to sync with this server, two virtual and two physical. The virtual machines are running NT 6.0, the physical machines 6.1 (client/server flavors not relevant here). The virtuals do not have the multimedia timer enabled, since I've read that this can negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, ntpd achieves sub-millisecond sync with the local server on all of them almost all of the time. I've registered three spikes on the virtual machines so far, of 2, 5 and 10 ms. To say I'm pleased with the results would be an understatement. In fact, I'm now tempted to try and solve the second problem, which is that no matter how accurately ntpd syncs the clock, there is no Windows API which will allow me to read its value with that accuracy! On the 2012 Server, GetSystemTimePreciseAsFileTime() is available, but most of our machines are still Windows Server 2008/2008 R2 (even with some 2003 server still hanging around). On the physical machines, GetSystemTimeAsFileTime() will get the time with 1 ms resolution since the MM timer will be enabled, which is good enough. On the virtual machines, however, GSTAFT cannot do better than the 15.625 ms resolution it has by default. I suppose it ought to be possible to expose enough of ntpd's internal state through shared memory to reconstruct what it thinks of the time on demand. There are obvious challenges (like appropriate locking and quickly detecting if ntpd has gone away so we can switch back to GSTAFT). I don't suppose anyone has experience with this? :-) -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 12/12/2012 20:58, Jeroen Mostert wrote: [] Here's some loopstats from a brand new machine running Windows Server 2012: 56273 56211.040 -0.000185248 20.113 0.65610 0.002127 8 56273 57117.052 0.000487392 20.115 0.000245606 0.002073 8 56273 57381.058 0.000771702 20.115 0.000250771 0.001958 8 56273 58424.072 0.000542051 20.118 0.000248229 0.001977 8 56273 59490.107 0.000320045 20.119 0.000245105 0.001903 8 56273 61613.141 0.000101314 20.120 0.000241965 0.001801 8 56273 62411.152 -0.000139791 20.119 0.000241858 0.001691 8 56273 63476.176 -0.000219043 20.118 0.000227966 0.001611 8 56273 65585.223 -0.000361511 20.116 0.000219111 0.001795 8 56273 66112.226 -0.000879125 20.114 0.000274771 0.001787 8 56273 66382.233 -0.000775453 20.113 0.000259625 0.001694 8 56273 66645.246 -0.000818638 20.112 0.000243336 0.001610 8 56273 68744.282 -0.000901985 20.105 0.000229520 0.002861 8 56273 69007.289 -0.000850863 20.105 0.000215455 0.002693 8 56273 69542.304 -0.000541853 20.103 0.000229247 0.002548 8 56273 69801.304 -0.000579627 20.103 0.000214857 0.002391 8 56273 70070.309 -0.000507633 20.102 0.000202585 0.002244 8 56273 70335.311 -0.000527417 20.102 0.000189630 0.002107 8 56273 72431.353 -0.000577564 20.097 0.000178267 0.002512 8 56273 72968.365 -0.000503697 20.096 0.000168786 0.002377 8 This is syncing with Internet time through the NL NTP pool. I've set up four other machines to sync with this server, two virtual and two physical. The virtual machines are running NT 6.0, the physical machines 6.1 (client/server flavors not relevant here). The virtuals do not have the multimedia timer enabled, since I've read that this can negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, ntpd achieves sub-millisecond sync with the local server on all of them almost all of the time. I've registered three spikes on the virtual machines so far, of 2, 5 and 10 ms. To say I'm pleased with the results would be an understatement. In fact, I'm now tempted to try and solve the second problem, which is that no matter how accurately ntpd syncs the clock, there is no Windows API which will allow me to read its value with that accuracy! On the 2012 Server, GetSystemTimePreciseAsFileTime() is available, but most of our machines are still Windows Server 2008/2008 R2 (even with some 2003 server still hanging around). On the physical machines, GetSystemTimeAsFileTime() will get the time with 1 ms resolution since the MM timer will be enabled, which is good enough. On the virtual machines, however, GSTAFT cannot do better than the 15.625 ms resolution it has by default. I suppose it ought to be possible to expose enough of ntpd's internal state through shared memory to reconstruct what it thinks of the time on demand. There are obvious challenges (like appropriate locking and quickly detecting if ntpd has gone away so we can switch back to GSTAFT). I don't suppose anyone has experience with this? :-) Yes, that's looking better! I have tried two Win-8/Server-2012 PCs, but only one showed that better performance. At least you can get that performance without needing a Linux or FreeBSD box. There is an issue with getting the time more precisely, and I found some code on the Internet which I translated to Delphi and had a play with. Results are here: http://www.satsignal.eu/ntp/TSCtime.html original page: http://www.lochan.org/2005/keith-cl/useful/win32time.html Perhaps something like that will help you? But please check it carefully! Virtual PCs are another issue altogether, of course. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-12 23:40, David Taylor wrote: On 12/12/2012 20:58, Jeroen Mostert wrote: [] Here's some loopstats from a brand new machine running Windows Server 2012: 56273 56211.040 -0.000185248 20.113 0.65610 0.002127 8 56273 57117.052 0.000487392 20.115 0.000245606 0.002073 8 56273 57381.058 0.000771702 20.115 0.000250771 0.001958 8 56273 58424.072 0.000542051 20.118 0.000248229 0.001977 8 56273 59490.107 0.000320045 20.119 0.000245105 0.001903 8 56273 61613.141 0.000101314 20.120 0.000241965 0.001801 8 56273 62411.152 -0.000139791 20.119 0.000241858 0.001691 8 56273 63476.176 -0.000219043 20.118 0.000227966 0.001611 8 56273 65585.223 -0.000361511 20.116 0.000219111 0.001795 8 56273 66112.226 -0.000879125 20.114 0.000274771 0.001787 8 56273 66382.233 -0.000775453 20.113 0.000259625 0.001694 8 56273 66645.246 -0.000818638 20.112 0.000243336 0.001610 8 56273 68744.282 -0.000901985 20.105 0.000229520 0.002861 8 56273 69007.289 -0.000850863 20.105 0.000215455 0.002693 8 56273 69542.304 -0.000541853 20.103 0.000229247 0.002548 8 56273 69801.304 -0.000579627 20.103 0.000214857 0.002391 8 56273 70070.309 -0.000507633 20.102 0.000202585 0.002244 8 56273 70335.311 -0.000527417 20.102 0.000189630 0.002107 8 56273 72431.353 -0.000577564 20.097 0.000178267 0.002512 8 56273 72968.365 -0.000503697 20.096 0.000168786 0.002377 8 This is syncing with Internet time through the NL NTP pool. I've set up four other machines to sync with this server, two virtual and two physical. The virtual machines are running NT 6.0, the physical machines 6.1 (client/server flavors not relevant here). The virtuals do not have the multimedia timer enabled, since I've read that this can negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, ntpd achieves sub-millisecond sync with the local server on all of them almost all of the time. I've registered three spikes on the virtual machines so far, of 2, 5 and 10 ms. To say I'm pleased with the results would be an understatement. In fact, I'm now tempted to try and solve the second problem, which is that no matter how accurately ntpd syncs the clock, there is no Windows API which will allow me to read its value with that accuracy! On the 2012 Server, GetSystemTimePreciseAsFileTime() is available, but most of our machines are still Windows Server 2008/2008 R2 (even with some 2003 server still hanging around). On the physical machines, GetSystemTimeAsFileTime() will get the time with 1 ms resolution since the MM timer will be enabled, which is good enough. On the virtual machines, however, GSTAFT cannot do better than the 15.625 ms resolution it has by default. I suppose it ought to be possible to expose enough of ntpd's internal state through shared memory to reconstruct what it thinks of the time on demand. There are obvious challenges (like appropriate locking and quickly detecting if ntpd has gone away so we can switch back to GSTAFT). I don't suppose anyone has experience with this? :-) Yes, that's looking better! I have tried two Win-8/Server-2012 PCs, but only one showed that better performance. At least you can get that performance without needing a Linux or FreeBSD box. Yes... but I'm probably getting one anyway, because, well, it's more fun that way. :-) We had the spare server anyway. And Linux still has a better NTP track record than Windows, even with the recent improvements. There is an issue with getting the time more precisely, and I found some code on the Internet which I translated to Delphi and had a play with. Results are here: http://www.satsignal.eu/ntp/TSCtime.html original page: http://www.lochan.org/2005/keith-cl/useful/win32time.html Perhaps something like that will help you? But please check it carefully! That looks promising, I'll look into it. The calibration stuff looks fiddly, though, I'd need to automate that effectively before I could put it into production use. We should be able to do even better by simply calling the get_sys_time_as_filetime pointer from nt_clockstuff.c, which will point to either GetSystemTimePreciseAsFileTime(), GetSystemTimeAsFileTime() or ntpd's own GetInterpTimeAsFileTime() routine, depending on what the OS supports. That would use ntpd's own interpolation if interpolation is being used, which has proven to be highly trustworthy (in my case, at least, I understand mileage varies). The basic approach cannot reliably get sub-millisecond timestamps (since the best GSTAFT can do is a millisecond-accurate timestamp if the MM timer is active) but I don't need that anyway. In theory, I could just extract the NT code from ntpd (minus clock disciplining, of course) and see how well it works when it's not running in a realtime thread, but I suspect the answer is not at all. It looks incredibly tight. Even so it should be possible to have ntpd do the fiddly stuff with realtime threads and keep the results that can't be
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-12 21:58, Jeroen Mostert wrote: Here's some loopstats from a brand new machine running Windows Server 2012: 56273 56211.040 -0.000185248 20.113 0.65610 0.002127 8 56273 57117.052 0.000487392 20.115 0.000245606 0.002073 8 56273 57381.058 0.000771702 20.115 0.000250771 0.001958 8 56273 58424.072 0.000542051 20.118 0.000248229 0.001977 8 56273 59490.107 0.000320045 20.119 0.000245105 0.001903 8 56273 61613.141 0.000101314 20.120 0.000241965 0.001801 8 56273 62411.152 -0.000139791 20.119 0.000241858 0.001691 8 56273 63476.176 -0.000219043 20.118 0.000227966 0.001611 8 56273 65585.223 -0.000361511 20.116 0.000219111 0.001795 8 56273 66112.226 -0.000879125 20.114 0.000274771 0.001787 8 56273 66382.233 -0.000775453 20.113 0.000259625 0.001694 8 56273 66645.246 -0.000818638 20.112 0.000243336 0.001610 8 56273 68744.282 -0.000901985 20.105 0.000229520 0.002861 8 56273 69007.289 -0.000850863 20.105 0.000215455 0.002693 8 56273 69542.304 -0.000541853 20.103 0.000229247 0.002548 8 56273 69801.304 -0.000579627 20.103 0.000214857 0.002391 8 56273 70070.309 -0.000507633 20.102 0.000202585 0.002244 8 56273 70335.311 -0.000527417 20.102 0.000189630 0.002107 8 56273 72431.353 -0.000577564 20.097 0.000178267 0.002512 8 56273 72968.365 -0.000503697 20.096 0.000168786 0.002377 8 This is syncing with Internet time through the NL NTP pool. I've set up four other machines to sync with this server, two virtual and two physical. The virtual machines are running NT 6.0, the physical machines 6.1 (client/server flavors not relevant here). The virtuals do not have the multimedia timer enabled, since I've read that this can negatively affect performance of the host (which makes sense, since driving all virtuals with 1000 interrupts/sec can't be easy). Even so, ntpd achieves sub-millisecond sync with the local server on all of them almost all of the time. I've registered three spikes on the virtual machines so far, of 2, 5 and 10 ms. VM #1: 56273 85876.796 0.18374 50.694 0.21662 0.002233 4 56273 86004.805 0.08291 50.695 0.20574 0.002119 4 56273 86052.822 0.33144 50.696 0.21156 0.002054 4 56273 86180.829 -0.07628 50.695 0.24483 0.001949 4 56273 86196.829 0.20398 50.696 0.24953 0.001827 4 56273 86260.831 0.05560 50.696 0.23924 0.001713 4 56273 86388.856 0.38796 50.701 0.25276 0.002317 4 VM #2: 56273 85960.089 0.15957 50.623 0.000131482 0.005627 4 56273 86039.794 0.27317 50.625 0.000123056 0.005314 4 56273 86167.801 0.89203 50.636 0.000117169 0.006288 4 56273 86183.801 0.000108884 50.637 0.000109822 0.005911 4 56273 86199.807 0.62115 50.638 0.000104051 0.005539 4 56273 86327.809 0.41898 50.644 0.97593 0.005488 4 56273 86343.811 0.38536 50.644 0.91298 0.005138 4 56273 86375.811 0.47414 50.646 0.85459 0.004833 4 I mean, seriously, wow. This is just begging for some high accuracy timestamp reading. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jeroen Mostert wrote: GetSystemTimePreciseAsFileTime() is available, but most of our machines are still Windows Server 2008/2008 R2 (even with some 2003 server still hanging around). On the physical machines, GetSystemTimeAsFileTime() will get the time with 1 ms resolution since the MM timer will be enabled, which is good enough. On the virtual machines, however, GSTAFT cannot do better than the 15.625 ms resolution it has by default. ntpq -c rv 0 precision should give a clue how close you can expect to get on a given machine. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-13 02:41, E-Mail Sent to this address will be added to the BlackLists wrote: Jeroen Mostert wrote: GetSystemTimePreciseAsFileTime() is available, but most of our machines are still Windows Server 2008/2008 R2 (even with some 2003 server still hanging around). On the physical machines, GetSystemTimeAsFileTime() will get the time with 1 ms resolution since the MM timer will be enabled, which is good enough. On the virtual machines, however, GSTAFT cannot do better than the 15.625 ms resolution it has by default. ntpq -c rv0 precision should give a clue how close you can expect to get on a given machine. I assume you mean 'ntpq -c rv 0 precision'. Your command gives me an error. I'm not sure that means much. On the physical machines I get precision=-10, which makes sense since the multimedia timer is on and the resolution of GSTAFT is 1 ms. On the virtuals, however, I get -19 (ntpd 4.2.6p5) and -20 (ntpd 4.2.7p310). That may reflect the numerical precision of the interpolated clock, but that doesn't mean actually reading it with that precision is useful. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 10/12/2012 20:17, unruh wrote: [] Since a Linux machine under conditions of use of the internet for time stamps is capable of sub-millisecond synchronization, this seems really bad to me. I thought that clock interrupt went at 1ms intervals, and one should be able to do that well even without interpolation, and with interpolation even better. The latest version of Windows (Win-8) can manage within 5 milliseconds using just Internet servers: http://www.satsignal.eu/ntp/Win-8+Internet.html It returns a more precise clock time, but there still remains one issue which limits its performance (the quantisation of the clock adjustment - it reports it differently from the actual value, sigh!). As you say, Linux timekeeping can do better than Windows, but this is hardly news. Cheers, David -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
David Taylor wrote: On 10/12/2012 21:18, David Woolley wrote: Jeroen Mostert wrote: For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Offsets should be scattered around zero. If they are all the same sign, something is wrong. What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. I also note that with my PCs being stratum-1 servers or synced to local stratum-1, there is an offset to the WAN servers of some number of milliseconds, typically between +3 ms and +6 ms, but the LAN servers have a near zero average offset. Here just now I have only MSF stratum-1 which from loop_summary is varying widely, over last 7 days from 61+/-1070 rms=266 to 2251+/-4282 rms=527. ADSL is about 12 Mbps down, 1200 kbps up. Other server 21+/-598 rms=166 to 177+/-794 rms=368. During that period NetBSD kernel and userland have been updated on both servers involving 2-3 reboots. The different down/up latency gets lost in the noise. I should have GPS+PPS reconnected next week but don't remember that showing any significant offset from the server with only internet ntp sources. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. Handwaving a bit... The query and the response seem to be something like 90 bytes (including an Ethernet header). That then is 720 bits. At 3 Mbits/s that would be 0.24 milliseconds of transmit time. It would then be 0.024 milliseconds on the downlink. I suspect that asymmetry is dwarfed by either queueing delays (bufferbloat) when either/both are active and/or the rest of the delays from your system to the server(s). rick jones -- It is not a question of half full or empty - the glass has a leak. The real question is Can it be patched? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 11/12/2012 19:35, Rick Jones wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. Handwaving a bit... The query and the response seem to be something like 90 bytes (including an Ethernet header). That then is 720 bits. At 3 Mbits/s that would be 0.24 milliseconds of transmit time. It would then be 0.024 milliseconds on the downlink. I suspect that asymmetry is dwarfed by either queueing delays (bufferbloat) when either/both are active and/or the rest of the delays from your system to the server(s). rick jones Yes, I see what you mean, but I was thinking of the whole network, and not simply the up and down speeds. That we have a 10:1 ratio may suggest how the rest of that ISP's network is configured. The delays in the cable modem, Samknows box, router and 1 Gb/s switch are likely to be far in excess of the 0.024 ms and even the 0.24 ms! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-10 21:41, Jeroen Mostert wrote: On 2012-12-10 21:17, unruh wrote: On 2012-12-10, Jeroen Mostertjmost...@xs4all.nl wrote: snip For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Since a Linux machine under conditions of use of the internet for time stamps is capable of sub-millisecond synchronization, this seems really bad to me. I thought that clock interrupt went at 1ms intervals, and one should be able to do that well even without interpolation, and with interpolation even better. If you say so. I have no idea how I would further diagnose a problem, if there is one, and fix it, if there is a solution. The obvious fix would be to install Linux, but for equally obvious reasons I'm not willing to go there. :-) NTP (and other tools) are indeed reporting a 1 ms resolution of the clock, and I can see the interrupt rate on core 0 is consistently above 1000 interrupts/sec, so I'm guessing that holds up. I noticed the drift was ever-increasing, slowly but surely. Since I muddled with settings quite a bit, I stopped ntpd, deleted ntp.drift and restarted it. The results are quite interesting. 56272 68581.536 0.022139147 2.356 0.006080932 0.008049 10 56272 68781.535 0.021885071 2.357 0.005698660 0.007537 10 56272 69311.535 0.020898356 2.359 0.005342012 0.007109 10 56272 71122.534 0.023597293 0.000 0.008392764 0.00 6 56272 71458.536 0.013381279 39.825 0.012521981 0.00 6 56272 71524.551 0.009503058 39.825 0.011793222 0.00 6 56272 71527.552 0.000754424 39.825 0.011456980 0.00 6 56272 71528.552 0.000233147 39.825 0.010722584 0.00 6 56272 71930.577 -0.013119319 39.511 0.011085491 0.41 6 56272 72003.578 -0.016005287 39.441 0.010419607 0.106838 6 56272 72207.579 -0.031178859 39.062 0.011125504 0.167193 6 56272 72331.588 -0.032740845 38.820 0.010421598 0.178267 6 56272 72607.596 -0.036786552 38.215 0.009852891 0.271267 7 56272 72611.597 -0.048063956 38.212 0.010042013 0.253749 7 56272 72667.599 -0.050119893 38.170 0.009421524 0.237821 7 56272 72960.613 -0.050045193 37.952 0.008819790 0.235492 6 56272 73291.594 -0.049274393 36.980 0.008257379 0.408236 6 56272 73419.587 -0.049355146 36.603 0.007731784 0.404411 6 So now NTP is betting very high on the drift and then shoots the clock in the other direction as a result. I'll give it time to stabilize. Assuming it'll stabilize. I may end up with the same offset at the opposite sign, who knows? -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 11/12/2012 19:35, Rick Jones wrote: Handwaving a bit... The query and the response seem to be something like 90 bytes (including an Ethernet header). That then is 720 bits. At 3 Mbits/s that would be 0.24 milliseconds of transmit time. It would then be 0.024 milliseconds on the downlink. I suspect that asymmetry is dwarfed by either queueing delays (bufferbloat) when either/both are active and/or the rest of the delays from your system to the server(s). Yes, I see what you mean, but I was thinking of the whole network, and not simply the up and down speeds. That we have a 10:1 ratio may suggest how the rest of that ISP's network is configured. The delays in the cable modem, Samknows box, router and 1 Gb/s switch are likely to be far in excess of the 0.024 ms and even the 0.24 ms! Well, I have zero direct knowledge of the internals of an ISP these days, but my understanding of the/a rational behind the asymmetry to the home has to do with allocating limited bandwidth/frequency/spectrum on the physical plant from the ISP's end to the home. If the ISP's internal network (beyond the head end or what ever it would be called) is built on more standard ethernet-ish things, I would expect there to be equivalent bandwidth in each direction since to my knowledge those things have symmetric bandwidth. Of course that doesn't guarantee symmetric routing... rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is Can it be patched? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jeroen Mostert wrote: I noticed the drift was ever-increasing, slowly but surely. Since I muddled with settings quite a bit, I stopped ntpd, deleted ntp.drift and restarted it. The results are quite interesting. 56272 68581.536 0.022139147 2.356 0.006080932 0.008049 10 56272 68781.535 0.021885071 2.357 0.005698660 0.007537 10 56272 69311.535 0.020898356 2.359 0.005342012 0.007109 10 56272 71122.534 0.023597293 0.000 0.008392764 0.00 6 56272 71458.536 0.013381279 39.825 0.012521981 0.00 6 56272 71524.551 0.009503058 39.825 0.011793222 0.00 6 56272 71527.552 0.000754424 39.825 0.011456980 0.00 6 56272 71528.552 0.000233147 39.825 0.010722584 0.00 6 56272 71930.577 -0.013119319 39.511 0.011085491 0.41 6 56272 72003.578 -0.016005287 39.441 0.010419607 0.106838 6 56272 72207.579 -0.031178859 39.062 0.011125504 0.167193 6 56272 72331.588 -0.032740845 38.820 0.010421598 0.178267 6 56272 72607.596 -0.036786552 38.215 0.009852891 0.271267 7 56272 72611.597 -0.048063956 38.212 0.010042013 0.253749 7 56272 72667.599 -0.050119893 38.170 0.009421524 0.237821 7 56272 72960.613 -0.050045193 37.952 0.008819790 0.235492 6 56272 73291.594 -0.049274393 36.980 0.008257379 0.408236 6 56272 73419.587 -0.049355146 36.603 0.007731784 0.404411 6 day, second, offset, drift, est error, stability, poll comp I looked at several of the last few days of loopstats on a few machines; it appears your drift compensation change rate is perhaps hundreds of times what mine are? I'm not certain what that means, is the PC/Device experiencing large Temperature Swings, or Cpu/Core Frequency/Power Management? Ref: http://dx.eng.uiowa.edu/dave/ntptemptext.php ? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
David Taylor wrote: On 10/12/2012 21:18, David Woolley wrote: Jeroen Mostert wrote: For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Offsets should be scattered around zero. If they are all the same sign, something is wrong. What happens if the link to the Internet is rather asymmetrical? For example, here I am stuck with 30 Mb/s down, but only 3 Mb/s up. If there is an actual asymmetry in the delays (the slow uplink may have lower delays, because it is unloaded!), the offsets will still be spread across zero, but zero will not correspond to the true time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-11 22:10, E-Mail Sent to this address will be added to the BlackLists wrote: Jeroen Mostert wrote: I noticed the drift was ever-increasing, slowly but surely. Since I muddled with settings quite a bit, I stopped ntpd, deleted ntp.drift and restarted it. The results are quite interesting. 56272 68581.536 0.022139147 2.356 0.006080932 0.008049 10 56272 68781.535 0.021885071 2.357 0.005698660 0.007537 10 56272 69311.535 0.020898356 2.359 0.005342012 0.007109 10 56272 71122.534 0.023597293 0.000 0.008392764 0.00 6 56272 71458.536 0.013381279 39.825 0.012521981 0.00 6 56272 71524.551 0.009503058 39.825 0.011793222 0.00 6 56272 71527.552 0.000754424 39.825 0.011456980 0.00 6 56272 71528.552 0.000233147 39.825 0.010722584 0.00 6 56272 71930.577 -0.013119319 39.511 0.011085491 0.41 6 56272 72003.578 -0.016005287 39.441 0.010419607 0.106838 6 56272 72207.579 -0.031178859 39.062 0.011125504 0.167193 6 56272 72331.588 -0.032740845 38.820 0.010421598 0.178267 6 56272 72607.596 -0.036786552 38.215 0.009852891 0.271267 7 56272 72611.597 -0.048063956 38.212 0.010042013 0.253749 7 56272 72667.599 -0.050119893 38.170 0.009421524 0.237821 7 56272 72960.613 -0.050045193 37.952 0.008819790 0.235492 6 56272 73291.594 -0.049274393 36.980 0.008257379 0.408236 6 56272 73419.587 -0.049355146 36.603 0.007731784 0.404411 6 day, second, offset, drift, est error, stability, poll comp I looked at several of the last few days of loopstats on a few machines; it appears your drift compensation change rate is perhaps hundreds of times what mine are? I'm not certain what that means, is the PC/Device experiencing large Temperature Swings, or Cpu/Core Frequency/Power Management? Improbable. I've admittedly not measured, but the machine has been running constantly for three days in a room with even heating, with no significant change in load. I don't think there's any way temperature could explain this much drift. CPU frequency remains constant and power management has been turned off. I suspect some driver or other is giving me trouble, preventing ntpd from getting decent readings from the clock. Or maybe the machine is just broken (clockwise, I mean), I guess that happens. For kicks, I repeated the procedure -- stop ntpd, delete the drift file, start ntpd, forcing it to do yet another drift calibration. (The servers must love me.) The difference isn't quite so dramatic, but still notable. 56272 76491.581 -0.039118819 30.383 0.004118758 0.429325 6 56272 76748.567 -0.038717153 29.790 0.003868185 0.453044 6 56272 76884.559 -0.035856775 29.500 0.003757023 0.436066 6 56272 76929.557 -0.023728814 29.436 0.005544073 0.408522 6 56272 77378.579 -0.030387567 0.000 0.010782393 0.00 6 56272 77719.530 0.011532945 33.821 0.031973641 0.00 6 56272 77719.532 0.012297079 33.821 0.029910596 0.00 6 56272 77783.546 -0.000656742 33.821 0.028351163 0.00 6 56272 77800.543 -0.72661 33.821 0.026522332 0.00 6 56272 78118.559 0.001651644 33.852 0.024816859 0.011068 6 56272 78127.560 -0.003217920 33.851 0.023277801 0.010371 6 56272 78193.560 -0.007368853 33.822 0.021823790 0.014112 6 56272 78197.561 -0.014632962 33.818 0.020575203 0.013258 6 56272 78257.562 -0.015837880 33.761 0.019251054 0.023555 7 56272 78989.594 -0.023846042 33.501 0.018228934 0.094564 7 56272 79047.605 -0.024689830 33.480 0.017055101 0.088777 7 The moral of this story is, uhm... time is not on my side. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jeroen Mostert wrote:
BlackLists wrote:
Jeroen Mostert wrote:
I noticed the drift was ever-increasing, slowly but surely.
Since I muddled with settings quite a bit, I stopped ntpd,
deleted ntp.drift and restarted it.
The results are quite interesting.
56272 68581.536 0.022139147 2.356 0.006080932 0.008049 10
56272 68781.535 0.021885071 2.357 0.005698660 0.007537 10
56272 69311.535 0.020898356 2.359 0.005342012 0.007109 10
56272 71122.534 0.023597293 0.000 0.008392764 0.00 6
56272 71458.536 0.013381279 39.825 0.012521981 0.00 6 *
56272 71524.551 0.009503058 39.825 0.011793222 0.00 6 *
56272 71527.552 0.000754424 39.825 0.011456980 0.00 6 *
56272 71528.552 0.000233147 39.825 0.010722584 0.00 6 *
56272 71930.577 -0.013119319 39.511 0.011085491 0.41 6 *
56272 72003.578 -0.016005287 39.441 0.010419607 0.106838 6 *
56272 72207.579 -0.031178859 39.062 0.011125504 0.167193 6 *
56272 72331.588 -0.032740845 38.820 0.010421598 0.178267 6 *
56272 72607.596 -0.036786552 38.215 0.009852891 0.271267 7 *
56272 72611.597 -0.048063956 38.212 0.010042013 0.253749 7 *
56272 72667.599 -0.050119893 38.170 0.009421524 0.237821 7 *
56272 72960.613 -0.050045193 37.952 0.008819790 0.235492 6 *
56272 73291.594 -0.049274393 36.980 0.008257379 0.408236 6 *
56272 73419.587 -0.049355146 36.603 0.007731784 0.404411 6 *
day, second, offset, drift, est error, stability, poll
comp
I looked at several of the last few days of loopstats
on a few machines; it appears your drift compensation
change rate is perhaps hundreds of times what mine are?
I'm not certain what that means, is the PC/Device experiencing
large Temperature Swings, or Cpu/Core Frequency/Power Management?
Improbable. I've admittedly not measured, but the machine has
been running constantly for three days in a room with even
heating, with no significant change in load.
I don't think there's any way temperature could explain this
much drift.
CPU frequency remains constant and power management has been
turned off.
I suspect some driver or other is giving me trouble,
preventing ntpd from getting decent readings from the clock.
Or maybe the machine is just broken (clockwise, I mean),
I guess that happens.
For kicks, I repeated the procedure -- stop ntpd, delete the
drift file, start ntpd, forcing it to do yet another drift
calibration. (The servers must love me.) The difference isn't
quite so dramatic, but still notable.
56272 76491.581 -0.039118819 30.383 0.004118758 0.429325 6
56272 76748.567 -0.038717153 29.790 0.003868185 0.453044 6
56272 76884.559 -0.035856775 29.500 0.003757023 0.436066 6
56272 76929.557 -0.023728814 29.436 0.005544073 0.408522 6
56272 77378.579 -0.030387567 0.000 0.010782393 0.00 6
56272 77719.530 0.011532945 33.821 0.031973641 0.00 6 *
56272 77719.532 0.012297079 33.821 0.029910596 0.00 6 *
56272 77783.546 -0.000656742 33.821 0.028351163 0.00 6 *
56272 77800.543 -0.72661 33.821 0.026522332 0.00 6 *
56272 78118.559 0.001651644 33.852 0.024816859 0.011068 6 *
56272 78127.560 -0.003217920 33.851 0.023277801 0.010371 6 *
56272 78193.560 -0.007368853 33.822 0.021823790 0.014112 6 *
56272 78197.561 -0.014632962 33.818 0.020575203 0.013258 6 *
56272 78257.562 -0.015837880 33.761 0.019251054 0.023555 7 *
56272 78989.594 -0.023846042 33.501 0.018228934 0.094564 7 *
56272 79047.605 -0.024689830 33.480 0.017055101 0.088777 7 *
The moral of this story is, uhm... time is not on my side.
Those latest 22 minute {stdev (0.1357614218)}
drift compensation values * appear to be changing 13%
of the 33 minute set above {stdev (1.0766335301)} ?
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jeroen Mostert wrote: On 2012-12-11 22:10, E-Mail Sent to this address will be added to the BlackLists wrote: Jeroen Mostert wrote: I noticed the drift was ever-increasing, slowly but surely. Since I muddled with settings quite a bit, I stopped ntpd, deleted ntp.drift and restarted it. The results are quite interesting. 56272 68581.536 0.022139147 2.356 0.006080932 0.008049 10 56272 68781.535 0.021885071 2.357 0.005698660 0.007537 10 56272 69311.535 0.020898356 2.359 0.005342012 0.007109 10 56272 71122.534 0.023597293 0.000 0.008392764 0.00 6 56272 71458.536 0.013381279 39.825 0.012521981 0.00 6 56272 71524.551 0.009503058 39.825 0.011793222 0.00 6 56272 71527.552 0.000754424 39.825 0.011456980 0.00 6 56272 71528.552 0.000233147 39.825 0.010722584 0.00 6 56272 71930.577 -0.013119319 39.511 0.011085491 0.41 6 56272 72003.578 -0.016005287 39.441 0.010419607 0.106838 6 56272 72207.579 -0.031178859 39.062 0.011125504 0.167193 6 56272 72331.588 -0.032740845 38.820 0.010421598 0.178267 6 56272 72607.596 -0.036786552 38.215 0.009852891 0.271267 7 56272 72611.597 -0.048063956 38.212 0.010042013 0.253749 7 56272 72667.599 -0.050119893 38.170 0.009421524 0.237821 7 56272 72960.613 -0.050045193 37.952 0.008819790 0.235492 6 56272 73291.594 -0.049274393 36.980 0.008257379 0.408236 6 56272 73419.587 -0.049355146 36.603 0.007731784 0.404411 6 day, second, offset, drift, est error, stability, poll comp I looked at several of the last few days of loopstats on a few machines; it appears your drift compensation change rate is perhaps hundreds of times what mine are? I'm not certain what that means, is the PC/Device experiencing large Temperature Swings, or Cpu/Core Frequency/Power Management? Improbable. I've admittedly not measured, but the machine has been running constantly for three days in a room with even heating, with no significant change in load. I don't think there's any way temperature could explain this much drift. CPU frequency remains constant and power management has been turned off. I suspect some driver or other is giving me trouble, preventing ntpd from getting decent readings from the clock. Or maybe the machine is just broken (clockwise, I mean), I guess that happens. For kicks, I repeated the procedure -- stop ntpd, delete the drift file, start ntpd, forcing it to do yet another drift calibration. (The servers must love me.) The difference isn't quite so dramatic, but still notable. 56272 76491.581 -0.039118819 30.383 0.004118758 0.429325 6 56272 76748.567 -0.038717153 29.790 0.003868185 0.453044 6 56272 76884.559 -0.035856775 29.500 0.003757023 0.436066 6 56272 76929.557 -0.023728814 29.436 0.005544073 0.408522 6 56272 77378.579 -0.030387567 0.000 0.010782393 0.00 6 56272 77719.530 0.011532945 33.821 0.031973641 0.00 6 56272 77719.532 0.012297079 33.821 0.029910596 0.00 6 56272 77783.546 -0.000656742 33.821 0.028351163 0.00 6 56272 77800.543 -0.72661 33.821 0.026522332 0.00 6 56272 78118.559 0.001651644 33.852 0.024816859 0.011068 6 56272 78127.560 -0.003217920 33.851 0.023277801 0.010371 6 56272 78193.560 -0.007368853 33.822 0.021823790 0.014112 6 56272 78197.561 -0.014632962 33.818 0.020575203 0.013258 6 56272 78257.562 -0.015837880 33.761 0.019251054 0.023555 7 56272 78989.594 -0.023846042 33.501 0.018228934 0.094564 7 56272 79047.605 -0.024689830 33.480 0.017055101 0.088777 7 The moral of this story is, uhm... time is not on my side. Here if ntpd is in sync, stopped, driftfile deleted, ntpd restarted the time taken to resync with creation of a new driftfile can be anything from a few hours to a few days. On the pcs that have taken a few days to resync the drift will probably be quite large, maybe 50 ppm but offset after a restart will usually be 1 ms within around around 30 minutes (only slightly longer than a restart of a pc with drift nearer to 0 ppm). I've had pcs with a system clocks so far off that ntpd is unable to correct and sometimes a fixed manual correction has achieved both a low drift and offset but more recent ntpd seems to have automatic calibration which defeats such manual correction (at least ntpd 4.2.6p5 on NetBSD-6). What's the value of your driftfile? pc offset(ms) frequency(ppm) ntp00.275 -50.8 ntp1 -0.106 -10.9 The offsets above are subject to a fair degree of jitter but frequency is fairly constant depending on temperature. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-12 01:20, David Lord wrote: Jeroen Mostert wrote: On 2012-12-11 22:10, E-Mail Sent to this address will be added to the BlackLists wrote: Jeroen Mostert wrote: I noticed the drift was ever-increasing, slowly but surely. Since I muddled with settings quite a bit, I stopped ntpd, deleted ntp.drift and restarted it. The results are quite interesting. 56272 68581.536 0.022139147 2.356 0.006080932 0.008049 10 56272 68781.535 0.021885071 2.357 0.005698660 0.007537 10 56272 69311.535 0.020898356 2.359 0.005342012 0.007109 10 56272 71122.534 0.023597293 0.000 0.008392764 0.00 6 56272 71458.536 0.013381279 39.825 0.012521981 0.00 6 56272 71524.551 0.009503058 39.825 0.011793222 0.00 6 56272 71527.552 0.000754424 39.825 0.011456980 0.00 6 56272 71528.552 0.000233147 39.825 0.010722584 0.00 6 56272 71930.577 -0.013119319 39.511 0.011085491 0.41 6 56272 72003.578 -0.016005287 39.441 0.010419607 0.106838 6 56272 72207.579 -0.031178859 39.062 0.011125504 0.167193 6 56272 72331.588 -0.032740845 38.820 0.010421598 0.178267 6 56272 72607.596 -0.036786552 38.215 0.009852891 0.271267 7 56272 72611.597 -0.048063956 38.212 0.010042013 0.253749 7 56272 72667.599 -0.050119893 38.170 0.009421524 0.237821 7 56272 72960.613 -0.050045193 37.952 0.008819790 0.235492 6 56272 73291.594 -0.049274393 36.980 0.008257379 0.408236 6 56272 73419.587 -0.049355146 36.603 0.007731784 0.404411 6 day, second, offset, drift, est error, stability, poll comp I looked at several of the last few days of loopstats on a few machines; it appears your drift compensation change rate is perhaps hundreds of times what mine are? I'm not certain what that means, is the PC/Device experiencing large Temperature Swings, or Cpu/Core Frequency/Power Management? Improbable. I've admittedly not measured, but the machine has been running constantly for three days in a room with even heating, with no significant change in load. I don't think there's any way temperature could explain this much drift. CPU frequency remains constant and power management has been turned off. I suspect some driver or other is giving me trouble, preventing ntpd from getting decent readings from the clock. Or maybe the machine is just broken (clockwise, I mean), I guess that happens. For kicks, I repeated the procedure -- stop ntpd, delete the drift file, start ntpd, forcing it to do yet another drift calibration. (The servers must love me.) The difference isn't quite so dramatic, but still notable. 56272 76491.581 -0.039118819 30.383 0.004118758 0.429325 6 56272 76748.567 -0.038717153 29.790 0.003868185 0.453044 6 56272 76884.559 -0.035856775 29.500 0.003757023 0.436066 6 56272 76929.557 -0.023728814 29.436 0.005544073 0.408522 6 56272 77378.579 -0.030387567 0.000 0.010782393 0.00 6 56272 77719.530 0.011532945 33.821 0.031973641 0.00 6 56272 77719.532 0.012297079 33.821 0.029910596 0.00 6 56272 77783.546 -0.000656742 33.821 0.028351163 0.00 6 56272 77800.543 -0.72661 33.821 0.026522332 0.00 6 56272 78118.559 0.001651644 33.852 0.024816859 0.011068 6 56272 78127.560 -0.003217920 33.851 0.023277801 0.010371 6 56272 78193.560 -0.007368853 33.822 0.021823790 0.014112 6 56272 78197.561 -0.014632962 33.818 0.020575203 0.013258 6 56272 78257.562 -0.015837880 33.761 0.019251054 0.023555 7 56272 78989.594 -0.023846042 33.501 0.018228934 0.094564 7 56272 79047.605 -0.024689830 33.480 0.017055101 0.088777 7 The moral of this story is, uhm... time is not on my side. Here if ntpd is in sync, stopped, driftfile deleted, ntpd restarted the time taken to resync with creation of a new driftfile can be anything from a few hours to a few days. I've just observed the same behavior on a server running Windows Server 2012 which is far better at keeping track of time -- it can take a really, really long time before the drift stabilizes. I've decided to terminate the NTP experiment for my home machine. Normally, it's turned off for the night, and in the interest of conserving power I'll return to that policy. Even with the problems ntpd has it's still better than nothing, and as long as it can keep the actual offset within one second (a very loose goal it has no trouble meeting) it's acceptable. My machine isn't used for anything where accurate time is critical, or even useful. What's the value of your driftfile? At present, 32.980, but the value is still trending downwards. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
David Taylor wrote: Glad the stats were of some help, and glad to have had the chat. ages ago I needed to timestamp large datasets from a spectrometer rushing in at 50 .. 100 Sample Sets/s. ( on SYSVR3.5 on a MVME167 System ) One way would have been to sync the system via DCF77 and ntp or similar. This would have presented a significant porting effort. My solution was to sample a GPIO pin attached to the DCF77 signal and insert this information together with the freerunning system uptime variable into my data sets. A utility later extracted the DCF time and synced it to the uptime counter. The only hard requirement was for the uptimecounter to be shortime stable. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-09 16:10, Jeroen Mostert wrote: On 2012-12-09 16:00, Jeroen Mostert wrote: I'm going to leave it alone for a bit to see the results after ntpd gets some time to stabilize. For reference, I've done all of the following so far: - Upgraded to ntpd 4.2.7p310. - Replaced individual server lines with a single pool line. - Adjusted power management options within Windows to make processors run at 100%. - Updated the BIOS. (Also scratched my nose, which I expect has the same effect.) - Turned off explicit processor frequency stepping options in the BIOS. - Used bcdedit /set useplatformclock on to force exclusive use of the HPET (I'm guessing this does nothing at the moment since interpolation isn't used). - Last but not least, restarted ntpd. And forgot: - Disabled Teredo tunneling. Likely nothing to do with the performance, but ntpd was logging spurious events for the Teredo interfaces appearing/disappearing. Since I do nothing with IPv6, I saw no reason why this should be on. For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Thanks to all involved and especially David Taylor for his excellent site on NTP on Windows. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-10, Jeroen Mostert jmost...@xs4all.nl wrote: On 2012-12-09 16:10, Jeroen Mostert wrote: On 2012-12-09 16:00, Jeroen Mostert wrote: I'm going to leave it alone for a bit to see the results after ntpd gets some time to stabilize. For reference, I've done all of the following so far: - Upgraded to ntpd 4.2.7p310. - Replaced individual server lines with a single pool line. - Adjusted power management options within Windows to make processors run at 100%. - Updated the BIOS. (Also scratched my nose, which I expect has the same effect.) - Turned off explicit processor frequency stepping options in the BIOS. - Used bcdedit /set useplatformclock on to force exclusive use of the HPET (I'm guessing this does nothing at the moment since interpolation isn't used). - Last but not least, restarted ntpd. And forgot: - Disabled Teredo tunneling. Likely nothing to do with the performance, but ntpd was logging spurious events for the Teredo interfaces appearing/disappearing. Since I do nothing with IPv6, I saw no reason why this should be on. For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Since a Linux machine under conditions of use of the internet for time stamps is capable of sub-millisecond synchronization, this seems really bad to me. I thought that clock interrupt went at 1ms intervals, and one should be able to do that well even without interpolation, and with interpolation even better. Thanks to all involved and especially David Taylor for his excellent site on NTP on Windows. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-10 21:17, unruh wrote: On 2012-12-10, Jeroen Mostertjmost...@xs4all.nl wrote: snip For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Since a Linux machine under conditions of use of the internet for time stamps is capable of sub-millisecond synchronization, this seems really bad to me. I thought that clock interrupt went at 1ms intervals, and one should be able to do that well even without interpolation, and with interpolation even better. If you say so. I have no idea how I would further diagnose a problem, if there is one, and fix it, if there is a solution. The obvious fix would be to install Linux, but for equally obvious reasons I'm not willing to go there. :-) NTP (and other tools) are indeed reporting a 1 ms resolution of the clock, and I can see the interrupt rate on core 0 is consistently above 1000 interrupts/sec, so I'm guessing that holds up. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
Jeroen Mostert wrote: For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Offsets should be scattered around zero. If they are all the same sign, something is wrong. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-10 22:18, David Woolley wrote: Jeroen Mostert wrote: For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Offsets should be scattered around zero. If they are all the same sign, something is wrong. OK. Well, that's too bad, I guess. Throw me a bone here, fellas. It's nice to know something is wrong, but if all I can see is that all peers consistently report offsets in this range, the best I can conclude is that either ntpd simply isn't successful in disciplining the clock appropriately, or there is some network problem going on that someone who understands the NTP protocol could probably diagnose. That someone would not yet be me. If I offset the offsets (pardon my math) by -33 milliseconds, I'd roughly have a zero axis that they'd be swinging around with a range of -10/+10. According to unruh, even that would still be horrible in terms of accuracy, so I'm not sure if that's fair in its simplicity. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-10, Jeroen Mostert jmost...@xs4all.nl wrote: On 2012-12-10 22:18, David Woolley wrote: Jeroen Mostert wrote: For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Offsets should be scattered around zero. If they are all the same sign, something is wrong. OK. Well, that's too bad, I guess. Throw me a bone here, fellas. It's nice to know something is wrong, but if all I can see is that all peers consistently report offsets in this range, the best I can conclude is that either ntpd simply isn't successful in disciplining the clock appropriately, or there is some network problem going on that someone who understands the NTP protocol could probably diagnose. That someone would not yet be me. If I offset the offsets (pardon my math) by -33 milliseconds, I'd roughly have a zero axis that they'd be swinging around with a range of -10/+10. According to unruh, even that would still be horrible in terms of accuracy, so I'm not sure if that's fair in its simplicity. Ah, if it really is 33 ms off on average, then yes something is wrong. I assumed that you meant that the width of the scatter was 27-41ms, not that the actual offset was always one sign and that far off. However I do have to ask what this offset is. What are your server entries in ntp.conf? Is this offset the offset from the same server that is being used to set the time? Maybe a few lines from /var/log/ntp/peerstats.xxx would let us see what the offset was doing. Or using some of the plotting programs to plot the offsets measured from the varios servers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-10 22:54, unruh wrote: On 2012-12-10, Jeroen Mostertjmost...@xs4all.nl wrote: On 2012-12-10 22:18, David Woolley wrote: Jeroen Mostert wrote: For what it's worth, after all of that, the offset is steadily zigzagging between 27 and 41 ms, which I'm guessing is about the best you can hope for on a Windows machine with Internet sync. There have not been any major time step adjustments. Offsets should be scattered around zero. If they are all the same sign, something is wrong. OK. Well, that's too bad, I guess. Throw me a bone here, fellas. It's nice to know something is wrong, but if all I can see is that all peers consistently report offsets in this range, the best I can conclude is that either ntpd simply isn't successful in disciplining the clock appropriately, or there is some network problem going on that someone who understands the NTP protocol could probably diagnose. That someone would not yet be me. If I offset the offsets (pardon my math) by -33 milliseconds, I'd roughly have a zero axis that they'd be swinging around with a range of -10/+10. According to unruh, even that would still be horrible in terms of accuracy, so I'm not sure if that's fair in its simplicity. Ah, if it really is 33 ms off on average, then yes something is wrong. I assumed that you meant that the width of the scatter was 27-41ms, not that the actual offset was always one sign and that far off. However I do have to ask what this offset is. What are your server entries in ntp.conf? pool nl.pool.ntp.org iburst Is this offset the offset from the same server that is being used to set the time? Maybe a few lines from /var/log/ntp/peerstats.xxx would let us see what the offset was doing. Or using some of the plotting programs to plot the offsets measured from the varios servers. ntpq -np: remote refid st t when poll reach delay offset jitter == nl.pool.ntp.org .POOL. 16 p- 6400.0000.000 0.977 *213.136.0.252 .PPS.1 u 800 1024 377 18.958 35.896 10.670 +213.239.154.12 193.190.230.65 2 u 572 1024 377 18.924 35.018 8.883 +81.171.44.131 193.190.230.66 2 u 528 1024 377 18.855 34.990 7.952 +46.19.33.5 193.79.237.142 u 381 1024 377 17.953 35.253 8.111 +95.211.111.53 221.238.121.188 3 u 674 1024 377 18.924 35.641 8.806 +195.191.113.251 193.79.237.142 u 694 1024 377 19.920 34.866 7.075 +178.251.121.16 193.67.79.2022 u7 1024 377 18.956 33.863 8.940 -83.98.201.133 153.60.75.10 2 u 703 1024 377 17.986 33.285 7.294 +192.87.106.2192.87.106.3 2 u 484 1024 377 17.853 32.520 6.394 peerstats tail of today (cutting off the first column to prevent wrapping): 77050.630 46.19.33.5 1424 0.032273618 0.018946933 0.016009420 0.005895699 77422.629 178.251.121.16 141a 0.034412494 0.018950946 0.016068324 0.009463505 77724.626 213.136.0.252 161a 0.035895776 0.018958086 0.016099349 0.010622052 77792.626 83.98.201.133 133a 0.035527840 0.018976950 0.016341863 0.009205395 77925.626 213.239.154.12 141a 0.031416422 0.017919850 0.020178597 0.006312898 77982.626 81.171.44.131 143a 0.031503337 0.018806412 0.020621400 0.005369126 78106.626 46.19.33.5 1424 0.035252534 0.017952556 0.016150506 0.008054216 78867.627 83.98.201.133 133a 0.033285314 0.017985677 0.016441743 0.007294158 78876.629 195.191.113.251 143a 0.034866163 0.019920461 0.016225952 0.007074704 78896.628 95.211.111.53 1424 0.035640734 0.018924019 0.020330239 0.008805813 78998.630 213.239.154.12 141a 0.035017893 0.018924218 0.020397573 0.008882811 79042.628 81.171.44.131 143a 0.034990054 0.018854869 0.020404077 0.007952290 79086.627 192.87.106.2 141a 0.032519558 0.017852997 0.016296482 0.006394490 79563.628 178.251.121.16 141a 0.033863486 0.018955711 0.020809018 0.008940402 As far as I can tell the peer offsets are OK, if you just ignore the fact that they're all too high -- and stay that way. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 08/12/2012 19:52, Jeroen Mostert wrote: If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): Log Name: System Source:Microsoft-Windows-Kernel-General Date: 2012-12-08 15:18:52 Event ID: 1 Task Category: None Level: Information Keywords: Time User: PORTIA\ntp Computer: PORTIA Description: The system time has changed to 2012-12-08T14:18:52.34700Z from 2012-12-08T14:18:52.569674500Z. As I understand it, it's not supposed to be doing this, instead it should slow the clock down. Event log entries from NTP (using the Meinberg install on Win7 64-bit): ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2) Raised to realtime priority class MM timer resolution: 1..100 msec, set to 1 msec Performance counter frequency 3.215 MHz Clock interrupt period 15.600 msec (startup slew 0.2 usec/period) Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.100 usec This is just a client machine syncing with NTP pool machines, no PPS. If my Googling indicates anything, those last two lines might indicate a problem since NTP is supposed to be using interpolation and it doesn't. There's also hints that the crazy huge precision value indicates a problem with a driver. However, I've checked two other machines and they log the same thing, so maybe this is normal. I've tried 4.2.7p310 binaries as well, but they log nearly the same thing: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec (startup slew -0.3 usec/period) Performance counter frequency 3.215 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.000 usec (-10) proto: fuzz beneath 0.201 usec The clock is now being adjusted forwards instead of backwards, but still with big increments. Current ntpq -pn output: remote refid st t when poll reach delay offset jitter == +89.188.26.129 193.79.237.142 u 56 64 377 24.989 20.536 8.671 +91.148.192.49 193.67.79.2022 u 35 64 377 17.968 35.173 13.029 -85.12.35.12 134.221.205.12 2 u 37 64 377 16.989 25.143 10.667 *83.98.155.30193.79.237.142 u 16 64 377 18.963 34.747 13.242 Any hints/tips? If NTP is regularly using big steps to adjust the time, it suggests that something is wrong. I would take a look at the drift value to see whether the clock on your PC has a frequency which is too far in error. You can also enable loopstats collection, and use a tool such as Meinberg's NTP Time Server Monitor or my own NTP Plotter to display the results: http://www.meinbergglobal.com/english/sw/ntp.htm http://www.satsignal.eu/software/net.htm#NTPplotter I would recommend moving to the newer pool directive rather than the older multiple pool server lines: http://www.satsignal.eu/ntp/setup.html#pool as it may use more pool servers than you would but, more importantly, it reviews the servers from time to time and will drop badly performing ones (i.e. broken) and replace them with a new one. NTP will use interpolation on Windows XP and Windows-8, but normally not in Windows Vista or Windows-7. Yes, it can be worth experimenting with these settings as you later report. Does the poll increase from 64 to higher values as NTP runs, or is it stuck on 64? I have seen one issue on Windows-7 where, at boot-up, NTP makes the wrong choice about interpolation because the system clock at that time is running at 15.6 ms, whereas it will later switch to 1 ms (I may have the explanation slightly wrong). For this reason, on both my Windows-7 LAN-synced PCs I have: NTPD_USE_SYSTEM_CLOCK=1 But I do then see: using Windows clock directly in the NTP events. Please let us know how you get on. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-09 09:37, David Taylor wrote: On 08/12/2012 19:52, Jeroen Mostert wrote: If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): Log Name: System Source: Microsoft-Windows-Kernel-General Date: 2012-12-08 15:18:52 Event ID: 1 Task Category: None Level: Information Keywords: Time User: PORTIA\ntp Computer: PORTIA Description: The system time has changed to 2012-12-08T14:18:52.34700Z from 2012-12-08T14:18:52.569674500Z. As I understand it, it's not supposed to be doing this, instead it should slow the clock down. Event log entries from NTP (using the Meinberg install on Win7 64-bit): ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2) Raised to realtime priority class MM timer resolution: 1..100 msec, set to 1 msec Performance counter frequency 3.215 MHz Clock interrupt period 15.600 msec (startup slew 0.2 usec/period) Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.100 usec This is just a client machine syncing with NTP pool machines, no PPS. If my Googling indicates anything, those last two lines might indicate a problem since NTP is supposed to be using interpolation and it doesn't. There's also hints that the crazy huge precision value indicates a problem with a driver. However, I've checked two other machines and they log the same thing, so maybe this is normal. I've tried 4.2.7p310 binaries as well, but they log nearly the same thing: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec (startup slew -0.3 usec/period) Performance counter frequency 3.215 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.000 usec (-10) proto: fuzz beneath 0.201 usec The clock is now being adjusted forwards instead of backwards, but still with big increments. Current ntpq -pn output: remote refid st t when poll reach delay offset jitter == +89.188.26.129 193.79.237.14 2 u 56 64 377 24.989 20.536 8.671 +91.148.192.49 193.67.79.202 2 u 35 64 377 17.968 35.173 13.029 -85.12.35.12 134.221.205.12 2 u 37 64 377 16.989 25.143 10.667 *83.98.155.30 193.79.237.14 2 u 16 64 377 18.963 34.747 13.242 Any hints/tips? If NTP is regularly using big steps to adjust the time, it suggests that something is wrong. I would take a look at the drift value to see whether the clock on your PC has a frequency which is too far in error. You can also enable loopstats collection Drift is currently at -2.3, and no abnormally high/low values have been recorded. Loopstats collection has been on since the beginning. From the period where these big adjustments happen, I get some suspicious data: 56269 38100.218 0.0 19.486 0.00238 0.120120 9 56269 38105.421 -0.054125528 19.486 0.019136264 0.112362 9 56269 38109.421 -0.054433286 19.486 0.017900666 0.105105 9 56269 39160.464 -0.072777326 19.415 0.017956687 0.101492 9 56269 41770.153 0.0 19.415 0.00238 0.094937 9 56269 41775.482 -0.002025903 19.415 0.000716265 0.088805 9 56269 41905.412 -0.044579941 19.409 0.015060036 0.083092 9 56269 43888.511 -0.066275609 19.287 0.016040319 0.088960 9 56269 47068.130 0.0 19.287 0.00238 0.083214 9 The 0 offsets suggest ntpd regularly thinks we're now in perfect sync, something which is certainly not true. I don't know how to properly interpret the error and stability values. and use a tool such as Meinberg's NTP Time Server Monitor or my own NTP Plotter to display the results: http://www.meinbergglobal.com/english/sw/ntp.htm http://www.satsignal.eu/software/net.htm#NTPplotter Not to look a gift horse in the mouth, but the fact that your plotter has drag and drop for input is annoying. This (to me) is one of the least convenient mechanisms for providing input. Since the plotter cannot meaningfully run without input, you might as well throw an Open File dialog up when it starts. And/or use the Windows convention of supplying a File - Open menu. I had to actually look in the readme to even realize it used drag and drop at all. The lack of feedback doesn't help either. When I drag peerstats.20121209 it's accepted but nothing happens, but it doesn't tell me why not. (Experimentally, the reason is that you must drag all files simultaneously, and the set must contain loopstats. Dragging peerstats individually never does anything, whether before or after it's already seen loopstats.) As far as the results go, practically all the graphs look crazy, with enormous spikes (as you'd imagine). I'll have to do more research before I can meaningfully interpret them. I would recommend moving to the newer pool directive rather than the older multiple pool server lines:
Re: [ntp:questions] Win7: ntpd adjusting time backwards
The 0 offsets suggest ntpd regularly thinks we're now in perfect sync, something which is certainly not true. I don't know how to properly interpret the error and stability values. Zero offset means that the timestamp it read, plus half the round trip time, matches what it thinks is the local clock time. There may be errors in the timestamp, and the outward and return delay times may be different. My guess, if you are getting a lot of zeroes, is that both the current system and the upstream system are not able to read their local times very precisely. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-09 09:37, David Taylor wrote: I have seen one issue on Windows-7 where, at boot-up, NTP makes the wrong choice about interpolation because the system clock at that time is running at 15.6 ms, whereas it will later switch to 1 ms (I may have the explanation slightly wrong). For this reason, on both my Windows-7 LAN-synced PCs I have: NTPD_USE_SYSTEM_CLOCK=1 But I do then see: using Windows clock directly in the NTP events. For what it's worth, after a reboot (with all custom overrides removed), I saw exactly the behavior you describe. And this is after the system is already up and running, starting ntpd manually. ntpd logs this: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec Performance counter frequency 14.318 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 15.600 msec, min. slew 6.410 ppm/s HZ 64.102 using 43 msec timer 23.256 Hz 64 deep Even though the multimedia timer has been set to 1 msec, GetSystemTimeAsFileTime() is still returning timestamps with a 15.6 msec offset. This should be 1 msec. Running clockres (from SysInternals) gives back that the timer interval is indeed 1 msec. Restarting NTP: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec (startup slew -0.1 usec/period) Performance counter frequency 14.318 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly I'm not sure what the issue is, here. Either ntpd somehow fails to set the multimedia timer (unlikely), or there is a delay between the multimedia timer getting set and the resolution increase in GetSystemTimeAsFileTime(), or (worst) GetSystemTimeAsFileTime() actually can't make up its mind. I'd need to whip up some code to test this. If it's due to a (subsecond) delay, it would be trivial to fix this in ntpd. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 09/12/2012 10:17, Jeroen Mostert wrote: [] Drift is currently at -2.3, and no abnormally high/low values have been recorded. Loopstats collection has been on since the beginning. From the period where these big adjustments happen, I get some suspicious data: 56269 38100.218 0.0 19.486 0.00238 0.120120 9 56269 38105.421 -0.054125528 19.486 0.019136264 0.112362 9 56269 38109.421 -0.054433286 19.486 0.017900666 0.105105 9 56269 39160.464 -0.072777326 19.415 0.017956687 0.101492 9 56269 41770.153 0.0 19.415 0.00238 0.094937 9 56269 41775.482 -0.002025903 19.415 0.000716265 0.088805 9 56269 41905.412 -0.044579941 19.409 0.015060036 0.083092 9 56269 43888.511 -0.066275609 19.287 0.016040319 0.088960 9 56269 47068.130 0.0 19.287 0.00238 0.083214 9 The 0 offsets suggest ntpd regularly thinks we're now in perfect sync, something which is certainly not true. I don't know how to properly interpret the error and stability values. and use a tool such as Meinberg's NTP Time Server Monitor or my own NTP Plotter to display the results: http://www.meinbergglobal.com/english/sw/ntp.htm http://www.satsignal.eu/software/net.htm#NTPplotter Not to look a gift horse in the mouth, but the fact that your plotter has drag and drop for input is annoying. This (to me) is one of the least convenient mechanisms for providing input. Since the plotter cannot meaningfully run without input, you might as well throw an Open File dialog up when it starts. And/or use the Windows convention of supplying a File - Open menu. I had to actually look in the readme to even realize it used drag and drop at all. The lack of feedback doesn't help either. When I drag peerstats.20121209 it's accepted but nothing happens, but it doesn't tell me why not. (Experimentally, the reason is that you must drag all files simultaneously, and the set must contain loopstats. Dragging peerstats individually never does anything, whether before or after it's already seen loopstats.) As far as the results go, practically all the graphs look crazy, with enormous spikes (as you'd imagine). I'll have to do more research before I can meaningfully interpret them. I would recommend moving to the newer pool directive rather than the older multiple pool server lines: http://www.satsignal.eu/ntp/setup.html#pool as it may use more pool servers than you would but, more importantly, it reviews the servers from time to time and will drop badly performing ones (i.e. broken) and replace them with a new one. Thanks. For some reason, none of the documentation I've read even mentions this directive, and that includes the setup instructions of the pool.ntp.org website, and all manpages for ntpd.conf I've come across. This is the first time I hear about it. NTP will use interpolation on Windows XP and Windows-8, but normally not in Windows Vista or Windows-7. Yes, it can be worth experimenting with these settings as you later report. Does the poll increase from 64 to higher values as NTP runs, or is it stuck on 64? It increases all the way up to 1024. I have seen one issue on Windows-7 where, at boot-up, NTP makes the wrong choice about interpolation because the system clock at that time is running at 15.6 ms, whereas it will later switch to 1 ms (I may have the explanation slightly wrong). For this reason, on both my Windows-7 LAN-synced PCs I have: NTPD_USE_SYSTEM_CLOCK=1 But I do then see: using Windows clock directly in the NTP events. Yes, that doesn't appear to be the issue. Please let us know how you get on. The pool directive had some effect (I now have 9 servers instead of 4) and initially the offset stayed under 10 ms, but it seems that as soon as the poll interval goes above 64, the offset starts slipping -- currently at 30 ms. I'll keep things under observation; I get the feeling it hasn't quite stabilized yet. I wonder whether you 0 offset values mean that NTP has restarted itself, perhaps after making one the time jumps? My NTP Plotter program will take an input file or directory from the command-line, as documented in the read-me, so you need only set up a batch command once and double-click it to see the current data. I'm always open to user suggestions, and so far no-one else has asked for a File|Open dialogue! But you are right that the program expects at least a loopstats file (or directory) to be dropped. It finds the peerstats automatically. The primary documentation for NTP is the set of HTML pages, not manpages. I do agree that the pool directive could be more widely publicised, and I have suggested that Meinberg incorporate that into their default install If you are still seeing stepping, I would want to investigate that further. It could be that your Internet connection is not so good (any Wi-Fi involved?), but it didn't look like that from the stats. One possibility may be to set maxpoll lower than 10 in the pool directive. It should be higher than 6 (64 seconds) to
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-09 15:14, David Taylor wrote: On 09/12/2012 10:17, Jeroen Mostert wrote: [] Drift is currently at -2.3, and no abnormally high/low values have been recorded. Loopstats collection has been on since the beginning. From the period where these big adjustments happen, I get some suspicious data: 56269 38100.218 0.0 19.486 0.00238 0.120120 9 56269 38105.421 -0.054125528 19.486 0.019136264 0.112362 9 56269 38109.421 -0.054433286 19.486 0.017900666 0.105105 9 56269 39160.464 -0.072777326 19.415 0.017956687 0.101492 9 56269 41770.153 0.0 19.415 0.00238 0.094937 9 56269 41775.482 -0.002025903 19.415 0.000716265 0.088805 9 56269 41905.412 -0.044579941 19.409 0.015060036 0.083092 9 56269 43888.511 -0.066275609 19.287 0.016040319 0.088960 9 56269 47068.130 0.0 19.287 0.00238 0.083214 9 The 0 offsets suggest ntpd regularly thinks we're now in perfect sync, something which is certainly not true. I don't know how to properly interpret the error and stability values. snip The pool directive had some effect (I now have 9 servers instead of 4) and initially the offset stayed under 10 ms, but it seems that as soon as the poll interval goes above 64, the offset starts slipping -- currently at 30 ms. I'll keep things under observation; I get the feeling it hasn't quite stabilized yet. I wonder whether you 0 offset values mean that NTP has restarted itself, perhaps after making one the time jumps? No, the service is definitely running continuously. My NTP Plotter program will take an input file or directory from the command-line, as documented in the read-me, so you need only set up a batch command once and double-click it to see the current data. Fair enough. I have no problem not getting a File - Open menu from the likes of gnuplot, but that's because that *only* has a command-line interface so I expect no better. If something starts up with a GUI, though, I expect to be able to use it without reading documentation. Funny how that goes. :-) I'm always open to user suggestions, and so far no-one else has asked for a File|Open dialogue! But you are right that the program expects at least a loopstats file (or directory) to be dropped. It finds the peerstats automatically. Provided it is named peerstats.somethingsomething, right? Unfortunately, the easy-to-find pages for troubleshooting NTP at http://www.ntp.org/ntpfaq/NTP-s-trouble.htm arbitrarily rename the files to loops and peers, which is what I've been using (and other folks too, I'd wager). I'm going to remove those options, but not just yet (since I don't want to stitch files together). The primary documentation for NTP is the set of HTML pages, not manpages. Well, you're right. http://www.eecis.udel.edu/~mills/ntp/html/confopt.html describes this option, as well as the Meinberg docs (which are an earlier version). The information seems to be ungoogleable in that you must read the whole thing top to bottom before you know it exists, but that is of course no excuse. It is a shame that nothing *outside* the reference documentation (in particular quick-start guides) seems to describe the use of this option, though. It's also unfortunate that ntpd has been around so long (with relatively few changes) that outdated documentation is a dime a dozen. If you are still seeing stepping, I would want to investigate that further. It could be that your Internet connection is not so good (any Wi-Fi involved?), but it didn't look like that from the stats. One possibility may be to set maxpoll lower than 10 in the pool directive. It should be higher than 6 (64 seconds) to avoid being /too/ unfriendly to the servers you are using, but perhaps 8 (256 seconds) might prevent things for getting so far out that a reset is required. I would figure this might fix things, but I'm holding off on that because (as you say) this is not friendly on servers and would also not fix/identify the root cause -- if my admittedly meager understanding of how NTP works is correct, then it shouldn't be necessary to poll the servers very frequently unless there's something inherently non-linearly wrong with your clock. I don't think we're at the bottom of this yet. Are you running any other software which might attempt to set the time? The W32time service is disabled and stopped? No fancy audio-visual programs being run? Nothing which completely hogs the CPU or saturates the network connection? Just some odd things to think about! Nothing of the sort. It is a consumer PC used for everything, including gaming, and although no gaming has been going on there could in theory be some exotic driver or piece of software mucking things up in a non-obvious way. If there is, though, I have no idea how to find it other than through an extremely tedious bisection that's really not worth it. If it turns out that NTP cannot work without stepping my clock every so often, I can actually live with that. Not so much if it
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-09 16:00, Jeroen Mostert wrote: I'm going to leave it alone for a bit to see the results after ntpd gets some time to stabilize. For reference, I've done all of the following so far: - Upgraded to ntpd 4.2.7p310. - Replaced individual server lines with a single pool line. - Adjusted power management options within Windows to make processors run at 100%. - Updated the BIOS. (Also scratched my nose, which I expect has the same effect.) - Turned off explicit processor frequency stepping options in the BIOS. - Used bcdedit /set useplatformclock on to force exclusive use of the HPET (I'm guessing this does nothing at the moment since interpolation isn't used). - Last but not least, restarted ntpd. And forgot: - Disabled Teredo tunneling. Likely nothing to do with the performance, but ntpd was logging spurious events for the Teredo interfaces appearing/disappearing. Since I do nothing with IPv6, I saw no reason why this should be on. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 09/12/2012 15:00, Jeroen Mostert wrote: [] No, the service is definitely running continuously. [] Fair enough. I have no problem not getting a File - Open menu from the likes of gnuplot, but that's because that *only* has a command-line interface so I expect no better. If something starts up with a GUI, though, I expect to be able to use it without reading documentation. Funny how that goes. :-) [] Provided it is named peerstats.somethingsomething, right? Unfortunately, the easy-to-find pages for troubleshooting NTP at http://www.ntp.org/ntpfaq/NTP-s-trouble.htm arbitrarily rename the files to loops and peers, which is what I've been using (and other folks too, I'd wager). I'm going to remove those options, but not just yet (since I don't want to stitch files together). The primary documentation for NTP is the set of HTML pages, not manpages. Well, you're right. http://www.eecis.udel.edu/~mills/ntp/html/confopt.html describes this option, as well as the Meinberg docs (which are an earlier version). The information seems to be ungoogleable in that you must read the whole thing top to bottom before you know it exists, but that is of course no excuse. It is a shame that nothing *outside* the reference documentation (in particular quick-start guides) seems to describe the use of this option, though. It's also unfortunate that ntpd has been around so long (with relatively few changes) that outdated documentation is a dime a dozen. [] I would figure this might fix things, but I'm holding off on that because (as you say) this is not friendly on servers and would also not fix/identify the root cause -- if my admittedly meager understanding of how NTP works is correct, then it shouldn't be necessary to poll the servers very frequently unless there's something inherently non-linearly wrong with your clock. [] Nothing of the sort. It is a consumer PC used for everything, including gaming, and although no gaming has been going on there could in theory be some exotic driver or piece of software mucking things up in a non-obvious way. If there is, though, I have no idea how to find it other than through an extremely tedious bisection that's really not worth it. If it turns out that NTP cannot work without stepping my clock every so often, I can actually live with that. Not so much if it happens on real machines, of course. This is strictly a research project. It is worth reporting, however, that no stepping has been occurring since I first reported the problem. This could be due to a simple restart of ntpd and not through any options I've tinkered with. I've tinkered with a *lot* of them, and since I'm not a professional scientist, I have made no attempt at systematic analysis of all options separately and combined, of course, just continued tweaking while I wasn't satisfied :-) I'm going to leave it alone for a bit to see the results after ntpd gets some time to stabilize. For reference, I've done all of the following so far: - Upgraded to ntpd 4.2.7p310. - Replaced individual server lines with a single pool line. - Adjusted power management options within Windows to make processors run at 100%. - Updated the BIOS. (Also scratched my nose, which I expect has the same effect.) - Turned off explicit processor frequency stepping options in the BIOS. - Used bcdedit /set useplatformclock on to force exclusive use of the HPET (I'm guessing this does nothing at the moment since interpolation isn't used). - Last but not least, restarted ntpd. Offset are still horrid (30 ms) but I notice the drift is swinging up too, so my guess is that ntpd hasn't fixed on a good value yet after all the tinkering (and/or my clock is just bogus for reasons yet unknown). If that doesn't work out, I may take apart the network traffic (including the DSL router) to see if that has anything to do with anything. Delay and jitter on the NTP packets seem fairly high (although I don't know if that would explain continuous bad offsets). NTO restarting - I meant a logical internal restart after a step, not the service restarting. I recall that the NTP Plotter is fairly open to accepting various different file names automatically because, as you say, different places have different recommendations. Sigh! Maybe I'll add a File|Open dialog if the program starts with no file specified, but it's not top priority at the moment. Nothing describes pool? Well, my Windows set-up page (also referenced by Meinberg) does for a start. As I mentioned, I haven't tried Internet servers alone recently on Windows except for one brief test with Windows-8 (because it has more precise time routines): http://www.satsignal.eu/ntp/Win-8+Internet.html and I did a test with a Linux server, WAN-only as well: http://www.satsignal.eu/ntp/2012-11-10-11-12-raspi1_ntp-b-day.png If precise timekeeping is important, it may be worth upgrading to Windows-8 (although I saw an improvement on only one of two PCs tested). Re IPv6, I turn
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-09 17:00, David Taylor wrote: On 09/12/2012 15:00, Jeroen Mostert wrote: It is a shame that nothing *outside* the reference documentation (in particular quick-start guides) seems to describe the use of this option, though. It's also unfortunate that ntpd has been around so long (with relatively few changes) that outdated documentation is a dime a dozen. Nothing describes pool? Well, my Windows set-up page (also referenced by Meinberg) does for a start. Yes indeed: David Taylor created a detailed step-by-step walkthrough of the installation on his website. Pshaw! As if I'm going to read some step-by-step walkthrough! There's screenshots below the thing, right? This David Taylor guy can't possibly have something more interesting to say. The above is, of course, steeped in irony, since your site is a veritable treasure trove for people setting up NTP under Windows. I really wish I'd stumbled across it sooner. I know I didn't find it through the Meinberg site. As I mentioned, I haven't tried Internet servers alone recently on Windows except for one brief test with Windows-8 (because it has more precise time routines): http://www.satsignal.eu/ntp/Win-8+Internet.html and I did a test with a Linux server, WAN-only as well: http://www.satsignal.eu/ntp/2012-11-10-11-12-raspi1_ntp-b-day.png If precise timekeeping is important, it may be worth upgrading to Windows-8 (although I saw an improvement on only one of two PCs tested). As long as Microsoft still doesn't make it possible to upgrade the kernel without upgrading the shell, that's not going to happen, because the Windows 8 UI is a serious productivity killer for me. The broader context is that I'm working on an NTP setup for a real network, where the only demand is that the servers stay within each other's times to some reasonable degree (I'll take anything = 10 ms), with only very lax demands on synchronizing to absolute time. I've already discovered that this is actually fairly easy as long as all machines sync to a single local server with some frequency (setting minpoll 4 maxpoll 4 is no problem on a LAN, of course, and keeps even the most wayward machines in line). I'm still happy I ran into problems locally, because upgrading to 4.2.7 significantly reduces jitter even in this setup (as reported by your site as well), so I'll be sure to slipstream that in. Of course, upgrading all machines to Windows 8/Windows Server 2012 just to get better time synchronization isn't going to happen. :-) For now the local server is a Windows Server 2008 machine, but I've already petitioned for a dedicated Linux machine (FreeBSD would be too out there for IT, I'm afraid...) If possible, we can later upgrade that to something with a GPS, but it's probably not necessary at the moment. It may well be that 30 - 40 ms is the best you can expect without some local server (e.g. FreeBSD/Linux/Win-8 box on your LAN), but stepping every hour should not normally be happening. If 30-40 ms is realistic for syncing to internet time, I'll take it. Though it's slightly disappointing, but I guess the limitation is in Windows more than it is in NTP. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-09 18:18, David Taylor wrote: On 09/12/2012 16:26, Jeroen Mostert wrote: [] As long as Microsoft still doesn't make it possible to upgrade the kernel without upgrading the shell, that's not going to happen, because the Windows 8 UI is a serious productivity killer for me. The broader context is that I'm working on an NTP setup for a real network, where the only demand is that the servers stay within each other's times to some reasonable degree (I'll take anything = 10 ms), with only very lax demands on synchronizing to absolute time. I've already discovered that this is actually fairly easy as long as all machines sync to a single local server with some frequency (setting minpoll 4 maxpoll 4 is no problem on a LAN, of course, and keeps even the most wayward machines in line). I'm still happy I ran into problems locally, because upgrading to 4.2.7 significantly reduces jitter even in this setup (as reported by your site as well), so I'll be sure to slipstream that in. Of course, upgrading all machines to Windows 8/Windows Server 2012 just to get better time synchronization isn't going to happen. :-) For now the local server is a Windows Server 2008 machine, but I've already petitioned for a dedicated Linux machine (FreeBSD would be too out there for IT, I'm afraid...) If possible, we can later upgrade that to something with a GPS, but it's probably not necessary at the moment. [] If 30-40 ms is realistic for syncing to internet time, I'll take it. Though it's slightly disappointing, but I guess the limitation is in Windows more than it is in NTP. Win-8 is almost the same as Win-7, just add a start-menu add-on such as ClassicShell. Quite tolerable, then (although DOS shell, run as Administrator takes a little more effort!). Yeah, no. I categorically refuse to upgrade my OS (at a non-zero cost) and then install some extra stuff just to make it *acceptable* again. That's just insane. I guess if you need the new features in Windows 8, it might be worth considering the time and effort, but at present I know of no such features. The increased clock accuracy isn't one. I'm waiting for Windows NT 6.3, or 7.0, whatever the marketing name ends up being. If that still has Metro, I'll see how I'll compensate. But I'm hoping it won't. What I would agree for your situation is to have a local server to which you tight-lock (low min/maxpoll) the rest. But as a result of my own recent tests, I would make that local server a Raspberry Pi or similar (it's very low cost) running Linux and synced to the Internet, and if it suits, make that a stratum-1 server with a GPS/PPS for a score of dollar/pounds more. I work for a Windows shop with too much money and too little time. It's going to be a spare server we had lying around; suggesting folks get enthusiastic with hardware that's not from Dell isn't going to fly. :-) So the Raspberry Pi is out, and upgrading to a stratum 1 only if there's a demonstrable need. This is all basically a spare time effort from me, to enable more accurate performance analysis of cross-server events. It's not exactly mission critical, but nice to have. There was a significant period of time where we had no time syncing whatsoever, and we only started to run into problems when one machine was 19 seconds off from actual time. I then configured w32time on all machines, but w32time is not particularly robust. Microsoft itself admits it's just there to make sure Kerberos doesn't completely fail, and as long as it keeps time within 5 minutes from a domain controller they don't care. I'm now at a point where I think machines deviating from each other for more than 10 ms is annoying, so that won't do anymore. No need to upgrade all PCs, just one server. PCs Hydra and Narvik here are on a LAN connection. http://www.satsignal.eu/mrtg/performance_ntp.php and PCs Molde, Puffin, Torvik and Ystad are Wi-Fi connected (which doesn't help timekeeping). Note the difference between XP and Windows-7. Statistics like those would be more than acceptable for my purposes. Your worst stats would be good enough for me. Your suggested arrangement of a Linux time server (which can be a very simple, low-powered PC) and tight coupling of the rest should give you excellent results. It's actually going to be far heavier than is necessary, but I'm confident it'll get the job done. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 09/12/2012 17:59, Jeroen Mostert wrote: [] Yeah, no. I categorically refuse to upgrade my OS (at a non-zero cost) and then install some extra stuff just to make it *acceptable* again. That's just insane. I guess if you need the new features in Windows 8, it might be worth considering the time and effort, but at present I know of no such features. The increased clock accuracy isn't one. I'm waiting for Windows NT 6.3, or 7.0, whatever the marketing name ends up being. If that still has Metro, I'll see how I'll compensate. But I'm hoping it won't. [] I work for a Windows shop with too much money and too little time. It's going to be a spare server we had lying around; suggesting folks get enthusiastic with hardware that's not from Dell isn't going to fly. :-) So the Raspberry Pi is out, and upgrading to a stratum 1 only if there's a demonstrable need. This is all basically a spare time effort from me, to enable more accurate performance analysis of cross-server events. It's not exactly mission critical, but nice to have. There was a significant period of time where we had no time syncing whatsoever, and we only started to run into problems when one machine was 19 seconds off from actual time. I then configured w32time on all machines, but w32time is not particularly robust. Microsoft itself admits it's just there to make sure Kerberos doesn't completely fail, and as long as it keeps time within 5 minutes from a domain controller they don't care. I'm now at a point where I think machines deviating from each other for more than 10 ms is annoying, so that won't do anymore. [] Statistics like those would be more than acceptable for my purposes. Your worst stats would be good enough for me. [] It's actually going to be far heavier than is necessary, but I'm confident it'll get the job done. I'm on a subscription for the Windows OS, and many of my customers are now upgrading to WIndows-8, or buying new PCs woth that OS, so I really have no choice to invest. Windows-7 is a fine OS for general purpose work and, if asked, I don't see any need for folk to upgrade. In fact Windows XP has many advantages as a lighter-weight OS than Win-7. Of course, if you have a Dell spare box, use that. Linux or FreeBSD. I used to be in a similar job myself, and actually introduced my branch of the company to NTP, which we used on both Windows and UNIX boxes. We were a DEC shop, but whether we ever got round to NTP on VMS I don't recall. I do recall Spring and Autumn events involving time, so perhaps we did not. My aim is to be within 1 millisecond, as the events my systems record have a resolution of 1 ms. It's nice, but not essential, to be able to correlate events across four separate satellite data reception systems. Glad the stats were of some help, and glad to have had the chat. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Win7: ntpd adjusting time backwards
If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): Log Name: System Source:Microsoft-Windows-Kernel-General Date: 2012-12-08 15:18:52 Event ID: 1 Task Category: None Level: Information Keywords: Time User: PORTIA\ntp Computer: PORTIA Description: The system time has changed to 2012-12-08T14:18:52.34700Z from 2012-12-08T14:18:52.569674500Z. As I understand it, it's not supposed to be doing this, instead it should slow the clock down. Event log entries from NTP (using the Meinberg install on Win7 64-bit): ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2) Raised to realtime priority class MM timer resolution: 1..100 msec, set to 1 msec Performance counter frequency 3.215 MHz Clock interrupt period 15.600 msec (startup slew 0.2 usec/period) Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.100 usec This is just a client machine syncing with NTP pool machines, no PPS. If my Googling indicates anything, those last two lines might indicate a problem since NTP is supposed to be using interpolation and it doesn't. There's also hints that the crazy huge precision value indicates a problem with a driver. However, I've checked two other machines and they log the same thing, so maybe this is normal. I've tried 4.2.7p310 binaries as well, but they log nearly the same thing: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec (startup slew -0.3 usec/period) Performance counter frequency 3.215 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.000 usec (-10) proto: fuzz beneath 0.201 usec The clock is now being adjusted forwards instead of backwards, but still with big increments. Current ntpq -pn output: remote refid st t when poll reach delay offset jitter == +89.188.26.129 193.79.237.142 u 56 64 377 24.989 20.536 8.671 +91.148.192.49 193.67.79.2022 u 35 64 377 17.968 35.173 13.029 -85.12.35.12 134.221.205.12 2 u 37 64 377 16.989 25.143 10.667 *83.98.155.30193.79.237.142 u 16 64 377 18.963 34.747 13.242 Any hints/tips? -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-08, Jeroen Mostert jmost...@xs4all.nl wrote: If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): Log Name: System Source:Microsoft-Windows-Kernel-General Date: 2012-12-08 15:18:52 Event ID: 1 Task Category: None Level: Information Keywords: Time User: PORTIA\ntp Computer: PORTIA Description: The system time has changed to ???2012???-???12???-???08T14:18:52.34700Z from ???2012???-???12???-???08T14:18:52.569674500Z. As I understand it, it's not supposed to be doing this, instead it should slow the clock down. No. ntpd jumps the time, forward or backward, if the time is out by more than 128 microseconds. Since ntpd puts a limit of 500PPM on the clock rate adjust, it would take a minimum of 3 hours to fix a 1 second error. (and a year to fix a 1 hr error) if it only used the slew rate to fix the time error. On Linux there are two clock rate fix machanisms-- a fine rate adjust and a coarse one. The coarse one can change the rate up to 10PPM so could in principle fix a 10 hr offset in 4 days, but ntpd does not use that mechanism. It jumps instead (Ie, it has a fine rate adjust and an infinite rate adjust only). I do not know if windows has the same coarse rate adjust mechanism. Note that both operating systems use the coarse adjust at bootup when they calibrate the system clock rate. If your timer rate is out by a lot, you can recalibrate by hand and readjust the system clock rate using that coarse adjust. The main question is whether or not your jumping indicates more severe problems-- ie why is the clock finding itself so far out that it has to jump. Why is the usual ntpd fixing mechanism not working properly. Do you get this behaviour only at the beginning, or after ntpd has been running for days? Event log entries from NTP (using the Meinberg install on Win7 64-bit): ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2) Raised to realtime priority class MM timer resolution: 1..100 msec, set to 1 msec Performance counter frequency 3.215 MHz Clock interrupt period 15.600 msec (startup slew 0.2 usec/period) Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.100 usec This is just a client machine syncing with NTP pool machines, no PPS. If my Googling indicates anything, those last two lines might indicate a problem since NTP is supposed to be using interpolation and it doesn't. There's also hints that the crazy huge precision value indicates a problem with a driver. However, I've checked two other machines and they log the same thing, so maybe this is normal. I've tried 4.2.7p310 binaries as well, but they log nearly the same thing: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec (startup slew -0.3 usec/period) Performance counter frequency 3.215 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.000 usec (-10) proto: fuzz beneath 0.201 usec The clock is now being adjusted forwards instead of backwards, but still with big increments. Current ntpq -pn output: remote refid st t when poll reach delay offset jitter == +89.188.26.129 193.79.237.142 u 56 64 377 24.989 20.536 8.671 +91.148.192.49 193.67.79.2022 u 35 64 377 17.968 35.173 13.029 -85.12.35.12 134.221.205.12 2 u 37 64 377 16.989 25.143 10.667 *83.98.155.30193.79.237.142 u 16 64 377 18.963 34.747 13.242 Any hints/tips? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-08 21:12, unruh wrote: On 2012-12-08, Jeroen Mostertjmost...@xs4all.nl wrote: If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): snip As I understand it, it's not supposed to be doing this, instead it should slow the clock down. No. ntpd jumps the time, forward or backward, if the time is out by more than 128 microseconds. I think you mean 128 milliseconds. That's what I'm getting from the docs, anyway. I thought ntp could adjust the time forwards in big steps, but would never adjust the time backwards. I'm guessing I got confused with the slew-only option (-x) for servers that absolutely cannot tolerate the clock going backwards, even if it takes forever to adjust it through slew only. Note that both operating systems use the coarse adjust at bootup when they calibrate the system clock rate. If your timer rate is out by a lot, you can recalibrate by hand and readjust the system clock rate using that coarse adjust. Since this machine more or less serves as a guinea pig/model for deployment in a network, calibrating stuff by hand is basically not going to be an option in the production environment. I'm just going to have to count on that working out. The main question is whether or not your jumping indicates more severe problems-- ie why is the clock finding itself so far out that it has to jump. Why is the usual ntpd fixing mechanism not working properly. Do you get this behaviour only at the beginning, or after ntpd has been running for days? At the time of the event, ntpd had been running for 19 hours (same as system uptime). This is of course not that long in NTP terms. The first clock adjustment (logged in the event log) came at 40 seconds uptime, then 4 hours later, and after that it started adjusting about every hour. With your explanation, I'm perfectly willing to blame crappy network conditions and/or crappy pool servers on the frequent adjustments. Looking at another machine, I see zero (0) adjustments there since ntpd was configured to use a central, local time server (stratum 2). This machine has no time-critical services, so as long as it's accurate to within 1 sec/day I can't complain. I was just confused about the clock going backwards. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-08 22:03, David Woolley wrote: If you suffer from temporary severe asymmetric delays, you can use the huff and puff tinker option to try and compensate. Given that the adjustments come about every hour, and the machine is not doing anything particularly interesting with the network, *and* I've seen this behavior on other Win7-machines configured to use the NTP pool servers (with radically different network setup/use) I doubt that would do the trick. But I'll keep it in mind. For now I've tried setting NTPD_USE_INTERP_DANGEROUS, because 1) it has DANGEROUS in the name, FOR SCIENCE! and 2) it's reported that the interpolation may actually work again on Windows 7 machines, sometimes (it didn't work well on Vista, which is why ntpd started using the clock directly). Though it's really too early to tell, it's interesting that the offset has kept to 40 ms since the last restart 2 hours ago and no adjustment to the system time has been logged, so this may be a keeper. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
