Re: [ntp:questions] NTP_MAXCLOCK in ntp.h
Mischanko, Edward T wrote: David, What evidence would be acceptable? I'm on a Windows machine, so how + would I go about capturing ntpq -p to post it here? The evidence you are using, for a start. As best I can remember, ntpq works on Windows. I can't think of anything non-standard it might want to do. Copying and pasting text from a DOS Boz may be a lost art, but it is certainly possible (use the left hand corner control menu). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP_MAXCLOCK in ntp.h
-Original Message- From: questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org [mailto:questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org] On Behalf Of David Woolley Sent: Tuesday, December 11, 2012 2:33 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] NTP_MAXCLOCK in ntp.h Mischanko, Edward T wrote: David, What evidence would be acceptable? I'm on a Windows machine, so how + would I go about capturing ntpq -p to post it here? The evidence you are using, for a start. As best I can remember, ntpq works on Windows. I can't think of anything non-standard it might want to do. Copying and pasting text from a DOS Boz may be a lost art, but it is certainly possible (use the left hand corner control menu). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions [Mischanko, Edward T] Thanks, David. I was able to modify a batch file that redirects the output of ntpq -p to a text file. I should be able to cut and paste from there. No the problem is I can't get it to do it again. If it ever exceeds 10 candidates again while I'm watching, then I'll post the evidence. :-) Thanks, Ed ___ 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] NTP_MAXCLOCK in ntp.h
-Original Message- From: Mischanko, Edward T Sent: Tuesday, December 11, 2012 2:53 AM To: questions@lists.ntp.org Subject: RE: [ntp:questions] NTP_MAXCLOCK in ntp.h -Original Message- From: questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org [mailto:questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org] On Behalf Of David Woolley Sent: Tuesday, December 11, 2012 2:33 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] NTP_MAXCLOCK in ntp.h Mischanko, Edward T wrote: David, What evidence would be acceptable? I'm on a Windows machine, so how + would I go about capturing ntpq -p to post it here? The evidence you are using, for a start. As best I can remember, ntpq works on Windows. I can't think of anything non-standard it might want to do. Copying and pasting text from a DOS Boz may be a lost art, but it is certainly possible (use the left hand corner control menu). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions [Mischanko, Edward T] Thanks, David. I was able to modify a batch file that redirects the output of ntpq -p to a text file. I should be able to cut and paste from there. No the problem is I can't get it to do it again. If it ever exceeds 10 candidates again while I'm watching, then I'll post the evidence. :-) Thanks, Ed [Mischanko, Edward T] I now have the evidence!! remote refid st t when poll reach delay offset jitter == +xxx.xxx.0.1 xxx.xxx.104.14 u9 32 1771.3030.312 4.534 +xxx.xxx.1.1 xxx.xxx.104.14 u4 32 3771.581 -0.262 4.627 +xxx.xxx.106.1 xxx.xxx.104.14 u 35 32 177 14.034 -6.267 3.745 +xxx.xxx.109.1 xxx.xxx.104.14 u 35 32 1771.503 -6.274 4.701 +xxx.xxx.110.1 xxx.xxx.104.14 u1 32 3774.7122.509 4.661 +xxx.xxx.112.1 xxx.xxx.104.14 u 33 32 1771.5771.753 5.437 +xxx.xxx.120.1 xxx.xxx.104.14 u 30 32 1771.3970.292 5.065 +xxx.xxx.121.1 xxx.xxx.104.14 u 31 32 1771.377 -6.034 3.962 +xxx.xxx.122.1 xxx.xxx.104.14 u 30 32 1771.786 -5.658 12.872 +xxx.xxx.123.1 xxx.xxx.104.14 u 31 32 1771.661 -5.436 3.475 +xxx.xxx.124.1 xxx.xxx.104.14 u 28 32 1771.6210.861 5.630 +xxx.xxx.125.1 xxx.xxx.104.14 u 28 32 1771.609 -5.344 3.737 +xxx.xxx.126.1 xxx.xxx.104.14 u 26 32 1771.5680.990 5.362 +xxx.xxx.129.1 xxx.xxx.104.14 u 27 32 1771.743 -6.641 3.919 +xxx.xxx.131.1 xxx.xxx.104.14 u 26 32 1771.579 -6.766 4.085 +xxx.xxx.134.1 xxx.xxx.104.14 u 22 32 1771.687 -4.519 4.721 +xxx.xxx.255.100 xxx.xxx.104.14 u 23 32 1770.761 -5.671 4.013 *xxx.xxx.255.200 xxx.xxx.104.14 u 22 32 1770.472 -5.641 4.124 +xxx.xxx.43.1 xxx.xxx.255.200 5 u 19 32 1771.168 -5.909 4.234 04.ameri xxx.xxx.242.249 5 u 21 32 1770.657 -32.581 18.102 x3.ameri xxx.xxx.242.249 5 u 19 32 1771.285 -33.645 12.719 xx.ameri xxx.xxx.250.248 4 u 16 32 1771.151 -19.906 7.480 xxx1v.mi xxx.xxx.250.248 4 u 35 32 1770.615 -26.309 4.581 v.mi xxx.xxx.250.248 4 u1 32 3771.189 -19.459 5.721 ___ 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
