Re: [ntp:questions] ntpq -p show refid as .INIT. even my NTP Servers are synchronized properly.
On Oct 5, 12:19 am, Steve Kostecke wrote: > On 2009-10-04, Andhu wrote: > > [snip: time island with primary and secondary time servers] > > > Problem: > > > When i execute ntpq -p the output shows refid as .INIT. ? > > Where are you running this command? > > It may be that you are not allowing enough time to elapse after ntpd is > started. > > For ntp-stable using ntpd's defaults a server which is using the > Undisciplined Local Clock (127.127.1.x) as its time "source" will not be > able to serve time to others until it has been running for approximately > 200 seconds (3 1/3 minutes). This time may be reduced to approximately > 50 seconds using the minpoll command. > > > How to resolve this? > > Fix your configuration and/or allow ntpd to run for a long enough time > before using 'ntpq -p'. > > > Why it is showing? > > We won't be able to tell you that until we see a sample configuration > for one of your servers and one of your clients. > > > Tell me how much time it will take to synchronize to the secondary > > server when primary goes down? > > The "client ntpd" will keep the primary server as its "sys_peer" (in > other words, will continue to be synced to the primary server) until > that primary server becomes unreachable. > > It takes a maximum of 8 polls for a time source to become unreachable. > > For unicast (or "client/server") associations, depending on the poll > interval being used by the client ntpd it will take somewhere between > 8.5 minutes and 2.27 hours for a remote time server to become > unreachable. > > -- > Steve Kostecke > NTP Public Services Project -http://support.ntp.org/ hi, When i execute ntpq -p the output shows refid as .INIT. ? Where are you running this command? I am executing this command in NTP Server and in my NTP Clients. It may be that you are not allowing enough time to elapse after ntpd is started. So you mean to say that we need to execute the command ntpq -p after the NTP server get stable? As i mentioned it was in production and these NTP Servers were running for very long time. And all my NTP Servers are getting synchronized from the Primary NTP Server. I found in some documents that this .INIT. is the kiss code error and it means that my associaition server is not synchronized for the first time. For ntp-stable using ntpd's defaults a server which is using the Undisciplined Local Clock (127.127.1.x) as its time "source" will not be able to serve time to others until it has been running for approximately 200 seconds (3 1/3 minutes). This time may be reduced to approximately 50 seconds using the minpoll command. >From the above you mean to say if the source is the Undisciplined Local Clock (127.127.1.x) it wont serve time until it has been running for 3 1/3 minutes. But my NTP Server is running for very long time. But still am getting the refid as .INIT. when i execute ntpq -p command. And regarding the time interval of ntpd client from changing the synchronization from Primary to Secondary when the primary becaome unreachable . As per you it will take maximum of 8 polls but it is taking more than 1 hours to change it secondary NTP server if the primary goes down. with regards A.Aravind ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote:
> It is an unshielded efficient radiator, the motherboard.
> Unshielded because the manufacturer does not want to spend
> the money to shield it.
Do you buy / use equipment that you have decided are the source
of objectionable levels of EMI?
If you have such equipment, what have you done to decrease
the emissions?
{Don't tell me you are complaining about it, while supporting
the manufacturers you think are behind the problem,
and doing nothing about it yourself.}
--
E-Mail Sent to this address
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
E-Mail Sent to this address will be added to the BlackLists
writes:
>Unruh wrote:
> > It is an unshielded efficient radiator, the motherboard.
> > Unshielded because the manufacturer does not want to spend
> > the money to shield it.
>Do you buy / use equipment that you have decided are the source
> of objectionable levels of EMI?
I do not have the equipment to measure the radiation given off. The
manufacturers do. If you tell me how I can get the information as to how
much it emits, I will certainly include that in my decision process.
> If you have such equipment, what have you done to decrease
> the emissions?
> {Don't tell me you are complaining about it, while supporting
> the manufacturers you think are behind the problem,
> and doing nothing about it yourself.}
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpq -p show refid as .INIT. even my NTP Servers are synchronized properly.
On 2009-10-04, Andhu wrote: [snip: time island with primary and secondary time servers] > Problem: > > When i execute ntpq -p the output shows refid as .INIT. ? Where are you running this command? It may be that you are not allowing enough time to elapse after ntpd is started. For ntp-stable using ntpd's defaults a server which is using the Undisciplined Local Clock (127.127.1.x) as its time "source" will not be able to serve time to others until it has been running for approximately 200 seconds (3 1/3 minutes). This time may be reduced to approximately 50 seconds using the minpoll command. > How to resolve this? Fix your configuration and/or allow ntpd to run for a long enough time before using 'ntpq -p'. > Why it is showing? We won't be able to tell you that until we see a sample configuration for one of your servers and one of your clients. > Tell me how much time it will take to synchronize to the secondary > server when primary goes down? The "client ntpd" will keep the primary server as its "sys_peer" (in other words, will continue to be synced to the primary server) until that primary server becomes unreachable. It takes a maximum of 8 polls for a time source to become unreachable. For unicast (or "client/server") associations, depending on the poll interval being used by the client ntpd it will take somewhere between 8.5 minutes and 2.27 hours for a remote time server to become unreachable. -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpq -p show refid as .INIT. even my NTP Servers are synchronized properly.
On Oct 4, 11:42 pm, Unruh wrote: > Andhu writes: > >hi, > >We are configured NTP in Multiple servers and all the servers are > >getting snchronized properly.We are having primary and Secondary NTP > >servers, where as primary NTP server is refering its LOCAL BIOS as > >reference clock. > > What is "local Bios"? do you mean the Real Time Clock (the little clock > chip on the motherboard)? That is likely to > out by many seconds between the various machines. Ie, ntp will find that > there there are no "true tickers" Just a random assortment of bad > clocks. > > > > >And Secondary NTP server refering Primary NTP server as reference > >clock. And other multiple NTP servers refering Primary as reference > >clock and if primary goes down they will be pointing secondary as > >reference clock automatically. > >Problem: > >When i execute ntpq -p the output shows refid as .INIT. ? > >How to resolve this? > >Why it is showing? > >Tell me how much time it will take to synchronize to the secondary > >server when primary goes down?- Hide quoted text - > > - Show quoted text - hi Unruh Thanks for your reply. Local BIOS is nothing but the Hardware clock , yes it is the Real time clock which comes in Motherboard. What is true tickers? You are saying that it is not recommend to keep the source reference clock as Real time clock? with regards aravind ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpq -p show refid as .INIT. even my NTP Servers are synchronized properly.
Andhu writes: >hi, >We are configured NTP in Multiple servers and all the servers are >getting snchronized properly.We are having primary and Secondary NTP >servers, where as primary NTP server is refering its LOCAL BIOS as >reference clock. What is "local Bios"? do you mean the Real Time Clock (the little clock chip on the motherboard)? That is likely to out by many seconds between the various machines. Ie, ntp will find that there there are no "true tickers" Just a random assortment of bad clocks. >And Secondary NTP server refering Primary NTP server as reference >clock. And other multiple NTP servers refering Primary as reference >clock and if primary goes down they will be pointing secondary as >reference clock automatically. >Problem: >When i execute ntpq -p the output shows refid as .INIT. ? >How to resolve this? >Why it is showing? >Tell me how much time it will take to synchronize to the secondary >server when primary goes down? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
John Hasler writes: >Unruh writes: >> Say you add plus or minus .5 sec at every tick. >You don't. The modulation is applied to the UHF clock source the >machine uses to generate its bus clocks. At these frequencies 10% >modulation depth will result in perhaps a few hundred nanoseconds in >uncertainty in the pulse position. This uncertainty is not magified as >the clock is divided down. >> Yes, after an hour, you will still have 3600 ticks, but when you >> measure the time at any particular point in the hour, you will never >> know the time to better than .5 sec. >More like 200 nsec. No. Because when you measure the time it is out by the amount that you jitter the time. (I assumed thatt he time jitter was .5 sec) IF you are claiming that the time jitter is 200ns then yes, the time would be out by 200ns >> And your system is till polluting the airwaves with the same amount of >> energy, only spread around slightly in frequency. >So are you by standing there giving off thermal radiation. IF the amplitude were the same as the thermal amplitude, then I would not care not would the FCC. Unfortunately it is many many many orders of magnitude higher than thermal. It is an unshielded efficient radiator, the motherboard. Unshielded because the manufacturer does not want to spend the money to shield it. >-- >John Hasler >jhas...@newsguy.com >Dancing Horse Hill >Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
I wrote: > More like 200 nsec. No, more like tens of nanoseconds at most. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] ntpq -p show refid as .INIT. even my NTP Servers are synchronized properly.
hi, We are configured NTP in Multiple servers and all the servers are getting snchronized properly.We are having primary and Secondary NTP servers, where as primary NTP server is refering its LOCAL BIOS as reference clock. And Secondary NTP server refering Primary NTP server as reference clock. And other multiple NTP servers refering Primary as reference clock and if primary goes down they will be pointing secondary as reference clock automatically. Problem: When i execute ntpq -p the output shows refid as .INIT. ? How to resolve this? Why it is showing? Tell me how much time it will take to synchronize to the secondary server when primary goes down? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh writes: > Say you add plus or minus .5 sec at every tick. You don't. The modulation is applied to the UHF clock source the machine uses to generate its bus clocks. At these frequencies 10% modulation depth will result in perhaps a few hundred nanoseconds in uncertainty in the pulse position. This uncertainty is not magified as the clock is divided down. > Yes, after an hour, you will still have 3600 ticks, but when you > measure the time at any particular point in the hour, you will never > know the time to better than .5 sec. More like 200 nsec. > And your system is till polluting the airwaves with the same amount of > energy, only spread around slightly in frequency. So are you by standing there giving off thermal radiation. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Rob writes: >Richard B. Gilbert wrote: >> Unruh wrote: >>> Steve Kostecke writes: >>> On 2009-10-03, Rob wrote: >>> > It is worse when you start to twiddle the config and shutdown/restart > ntpd often. Then it can take a very long time before it becomes stable > again. >>> In my experience with ntpd "warm restarts" have never been a problem. >>> YMMV >>> > It seems that the official standpoint is to ignore or deny these problems, > but that doesn't mean they cease to exist. >>> There is no policy of denial. >>> >>> There have been extensive discussions on the slow convergence of ntp, >>> and David Mills has been adamant that the current algorithm will not >>> change, and that the slow convergence is a feature that will also not >>> change. It is I agree not a policy of denial. It is a policy of "that's >>> not a bug, its a feature". >>> >> >> It's a feature! Learn to live with it or write your own NTPD. Dr. >> Mills is unlikely to change his mind! Chrony and perhaps other products >> may come closer to meeting your requirements. >My statement "It seems that the official standpoint is to ignore or deny >these problems" was meant to point in this direction, but apparently my >bad English idiom was again misunderstood. >> One relatively easy solution is to keep NTPD running 24x7. If you can't >> or won't do that, NTPD is a poor choice for your requirements! >I am talking about problems at startup time. Even when you keep NTPD >running 24x7 you have to start it at some time. That is not a smooth >operation. But that problem is denied or ignored. No. ntp stores the current drift rate in a file. It also assumes that there is a mechanism to flywheel the time ( a "real time clock") so that when it is restarted, it has a good idea of what the time is and what the drift rate is. The problems arise if either of these mechanism do not work. If the system has no on board rtc, then ntp can use the ntpd -g mechanism to rapidly get the right time set. If you have to drift file, it tries to rapidly get an idea of the drift. But if you hava a drift file and for some reason the real drift is different ( eg the Linux calibration problems) then ntp behaves very badly. (it also behaves badly if during the running the drift rate changes eg because the computer heats up due to heavy use). Thus on systems where the drift rate is stable over reboots ( to less than a PPM) ntpd behaves well even over restarts. On systems where that is not true, it behaves badly (ie slowly). If the true drift is out by say 50-100PPM and one has a large poll interval ( eg 6 or higher) it can easily approach or even exceed the 500PPM limit on the drift rate and go a bit crazy, or shut itself down. This is a problem with recent linux kernels where the drift rate can fluctuate by 50-100PPM over reboots. Note that the problem is not denied or ignored. It is stated that ntp needs time to settle down, and you should run ntp continuously. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
"Maarten Wiltink" writes: >"Unruh" wrote in message >news:6rmxm.46378$db2.43...@edtnps83... >> "Maarten Wiltink" writes: >>> "Unruh" wrote in message >>> news:k8yxm.46291$db2.44...@edtnps83... No idea what "spread spectrum " means for a clock. >> >>> That there is a certain jitter explicitly introduced in its >>> effective frequency. Probably in the form of a random offset, >>> that averages to zero, to every tick, so you're certain that >>> the long-term frequency doesn't change. >> >> I am afraid I am left as confused as before. HOw introducing random >> offsets would stop the frequency from changing I have no idea. >Say you have a clock running at 1 Hz. One tick per second. Naively, >you might "spread its spectrum" by changing the frequency. Let it >run at 0.5 Hz some seconds, 1.5 Hz some others. That's two ticks >some seconds, two thirds of one others. The average frequency works >out to 0.75 Hz. Not what you want. >Alternatively, instead of ticking at the top of every second, add >a random offset to the time when every tick happens. After an hour, >there will have been 3,600 ticks. Still 1 Hz. >> It sounds like a terrible idea, but that may be ignorance. >If you want the best clock possible, it is. But that's not the only >consideration. Say you add plus or minus .5 sec at every tick. Yes, after an hour, you will still have 3600 ticks, but when you measure the time at any particular point in the hour, you will never know the time to better than .5 sec. This will set an ultimate limit on the accuracy of your clock. All to save a few cents in copper to shield your system properly. And your system is till polluting the airwaves with the same amount of energy, only spread around slightly in frequency. >Groetjes, >Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote: > David Lord writes: > > >> I've started replacing ntpd on desktops and notebooks as it's not >> really appropriate and "ntpd -q" or ntpdate would be sufficient. >> It's just that ntpd was installed by default. Using "ntpd -q" before >> starting chrony seems to give good results. > > Why would that do anything? Chrony itself has an option to step the > clock on startup if the offset is too large ( user selectable-- if you > want to select .128 sec, that is fine) This is just for when using mobile broadband where there is massive latency and switching between GSM modes at start of connections. Ntp.conf with burst (from my own servers) gets initially to within about 20ms but without burst around 100ms at best and more often 1-2s. Desktops on wired network don't really need it but are sometimes connected by mobile so I've kept the same method. Chrony does have a burst option but this has to be called on demand using chronyc and I've not got round to trying that, but if it works ok I'll move to using that. When/if I can get a portable radioclock sorted that should be a better solution. David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
"Unruh" wrote in message news:6rmxm.46378$db2.43...@edtnps83... > "Maarten Wiltink" writes: >> "Unruh" wrote in message >> news:k8yxm.46291$db2.44...@edtnps83... >>> No idea what "spread spectrum " means for a clock. > >> That there is a certain jitter explicitly introduced in its >> effective frequency. Probably in the form of a random offset, >> that averages to zero, to every tick, so you're certain that >> the long-term frequency doesn't change. > > I am afraid I am left as confused as before. HOw introducing random > offsets would stop the frequency from changing I have no idea. Say you have a clock running at 1 Hz. One tick per second. Naively, you might "spread its spectrum" by changing the frequency. Let it run at 0.5 Hz some seconds, 1.5 Hz some others. That's two ticks some seconds, two thirds of one others. The average frequency works out to 0.75 Hz. Not what you want. Alternatively, instead of ticking at the top of every second, add a random offset to the time when every tick happens. After an hour, there will have been 3,600 ticks. Still 1 Hz. > It sounds like a terrible idea, but that may be ignorance. If you want the best clock possible, it is. But that's not the only consideration. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Richard B. Gilbert wrote: > Unruh wrote: >> Steve Kostecke writes: >> >>> On 2009-10-03, Rob wrote: >> It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. >> >>> In my experience with ntpd "warm restarts" have never been a problem. >> >>> YMMV >> It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. >> >>> There is no policy of denial. >> >> There have been extensive discussions on the slow convergence of ntp, >> and David Mills has been adamant that the current algorithm will not >> change, and that the slow convergence is a feature that will also not >> change. It is I agree not a policy of denial. It is a policy of "that's >> not a bug, its a feature". >> > > It's a feature! Learn to live with it or write your own NTPD. Dr. > Mills is unlikely to change his mind! Chrony and perhaps other products > may come closer to meeting your requirements. My statement "It seems that the official standpoint is to ignore or deny these problems" was meant to point in this direction, but apparently my bad English idiom was again misunderstood. > One relatively easy solution is to keep NTPD running 24x7. If you can't > or won't do that, NTPD is a poor choice for your requirements! I am talking about problems at startup time. Even when you keep NTPD running 24x7 you have to start it at some time. That is not a smooth operation. But that problem is denied or ignored. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
"Richard B. Gilbert" writes: >Unruh wrote: >> Steve Kostecke writes: >> >>> On 2009-10-03, Rob wrote: >> It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. >> >>> In my experience with ntpd "warm restarts" have never been a problem. >> >>> YMMV >> It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. >> >>> There is no policy of denial. >> >> There have been extensive discussions on the slow convergence of ntp, >> and David Mills has been adamant that the current algorithm will not >> change, and that the slow convergence is a feature that will also not >> change. It is I agree not a policy of denial. It is a policy of "that's >> not a bug, its a feature". >> >It's a feature! Learn to live with it or write your own NTPD. Dr. >Mills is unlikely to change his mind! Chrony and perhaps other products >may come closer to meeting your requirements. Well, some might feel that the purpose of this discussion group it to improve ntp. I believe it is that slow response which results in ntp being a factor or 2-3 (or more) worse than chrony at disciplining the clock of a computer. Of course, if one does not care how well ntp works, then poor performance is irrelevant-- it is a feature, not a bug. I do agree that the slow response is a direct result of the ntp algorithm and that Mills is not liable to change that. He has stated that he does not care if it has slow response. >One relatively easy solution is to keep NTPD running 24x7. If you can't >or won't do that, NTPD is a poor choice for your requirements! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
