[ntp:questions] NTP client configuration
Hello, We are using Meindberg NTP client and server. Our configuration is: - 1 Computer under windows that is server server 127.127.1.0 broadcast 192.168.2.255 minpoll 4 maxpoll 4 iburst disable auth - several computer under linux + computers under windows, client of this server: server 192.168.2.250 minpoll 4 maxpoll 4 iburst broadcastclient disable auth My problem is the following: Mainly on windows computer, sometime, depending what the computer is doing, there is a big offset between clients and server. (Big for me is more than 500ms). I would like to know if it is possible to setup client so as soon as he see offset500ms, then client do a fast synch. (STEP). Another way to solve my problem could be for me, to modify the source code of my application in order to get this offset information inside my code (C or C++ langage). then I could add this offset to the time of the computer in order to be as much accurate as possible during the time the offset is bigger than 500ms. Do you have any solution? Regards. B CABUT -- CABUT Benjamin CEO - president RSA Cosmos ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
On 27/09/2012 07:08, Benjamin CABUT wrote: Hello, We are using Meindberg NTP client and server. Our configuration is: - 1 Computer under windows that is server server 127.127.1.0 broadcast 192.168.2.255 minpoll 4 maxpoll 4 iburst disable auth - several computer under linux + computers under windows, client of this server: server 192.168.2.250 minpoll 4 maxpoll 4 iburst broadcastclient disable auth My problem is the following: Mainly on windows computer, sometime, depending what the computer is doing, there is a big offset between clients and server. (Big for me is more than 500ms). I would like to know if it is possible to setup client so as soon as he see offset500ms, then client do a fast synch. (STEP). Another way to solve my problem could be for me, to modify the source code of my application in order to get this offset information inside my code (C or C++ langage). then I could add this offset to the time of the computer in order to be as much accurate as possible during the time the offset is bigger than 500ms. Do you have any solution? Regards. B CABUT I haven't used broadcast or auth, so I don't know if that affects things. My understanding of NTP was that unless you configure it otherwise, an offset exceeding 128 milliseconds would force NTP to step the PC's clock rather than changing the rate, so I am surprised you are seeing 500 ms offsets. I'm using NTP 4.2.7p285 (updated from the Meinberg installation) and seeing offsets in the millisecond range (except on a couple of PCs where it's the few milliseconds range). This is with three local PCs as stratum-1 servers, with a GPS reference. See: http://www.satsignal.eu/mrtg/performance_ntp.php I would not recommend using the local clock, and if you need an isolated network I suggest looking into orphan mode (about which I know nothing). 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] NTP client configuration
David Taylor wrote: I haven't used broadcast or auth, so I don't know if that affects things. My understanding of NTP was that unless you configure it otherwise, an offset exceeding 128 milliseconds would force NTP to step the PC's clock rather than changing the rate, so I am surprised you are seeing 500 ms offsets. ntpd will wait a considerable amount of time before accepting that the time it has really is broken. That I think is the issue here. There is a tinker option which will reduce that. However the fundamental problem is that NTP is intended to be used with time sources that behave like UTC, with the only perturbations being those due to variations in network delays, etc. The OP is asking the system to work with a fundamentally broken time source. To get anything like that to work, he is going to have to tune things a very long way from their best practice settings, and accept that the ability to do so is not part of the core requirements for ntpd. The best solution is to fix the time source, but I suspect there is some reason why that is not an option. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
On 2012-09-27, Benjamin CABUT benjamin.ca...@rsacosmos.com wrote: Hello, We are using Meindberg NTP client and server. Our configuration is: - 1 Computer under windows that is server server 127.127.1.0 Why would you be using a windows machine as your server. Windows is not a great platform for time. And why in the worl would you have it be using the local refclock. That should never be used. Where in the world is that computer getting its time from? broadcast 192.168.2.255 minpoll 4 maxpoll 4 iburst disable auth - several computer under linux + computers under windows, client of this server: server 192.168.2.250 minpoll 4 maxpoll 4 iburst broadcastclient disable auth My problem is the following: Mainly on windows computer, sometime, depending what the computer is doing, there is a big offset between clients and server. (Big for me is more than 500ms). I would like to know if it is possible to setup client so as soon as he see offset500ms, then client do a fast synch. (STEP). If ntpd sees an offset of 128ms and it believes this is a valid offset, it steps. Another way to solve my problem could be for me, to modify the source code of my application in order to get this offset information inside my code (C or C++ langage). then I could add this offset to the time of the computer in order to be as much accurate as possible during the time the offset is bigger than 500ms. ntpd does its best to get a small offset. What makes yo uthing your C program can do better? You have other problems. Worry about them, not about rewriting ntpd. Do you have any solution? Regards. B CABUT ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
Hello David, - our time source is the local clock of one computer. wich I guess is accurate. I mean, we don't need to get the correct time in our application, but we need that all computers shares the same time even if it wrong compared to UTC. - you are right our problem is that ntpd takes time before accepting time is broken, and during all this time our software do not work well BUT I don't think the problem wome from the server (local clock). Because the problem happen on one client only, when this client computer is doing some action that I guess are making trouble to ntp. Actualy my computer is playing audiofiles throught a special audio board. I don't know why it affect ntp client, but it does I also have a problem when we start the computers in the morning, in this case the server need some time to accept client request + client need time to adjust there clock. What I was wondering, is how Meinberg Time Server Monitor is doing to know the offset (ntpq is also getting this information). If i could have a way to get this in C source code, then I will handle easily this issue. Do you know how I can proceed to get offset value in a source code? Regards. Benjamin Le 27/09/2012 19:57, David Woolley a écrit : David Taylor wrote: I haven't used broadcast or auth, so I don't know if that affects things. My understanding of NTP was that unless you configure it otherwise, an offset exceeding 128 milliseconds would force NTP to step the PC's clock rather than changing the rate, so I am surprised you are seeing 500 ms offsets. ntpd will wait a considerable amount of time before accepting that the time it has really is broken. That I think is the issue here. There is a tinker option which will reduce that. However the fundamental problem is that NTP is intended to be used with time sources that behave like UTC, with the only perturbations being those due to variations in network delays, etc. The OP is asking the system to work with a fundamentally broken time source. To get anything like that to work, he is going to have to tune things a very long way from their best practice settings, and accept that the ability to do so is not part of the core requirements for ntpd. The best solution is to fix the time source, but I suspect there is some reason why that is not an option. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- CABUT Benjamin CEO - president RSA Cosmos ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
On 27/09/2012 19:59, Benjamin CABUT wrote: Hello David, - our time source is the local clock of one computer. wich I guess is accurate. I mean, we don't need to get the correct time in our application, but we need that all computers shares the same time even if it wrong compared to UTC. - you are right our problem is that ntpd takes time before accepting time is broken, and during all this time our software do not work well BUT I don't think the problem wome from the server (local clock). Because the problem happen on one client only, when this client computer is doing some action that I guess are making trouble to ntp. Actualy my computer is playing audiofiles throught a special audio board. I don't know why it affect ntp client, but it does I also have a problem when we start the computers in the morning, in this case the server need some time to accept client request + client need time to adjust there clock. What I was wondering, is how Meinberg Time Server Monitor is doing to know the offset (ntpq is also getting this information). If i could have a way to get this in C source code, then I will handle easily this issue. Do you know how I can proceed to get offset value in a source code? Regards. Benjamin = Be aware that enabling and disabling the Multi-Media timer on Windows can lead to time steps in the order of tens of milliseconds. Best to keep the MM timer running by configuring NTP appropriately. NTP works best when kept running 24 x 7. In your case, I would now suggest getting a low-powered PC (e.g. Intel Atom) and leave that running 24 x 7 with a GPS reference clock such as the Garmin GPS 18x LVC or Sure Electronics board, as mentioned on my Web site. Given that you get an extra PC, run FreeBSD on it rather than Windows. 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] NTP client configuration
On 27/09/2012 19:39, unruh wrote: On 2012-09-27, Benjamin CABUT benjamin.ca...@rsacosmos.com wrote: Hello, We are using Meindberg NTP client and server. Our configuration is: - 1 Computer under windows that is server server 127.127.1.0 Why would you be using a windows machine as your server. Windows is not a great platform for time. And why in the worl would you have it be using the local refclock. That should never be used. Where in the world is that computer getting its time from? [] Agreed on the local clock. Windows-7 with a GPS reference clock can be well within 100 microseconds, see PCs Alta and Stamsund here: http://www.satsignal.eu/mrtg/performance_ntp.php 100 microseconds may well be quite good enough for the particular application, and if a Windows PC is available, why not use it? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
On 9/27/2012 2:59 PM, Benjamin CABUT wrote: Hello, I don't car in my application to have the correct UTC time. What I care is that all my computers share exactly the same time. Our application is not connected to internet. So only time I can use as a reference is local clock of one computer. It's difficult to get multiple devices to keep a common time without a stable reference clock. I'd suggest using a GPS timing receiver. It will give you a rock solid one second per second beat that most computers can synchronize with. NTPD needs about ten hours to synchronize its host down to the nano-second level. Once synchronized it should stay synchronized. If you need to turn everything off at 5:00 PM and turn it on again at 9:00 AM, NTP is a poor choice. I can realy tell you that my client is not sync some times! it happen in 2 ways: - when I start my computers, it need arround 5 minutes to be sync, it is a problem for me - when one computer has heavy operation to do, then ntp client desync and I have offset that can be 2 seconds, and stay like this during sereval minutes. so It realy need a long time to ntp client to detect the big desync. I do not want to rewrite ntp. ntpq gives the offset between clock of client and clock of server. As you say the best way for me is that ntp is working perfectly, but it is not the case. I don't know how to improve this by configuration. So I was just wondering if I could get the offset in my software to solve my problem... Regards. snip ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
On 2012-09-27, Benjamin CABUT benjamin.ca...@rsacosmos.com wrote: Hello, I don't car in my application to have the correct UTC time. What I care is that all my computers share exactly the same time. Our application is not connected to internet. So only time I can use as a reference is local clock of one computer. OK, look up orphan mode. But again why are you suing a windows machine as your reference? Windows is not known for its timekeeping ability. Use for example one of your Linux machines instead. I can realy tell you that my client is not sync some times! it happen in 2 ways: - when I start my computers, it need arround 5 minutes to be sync, it is a problem for me ntpd is NOT designed for rapid convergence. 5 min is very fast as far as ntpd is concerned. - when one computer has heavy operation to do, then ntp client desync What do you mean when one computer? The server? a client? And what is a heavy operation? and I have offset that can be 2 seconds, and stay like this during sereval minutes. You have other problems. ntpd is NOT designed to correct clocks which jump around by seconds. You need to get your clocks to behave themselves first so that their time does not jump around. so It realy need a long time to ntp client to detect the big desync. I do not want to rewrite ntp. ntpq gives the offset between clock of client and clock of server. As you say the best way for me is that ntp is working perfectly, but it is not the case. Your idea and Mill's idea of working perfectly is different. He designed it so that it will correct clocks which run stably (loess than say 100PPM rate error always). It is NOT designed to hadle clocks whose rates can vary by more than that, or whose time can jump around. chrony (sorry does not run on Windows) does a bit better but again it would have trouble with your clocks as well. I don't know how to improve this by configuration. Depends on what you mean by improved. So I was just wondering if I could get the offset in my software to solve my problem... I think you need to figure out what your problem is first. Regards. Le 27/09/2012 20:39, unruh a ?crit : On 2012-09-27, Benjamin CABUT benjamin.ca...@rsacosmos.com wrote: Hello, We are using Meindberg NTP client and server. Our configuration is: - 1 Computer under windows that is server server 127.127.1.0 Why would you be using a windows machine as your server. Windows is not a great platform for time. And why in the worl would you have it be using the local refclock. That should never be used. Where in the world is that computer getting its time from? broadcast 192.168.2.255 minpoll 4 maxpoll 4 iburst disable auth - several computer under linux + computers under windows, client of this server: server 192.168.2.250 minpoll 4 maxpoll 4 iburst broadcastclient disable auth My problem is the following: Mainly on windows computer, sometime, depending what the computer is doing, there is a big offset between clients and server. (Big for me is more than 500ms). I would like to know if it is possible to setup client so as soon as he see offset500ms, then client do a fast synch. (STEP). If ntpd sees an offset of 128ms and it believes this is a valid offset, it steps. Another way to solve my problem could be for me, to modify the source code of my application in order to get this offset information inside my code (C or C++ langage). then I could add this offset to the time of the computer in order to be as much accurate as possible during the time the offset is bigger than 500ms. ntpd does its best to get a small offset. What makes yo uthing your C program can do better? You have other problems. Worry about them, not about rewriting ntpd. Do you have any solution? Regards. B CABUT ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
Benjamin CABUT wrote: Because the problem happen on one client only, when this client computer is doing some action that I guess are making trouble to ntp. Actualy my computer is playing audiofiles throught a special audio board. I don't know why it affect ntp client, but it does OK, The problem is on the client, not the server. I guess you have something that is locking out interrupts for so long that it loses clock ticks (the errors will always be negative). That represents a poor device driver or inadequate hardware. ntpd is not designed for working round software clock implementations that are broken, although by setting fast polling, setting the tinker option for a short confirmation interval, and setting the offset after which it will step low, you might coax it to tolerate the problem a bit better. (Setting the poll interval low will give poor frequency stability.) By the way, your subject isn't close to summarising the real question and Meinberg don't do an ntpd implementation, they simply provide a Windows installer for the University of Delaware (the Reference) version. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
Ben, you have not yet stated what OS you are using. I think we need to know the flavour of windows you are using. If I read the mail thread, I see you have the following issues... 1. You have a problem with startup being too slow to achieve acceptable synchronisation. 2. Your windows boxes sometimes drift off a long way compared to the server. 3. You are now looking to patch up a poorly designed framework with software hacks to step the clocks back into alignment rather than fix the root cause of your troubles. My advice would be as follows... A. Decide what your startup AND synch criteria are (and let us know). If it cannot be met, you are wasting your time with NTP, and need to look elsewhere. B. Forget using localhost as a time source. More trouble than it is worth. C. Get a stable time source for your server. If you have internet, use it. If not, get a GPS based server and use it. As a rough guide, A Windows server will give you milliseconds quality reference clock. A Linux box will give you a Microseconds quality reference clock. D. Sort out your client PC's install of NTP. They are clearly not well installed or configured at this time. E. Monitor your client PC's (and indeed the server PC) over both the long term (days) and short term (minutes) to confirm both the startup time from boot and the stability are acceptable under regular use. Apologies if this is a little prescriptive and blunt (in my defence, I am a Yorkshireman), but we are a windows shop and have great success with ntp. regards pk -Original Message- From: questions-bounces+p.kennedy=fugro.com...@lists.ntp.org [mailto:questions-bounces+p.kennedy=fugro.com...@lists.ntp.org] On Behalf Of unruh Sent: Friday, 28 September 2012 5:20 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] NTP client configuration On 2012-09-27, Benjamin CABUT benjamin.ca...@rsacosmos.com wrote: Hello, I don't car in my application to have the correct UTC time. What I care is that all my computers share exactly the same time. Our application is not connected to internet. So only time I can use as a reference is local clock of one computer. OK, look up orphan mode. But again why are you suing a windows machine as your reference? Windows is not known for its timekeeping ability. Use for example one of your Linux machines instead. I can realy tell you that my client is not sync some times! it happen in 2 ways: - when I start my computers, it need arround 5 minutes to be sync, it is a problem for me ntpd is NOT designed for rapid convergence. 5 min is very fast as far as ntpd is concerned. - when one computer has heavy operation to do, then ntp client desync What do you mean when one computer? The server? a client? And what is a heavy operation? and I have offset that can be 2 seconds, and stay like this during sereval minutes. You have other problems. ntpd is NOT designed to correct clocks which jump around by seconds. You need to get your clocks to behave themselves first so that their time does not jump around. so It realy need a long time to ntp client to detect the big desync. I do not want to rewrite ntp. ntpq gives the offset between clock of client and clock of server. As you say the best way for me is that ntp is working perfectly, but it is not the case. Your idea and Mill's idea of working perfectly is different. He designed it so that it will correct clocks which run stably (loess than say 100PPM rate error always). It is NOT designed to hadle clocks whose rates can vary by more than that, or whose time can jump around. chrony (sorry does not run on Windows) does a bit better but again it would have trouble with your clocks as well. I don't know how to improve this by configuration. Depends on what you mean by improved. So I was just wondering if I could get the offset in my software to solve my problem... I think you need to figure out what your problem is first. Regards. Le 27/09/2012 20:39, unruh a ?crit : On 2012-09-27, Benjamin CABUT benjamin.ca...@rsacosmos.com wrote: Hello, We are using Meindberg NTP client and server. Our configuration is: - 1 Computer under windows that is server server 127.127.1.0 Why would you be using a windows machine as your server. Windows is not a great platform for time. And why in the worl would you have it be using the local refclock. That should never be used. Where in the world is that computer getting its time from? broadcast 192.168.2.255 minpoll 4 maxpoll 4 iburst disable auth - several computer under linux + computers under windows, client of this server: server 192.168.2.250 minpoll 4 maxpoll 4 iburst broadcastclient disable auth My problem is the following: Mainly on windows computer, sometime, depending what the computer is doing, there is a big offset between clients and server. (Big for me is more than 500ms). I would like to know if it is possible to setup client so as soon as he
Re: [ntp:questions] NTP client configuration
Benjamin CABUT wrote: - our time source is the local clock of one computer. wich I guess is accurate. Probably not. I mean, we don't need to get the correct time in our application, but we need that all computers shares the same time even if it wrong compared to UTC. You might be able to get get what you want by using orphan mode instead of localclock; and messing with the e.g. ntp conf tos and tinker options to deal with your unstable timebases. Do you know how I can proceed to get offset value in a source code? Pick your poison. http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ I'd probably first look at the source code: ntp-dev-4.2.7p306/ntpq and/or ntp-dev-4.2.7p306/sntp FYI: Lots applications use NTPq to get that kind of information for them. -- 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] NTP client configuration
I have 4 Windows client computers who get their time from a Windows Server 2003 machine, which in turn gets its time from 9 Stratum 2 servers, all but one within 150 miles. The clients easily experience offsets within +- 6 ms, except when I download a large file. In that case the offset immediately goes up to 300 ms or more, says steady for the duration of the download, and then declines to -300 ms, or vice versa; I don't remember exactly. The time offset will also occasionally become large when the ISP's router becomes congested, say when half a dozen neighbors are all downloading movies. The surprising result is how quickly the clients recover the correct time: within a minute or two. I don't understand why you need the broadcast mode. It seems to me that NTPD is optimized for the client/server configuration. If you really want accurate time, the server should be synchronized to a local time source, such as a GPS clock. Charles Elliott -Original Message- From: questions-bounces+elliott.ch=verizon@lists.ntp.org [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of David Taylor Sent: Thursday, September 27, 2012 10:47 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] NTP client configuration On 27/09/2012 07:08, Benjamin CABUT wrote: Hello, We are using Meindberg NTP client and server. Our configuration is: - 1 Computer under windows that is server server 127.127.1.0 broadcast 192.168.2.255 minpoll 4 maxpoll 4 iburst disable auth - several computer under linux + computers under windows, client of this server: server 192.168.2.250 minpoll 4 maxpoll 4 iburst broadcastclient disable auth My problem is the following: Mainly on windows computer, sometime, depending what the computer is doing, there is a big offset between clients and server. (Big for me is more than 500ms). I would like to know if it is possible to setup client so as soon as he see offset500ms, then client do a fast synch. (STEP). Another way to solve my problem could be for me, to modify the source code of my application in order to get this offset information inside my code (C or C++ langage). then I could add this offset to the time of the computer in order to be as much accurate as possible during the time the offset is bigger than 500ms. Do you have any solution? Regards. B CABUT I haven't used broadcast or auth, so I don't know if that affects things. My understanding of NTP was that unless you configure it otherwise, an offset exceeding 128 milliseconds would force NTP to step the PC's clock rather than changing the rate, so I am surprised you are seeing 500 ms offsets. I'm using NTP 4.2.7p285 (updated from the Meinberg installation) and seeing offsets in the millisecond range (except on a couple of PCs where it's the few milliseconds range). This is with three local PCs as stratum-1 servers, with a GPS reference. See: http://www.satsignal.eu/mrtg/performance_ntp.php I would not recommend using the local clock, and if you need an isolated network I suggest looking into orphan mode (about which I know nothing). Cheers, David -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client configuration
On 2012-09-27, Benjamin CABUT benjamin.ca...@rsacosmos.com wrote: - our time source is the local clock of one computer. wich I guess is accurate. I mean, we don't need to get the correct time in our application, but we need that all computers shares the same time even if it wrong compared to UTC. This is a common fallacy. A cluster of ntpds which do not have access to a stable time reference can only chase a moving target. So those clocks can not be brought into tight synchronization. UTC is a ubiquitous stable time reference which can be inexpensively acquired from high quality time sources via the public Internet, timing GPS receivers and other radio clocks, or even modem dial-up. As a side effect of using a UTC source your clocks will be set to the correct time. And there is something to be said for having log and transaction time stamps correlate with reality. - you are right our problem is that ntpd takes time before accepting time is broken, and during all this time our software do not work well Then you should not start your software until the clocks are close enough. BUT I don't think the problem wome from the server (local clock). Because the problem happen on one client only, when this client computer is doing some action that I guess are making trouble to ntp. Actualy my computer is playing audiofiles throught a special audio board. I don't know why it affect ntp client, but it does... If this client is one of the systems running your time sensitive software why are you running (non-essential?) tasks which are known to cause a problem? I also have a problem when we start the computers in the morning, in this case the server need some time to accept client request + client need time to adjust there clock. Actually the issue is that the client will not accept the server's responses until the server declares that it is synced. If your server is configured with the Undisciplined Local Clock 127.127.1.x (aka LOCAL) you can reduce the initial sync time by setting minpoll to the lowest possible value. You should be able to reduce the server's initial self-sync time to about 60 seconds. If your server is configure with Orphan Mode then it will self-sync almost immediately. The clients should all be configured with iburst becuase it will reduce their initial sync time to ~20 seconds. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
