Re: NTP Client synchronization with a Windows 2003/2008
On Wednesday 14 October 2009 18:04:41 Jacques Henry wrote: Alternatively, from the commandline try ntpd -g -q -c /etc/ntp.conf The -g flag allows ntpd to set the clock once regardless of the offset and the -q causes it to quit after setting the time. I tried this command without success... I can see the NTP packets (client and server) but the clock is never set Are you running with an elevated securelevel? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
2009/10/15 Chris Hill ch...@monochrome.org On Wed, 14 Oct 2009, Jacques Henry wrote: The 19 minutes between when I sent my suggestions and you responded is hardly enough time to see if ntpd was slewing the time. Slewing 587 seconds takes days. The thing is that ntpd is not slewing the time at all, even after several hours!! If I may pipe up... Can you not set the clock manually, then let ntpd take it from there? Seems like your clock would become synced a lot faster if it started out close. Sorry if I'm being naive, but this seemed like the obvious thing to do. -- Chris Hill ch...@monochrome.org ** [ Busy Expunging | ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org sometimes the crude and simple methods are the best 8) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
If I may pipe up... Can you not set the clock manually, then let ntpd take it from there? Seems like your clock would become synced a lot faster if it started out close. Sorry if I'm being naive, but this seemed like the obvious thing to do. Don't apologize! Any input is valuable! But I don't quite understand what you meant about let ntpd take it from here or if it started out close... (I am French and maybe you're using a figure of language I don't understand...) Are you running with an elevated securelevel? No the Secure Level is -1... But I've found the beginning of a solution... It doesn't come from ntpd but from the Windows Time Server. When configured to sync with its internal clock, the NTP Server IP packets that goes to the client contain strange values (rootdispersion, etc.) that are higher than expected. Thus, ntpd doesn't consider the Windows Server as a reliable source. But once the windows server configured to sync with an external source, it works! The IP packets generated from the windows server begin to look like real and reliable answer to ntpd... I'm working now on a correct configuration of the Windows Server. Thanks again to all! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
On Tuesday 13 October 2009 18:44:57 Jon Radel wrote: Jacques Henry wrote: I commented the commands involved and nothing changed... (with only 10 minutes of time difference) The 19 minutes between when I sent my suggestions and you responded is hardly enough time to see if ntpd was slewing the time. Slewing 587 seconds takes days. I even tried to force the sync: U450XA0A0800650nstop ntp U450XA0A0800650ntpd -x -n -q -c /var/ntp.conf U450XA0A0800650nstart ntp Are you sure that -x in there, telling ntpd to not step unless the offset is over 600 sec, doesn't override what you're trying to do with the -q? How about you try simple: ntpdate the_windows_server and see what that does? After that look in /var/log/messages. In fact I am still quite convinced that the MS implementation isn't totally compliant with the client... Could be, but ntpq was showing that your ntpd was accepting time data from the Windows server at least on some level. Alternatively, from the commandline try ntpd -g -q -c /etc/ntp.conf The -g flag allows ntpd to set the clock once regardless of the offset and the -q causes it to quit after setting the time. In /etc/rc.conf, all you should need is ntpd_enable=YES ntpd_sync_on_start=YES The second option adds -g to the ntpd flags, allowing it to set the clock at startup and continue running. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
The 19 minutes between when I sent my suggestions and you responded is hardly enough time to see if ntpd was slewing the time. Slewing 587 seconds takes days. The thing is that ntpd is not slewing the time at all, even after several hours!! Are you sure that -x in there, telling ntpd to not step unless the offset is over 600 sec, doesn't override what you're trying to do with the -q? How about you try simple: ntpdate the_windows_server and see what that does? After that look in /var/log/messages. I don't have that command on my system... Alternatively, from the commandline try ntpd -g -q -c /etc/ntp.conf The -g flag allows ntpd to set the clock once regardless of the offset and the -q causes it to quit after setting the time. I tried this command without success... I can see the NTP packets (client and server) but the clock is never set with the debugging option enabled (-D 3), at the end I get: ... ... poll_update: at 15 172.30.1.5 flags 0201 poll 6 burst 1 last 1 next 17 read_network_packet: fd=22 length 48 from ac1e0105 172.30.1.5 receive: at 15 172.30.1.250-172.30.1.5 flags 19 restrict 080 receive: at 15 172.30.1.250-172.30.1.5 mode 4 code 1 auth 0 packet: flash header 0040 addto_syslog: no reply; clock not set ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
On Wed, 14 Oct 2009, Jacques Henry wrote: The 19 minutes between when I sent my suggestions and you responded is hardly enough time to see if ntpd was slewing the time. Slewing 587 seconds takes days. The thing is that ntpd is not slewing the time at all, even after several hours!! If I may pipe up... Can you not set the clock manually, then let ntpd take it from there? Seems like your clock would become synced a lot faster if it started out close. Sorry if I'm being naive, but this seemed like the obvious thing to do. -- Chris Hill ch...@monochrome.org ** [ Busy Expunging | ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
On Tue, 13 Oct 2009 17:13:16 +0200 Jacques Henry (caramba...@googlemail.com) replied: Hello, I am using a System based on FreeBSD 6.3. On this System an automatically generated ntpd.conf file is generated in order to synchronize the System clock with a NTP Server. I want to use a Windows 2003 or 2008 Server to act as the NTP Server. On the Windows System the NTP Server (Windows Time Service) is *correctly* running. The thing is that even if there are NTP traffic between the client and the Server (NTP Client and Server IP packet), My FreeBSD is not synchronizing at all: freebsd-clientntpq -p 127.0.0.1 remote refid st t when poll reach delay offset jitter === NTP_server 192.168.10.6 2 u 103 102411.037 -587367 0.002 As you can see the offset is huge and never decreases as in a normal way... My ntpd.conf file looks like: --- # File is automatically generated # Do not edit tinker panic 1 tinker step 1 # ntp servers list server 172.30.1.5 # files informations driftfile /etc/ntp.drift # restriction informations restrict default ignore # do not allow request by default restrict 127.0.0.1 # allow localhost for debugging restrict 172.30.1.5 nomodify my ntp.drift file -101.101 I know that maybe the Microsoft NTP/SNTP implementation is not RFC-compliant, but is there a way to configure my NTP client in a more compatible (less strict) way to adjust its time with a Windows Server? You might want to check out these two URL's for starters: http://lists.ntp.isc.org/pipermail/questions/2007-January/012469.html http://msdn.microsoft.com/en-us/library/ms884917.aspx -- Jerry ges...@yahoo.com My folks didn't come over on the Mayflower, but they were there to meet the boat. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
Jacques Henry wrote: Hello, I am using a System based on FreeBSD 6.3. On this System an automatically generated ntpd.conf file is generated in order to synchronize the System clock with a NTP Server. I want to use a Windows 2003 or 2008 Server to act as the NTP Server. On the Windows System the NTP Server (Windows Time Service) is *correctly* running. The thing is that even if there are NTP traffic between the client and the Server (NTP Client and Server IP packet), My FreeBSD is not synchronizing at all: freebsd-clientntpq -p 127.0.0.1 remote refid st t when poll reach delay offset jitter === NTP_server 192.168.10.6 2 u 103 102411.037 -587367 0.002 As you can see the offset is huge and never decreases as in a normal way... My ntpd.conf file looks like: --- # File is automatically generated # Do not edit tinker panic 1 tinker step 1 My man page for ntp.conf clearly states in regards to the tinker command: The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. In general, they interact in intricate ways that are hard to predict and some combinations can result in some very nasty behavior. Very rarely is it necessary to change the default values; but, some folks cannot resist twisting the knobs anyway and this com- mand is for them. Emphasis added: twisters are on their own and can expect no help from the support group. so the very first thing you might want to try is to comment out the tinker commands, in particular the panic one. I'm not sure that after you set the panic threshold to 1 second you should expect your ntpd to pay any attention to servers with an offset of 587 seconds. If that fails, consider setting ntpdate_enable=YES ntpdate_hosts=NTP_server in your /etc/rc.conf and simply stepping to the correct time at boot time. In short, I don't think this has anything with a Windows server being involved, and everything to do with starting off almost 10 minutes off and a config file that says to never make a step correction larger than 1 second and to panic if you see an offset of over 1 second. -- --Jon Radel j...@radel.com smime.p7s Description: S/MIME Cryptographic Signature
Re: NTP Client synchronization with a Windows 2003/2008
2009/10/13 Jacques Henry caramba...@googlemail.com Hello, I am using a System based on FreeBSD 6.3. On this System an automatically generated ntpd.conf file is generated in order to synchronize the System clock with a NTP Server. I want to use a Windows 2003 or 2008 Server to act as the NTP Server. On the Windows System the NTP Server (Windows Time Service) is *correctly* running. The thing is that even if there are NTP traffic between the client and the Server (NTP Client and Server IP packet), My FreeBSD is not synchronizing at all: freebsd-clientntpq -p 127.0.0.1 remote refid st t when poll reach delay offset jitter === NTP_server 192.168.10.6 2 u 103 102411.037 -587367 0.002 As you can see the offset is huge and never decreases as in a normal way... My ntpd.conf file looks like: --- # File is automatically generated # Do not edit tinker panic 1 tinker step 1 # ntp servers list server 172.30.1.5 # files informations driftfile /etc/ntp.drift # restriction informations restrict default ignore # do not allow request by default restrict 127.0.0.1 # allow localhost for debugging restrict 172.30.1.5 nomodify my ntp.drift file -101.101 I know that maybe the Microsoft NTP/SNTP implementation is not RFC-compliant, but is there a way to configure my NTP client in a more compatible (less strict) way to adjust its time with a Windows Server? Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ntpd wont resync if the time difference is to big, as it assumes something is wrong as you would have set the system clock roughly correct. To fix stop ntpd, then do an ntpdate against the server. This should set the time. Now run ntpd again also set the following variables to a server of your choosing to make sure ntpdate is run 1st on boot $ grep ntp /etc/rc.conf* /etc/rc.conf:ntpdate_flags=uk.pool.ntp.org /etc/rc.conf:ntpdate_enable=YES /etc/rc.conf:ntpd_enable=YES ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: NTP Client synchronization with a Windows 2003/2008
ntpd wont resync if the time difference is to big, as it assumes something is wrong as you would have set the system clock roughly correct. To fix stop ntpd, then do an ntpdate against the server. This should set the time. Now run ntpd again also set the following variables to a server of your choosing to make sure ntpdate is run 1st on boot $ grep ntp /etc/rc.conf* /etc/rc.conf:ntpdate_flags=uk.pool.ntp.org /etc/rc.conf:ntpdate_enable=YES /etc/rc.conf:ntpd_enable=YES I cannot do that because I have no Internet access... so the very first thing you might want to try is to comment out the tinker commands, in particular the panic one. I'm not sure that after you set the panic threshold to 1 second you should expect your ntpd to pay any attention to servers with an offset of 587 seconds. If that fails, consider setting ntpdate_enable=YES ntpdate_hosts=NTP_server in your /etc/rc.conf and simply stepping to the correct time at boot time. In short, I don't think this has anything with a Windows server being involved, and everything to do with starting off almost 10 minutes off and a config file that says to never make a step correction larger than 1 second and to panic if you see an offset of over 1 second. I commented the commands involved and nothing changed... (with only 10 minutes of time difference) I even tried to force the sync: U450XA0A0800650nstop ntp U450XA0A0800650ntpd -x -n -q -c /var/ntp.conf U450XA0A0800650nstart ntp In fact I am still quite convinced that the MS implementation isn't totally compliant with the client... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
Jacques Henry wrote: I commented the commands involved and nothing changed... (with only 10 minutes of time difference) The 19 minutes between when I sent my suggestions and you responded is hardly enough time to see if ntpd was slewing the time. Slewing 587 seconds takes days. I even tried to force the sync: U450XA0A0800650nstop ntp U450XA0A0800650ntpd -x -n -q -c /var/ntp.conf U450XA0A0800650nstart ntp Are you sure that -x in there, telling ntpd to not step unless the offset is over 600 sec, doesn't override what you're trying to do with the -q? How about you try simple: ntpdate the_windows_server and see what that does? After that look in /var/log/messages. In fact I am still quite convinced that the MS implementation isn't totally compliant with the client... Could be, but ntpq was showing that your ntpd was accepting time data from the Windows server at least on some level. -- --Jon Radel j...@radel.com smime.p7s Description: S/MIME Cryptographic Signature
