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
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 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!). 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. 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. 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. -- 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 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 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: [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 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. 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
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 st
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
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: 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
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
