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] Consequences of orphan mode enabled at startup
rumeg...@ugpa.ru wrote: Why does a ntp server (with tos orphan enabled) start answering requests before all existing peers are checked for availability? Is there any good reason? (Shrug) Peoples have to make workarounds to avoid such behavior. They shouldn't have to. If the orphan stratum is high enough, e.g. 10, between the ophan's stratum, the orphan's dispersion, the clients reach count for the orphan, and the clients checking other servers, they would ignore the orphan, till it got its act together. How do you deal with is? I mean a configuration like below: server ntp.mydomain.ru true iburst prefer minpoll 6 maxpoll 10 tos orphan 6 tos maxdist 3 tinker panic 0 If you set it on a windows machine and reboot, the time would be broken for about 10 minutes after startup. And what is more, the bad time would be provided across the LAN. Which gets ignored? How it can be avoided? Have the clients look at more than server? e.g. # Start ntpd with -g, the -g will prevent a panic stop if the time needs to be stepped when started # ntp.conf for ALL (Clients and/or Servers) tos cohort 1 orphan 11 restrict default limited kod nomodify notrap restrict 127.0.0.1 restrict source nomodify keys /etc/ntp.keys # e.g. contains: 123 M YOUR_MD5_KEY trustedkey 123 manycastserver 224.0.1.1 manycastclient 224.0.1.1 key 123 preempt multicastclient 224.0.1.1 key 123 preempt broadcastclient # server ###.###.###.### iburst key 123 # server ntp.example.net iburst preempt # pool pool.ntp.org preempt# Won't hurt anything if the internet can't be reached Switching off tos orphan doesn't fit my requirements.. -- 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-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
[ntp:questions] NTP_MAXCLOCK in ntp.h
Please tell me why when watching my client with NTP Time Server Monitor by Meinberg, my client does not honor the NTP_MAXCLOCK setting in the ntp.h file. Thanks, Ed Mischanko ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP_MAXCLOCK in ntp.h
Mischanko, Edward T wrote: Please tell me why when watching my client with NTP Time Server Monitor by Meinberg, my client does not honor the NTP_MAXCLOCK setting in the ntp.h file. Please provide the evidence. ntpq peers may be more useful. I suspect the answer comes down to the parameter not doing what you think it does. ___ 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 1:21 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] NTP_MAXCLOCK in ntp.h Mischanko, Edward T wrote: Please tell me why when watching my client with NTP Time Server Monitor by Meinberg, my client does not honor the NTP_MAXCLOCK setting in the ntp.h file. Please provide the evidence. ntpq peers may be more useful. I suspect the answer comes down to the parameter not doing what you think it does. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions [Mischanko, Edward T] 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? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP_MAXCLOCK in ntp.h
On 2012-12-11, Mischanko, Edward T edward.mischa...@arcelormittal.com wrote: Please tell me why when watching my client with NTP Time Server Monitor by Meinberg, my client does not honor the NTP_MAXCLOCK setting in the ntp.h file. Why do you thing your client does not honour that setting? And what do you think this setting does? ___ 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 unruh Sent: Tuesday, December 11, 2012 1:36 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] NTP_MAXCLOCK in ntp.h On 2012-12-11, Mischanko, Edward T edward.mischa...@arcelormittal.com wrote: Please tell me why when watching my client with NTP Time Server Monitor by Meinberg, my client does not honor the NTP_MAXCLOCK setting in the ntp.h file. Why do you thing your client does not honour that setting? And what do you think this setting does? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions [Mischanko, Edward T] I believe the setting limits the maximum amount of peers that are selected as candidates for averaging? /* * Selection algorithm tuning parameters */ #define NTP_MINCLOCK3 /* min survivors */ #define NTP_MAXCLOCK10 /* max candidates */ #define MINDISPERSE .001/* min distance */ #define MAXDISTANCE 1.5 /* max root distance (select threshold) */ #define CLOCK_SGATE 3.0 /* popcorn spike gate */ #define HUFFPUFF900 /* huff-n'-puff sample interval (s) */ #define MAXHOP 2 /* anti-clockhop threshold */ #define MAX_TTL 8 /* max ttl mapping vector size */ #define BEACON 7200/* manycast beacon interval */ #define NTP_MAXEXTEN2048/* max extension field size */ #define NTP_ORPHWAIT300 /* orphan wair (s) */ /* ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
