Re: [ntp:questions] Rejecting Good Peers
Cal Webster [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] I haven't restarted the servers yet in case I need to query some more info. Do you think this could be a contributing factor in this problem? If you haven't restarted the machines, that's okay. You never have to, restarting NTP is enough. If you haven't restarted the NTP daemons, they will not have the new configuration. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
Thank you for the links. I always try to use the documentation before soliciting help but it's frustrating when I can't find information on a topic that everyone seems to know about. On Wed, 2008-12-03 at 02:18 +, Harlan Stenn wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Cal Webster) writes: Cal It sure would be nice if there were more documentation about Orphan Cal mode. There is nothing in the man or info pages for any version. The Cal only scraps I could find were a short blurb on the associations page Cal at ntp.org and an archived mailing list post. Stock NTP currently ships with only HTML docs. If you want to see (or search) the docs for various versions of NTP, try http://doc.ntp.org (thanks, Steve!). I intend to have man and info pages generated for NTP as well - those efforts are described at: http://ntpforum.isc.org/bin/view/Main/ForumProject3 and http://ntpforum.isc.org/bin/view/Main/ForumProject4 If nothing happens on these projects before next summer, I'll be listing the first one as anothe GSoC project. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Wed, 2008-12-03 at 02:25 +, Steve Kostecke wrote: On 2008-12-03, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That still doesn't make sense to me. A peer is objecting to his peer using a fellow peer as a candidate? Why then does this behavior only present itself on the version 4.2.4 peer and none of the others? The difference between 4.2.4 and 4.2.0 is greater than one might be led to believe. So this is *not* a normal function of peer relationships but an anomaly caused by mixing different versions of NTP, right? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Wed, 2008-12-03 at 02:34 +, Steve Kostecke wrote: On 2008-12-02, Cal Webster [EMAIL PROTECTED] wrote: On Tue, 2008-12-02 at 21:29 +, Steve Kostecke wrote: Orphan Mode was introduced in version 4.2.2 It sure would be nice if there were more documentation about Orphan mode. The Official Distribution Documentation is maintained by one individual. And it (http://www.eecis.udel.edu/~mills/ntp/html) tracks the NTP development tree. The NTP Public Services Project operates a Distribution Documentation Archive at http://doc.ntp.org/. This archive contains frozen versions of the Distribution Documentation present in each stable release. Thank you. I'll check out the additional link. [...] The only scraps I could find were a short blurb on the associations page at ntp.org and an archived mailing list post. This is one reason why we have a Community Supported Documentation system (at http://support.ntp.org/support). Volunteers are welcome to add / correct / improve documentation. I'll be happy to contribute once I feel confident about how NTP is *supposed* to work. At this point I'm in learning mode. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Wed, 2008-12-03 at 09:08 +0100, Maarten Wiltink wrote: Cal Webster [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] I haven't restarted the servers yet in case I need to query some more info. Do you think this could be a contributing factor in this problem? If you haven't restarted the machines, that's okay. You never have to, restarting NTP is enough. If you haven't restarted the NTP daemons, they will not have the new configuration. Thank you for being specific Maarten. If I were a Linux novice that information would be very helpful. It's hard to judge skill level from a few posts. When I say servers I mean the ntpd daemons on each host. I only restart hosts for kernel updates or shutdown in case of destructive whether. :-) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
Calvin Webster said: On Wed, 2008-12-03 at 02:25 +, Steve Kostecke wrote: On 2008-12-03, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That still doesn't make sense to me. A peer is objecting to his peer using a fellow peer as a candidate? Why then does this behavior only present itself on the version 4.2.4 peer and none of the others? The difference between 4.2.4 and 4.2.0 is greater than one might be led to believe. So this is *not* a normal function of peer relationships but an anomaly caused by mixing different versions of NTP, right? No. v4.2.4 is properly detecting (and rejecting) a peer loop. v4.2.0 is not. The NTP version numbers are not the major.minor.point that most people expect. Rather they are protocol_version.major.minor with an added 'pN' for point releases. So the difference between 4.2.4 and 4.2.0 is more than a couple of point releases. It is, in fact, 2 entire development cycles. -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project http://support.ntp.org/ Public Key at http://support.ntp.org/Users/SteveKostecke ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Wed, 2008-12-03 at 09:46 -0500, Steve Kostecke wrote: Calvin Webster said: On Wed, 2008-12-03 at 02:25 +, Steve Kostecke wrote: On 2008-12-03, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That still doesn't make sense to me. A peer is objecting to his peer using a fellow peer as a candidate? Why then does this behavior only present itself on the version 4.2.4 peer and none of the others? The difference between 4.2.4 and 4.2.0 is greater than one might be led to believe. So this is *not* a normal function of peer relationships but an anomaly caused by mixing different versions of NTP, right? No. v4.2.4 is properly detecting (and rejecting) a peer loop. v4.2.0 is not. The NTP version numbers are not the major.minor.point that most people expect. Rather they are protocol_version.major.minor with an added 'pN' for point releases. So the difference between 4.2.4 and 4.2.0 is more than a couple of point releases. It is, in fact, 2 entire development cycles. Okay, I understand your version/release convention now. However, I guess I'm a little thick-headed on the peer loop issue. Please explain what a peer loop is or point me to the doc page that explains it. I don't see the disadvantage of having common peers. So, the new behavior is to select no candidates if they have common peers? This would seem counter-intuitive from a reliability/redundancy standpoint. What will this ver 4.2.4 server do when it can no longer reach the master server? My guess is that it will either stop serving time or die since it has no other reference (local undisciplined clocks not configured). If true, this is an undesirable condition, and seems especially wasteful when there are other time sources available even if they may not be as precise as the master. I'm sure I'm misunderstanding something here. Thanks for being patient with me. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
Cal Webster said: Please explain what a peer loop is or point me to the doc page that explains it. I don't see the disadvantage of having common peers. peers unfortunately has multiple meanings. The remote time servers that an ntpd is synced to are often refered to as peers. But these ntpds could be in a peer (bi-directional) or server (uni-directional) association. Systems which are in a peer association exchange their notion of time with each other. In a server association the client requests the time from the server. So, the new behavior is to select no candidates if they have common peers? A peer association will be discarded if both peers are have selected the same sys_peer (i.e. they are both synced to the same time source). This would seem counter-intuitive from a reliability/redundancy standpoint. What will this ver 4.2.4 server do when it can no longer reach the master server? My guess is that it will either stop serving time or die since it has no other reference (local undisciplined clocks not configured). If true, this is an undesirable condition, and seems especially wasteful when there are other time sources available even if they may not be as precise as the master. An ntpd keeps running and continues to discipline the system clock with the last known frequency correction when all time sources become unreachable. So, no, it won't fall over. But what will happen is this ntpd will no longer be able to serve time to others unless it is configured with (a) the Undisciplined Local Clock or (b) Orphan Mode. One thing you need to keep in mind is that the associations are not static. ntpd evaluates them at each poll and will select (as sys_peer or candidate) or discard associations as conditions change. In your case the remaining servers will select the reachable server with the lowest stratum Undisciplined Local Clock when the master (server A) is unreachable. Assuming that you restarted ntpd with the revised configuration files. -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project http://support.ntp.org/ Public Key at http://support.ntp.org/Users/SteveKostecke ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Wed, 2008-12-03 at 11:09 -0500, Steve Kostecke wrote: Cal Webster said: Please explain what a peer loop is or point me to the doc page that explains it. I don't see the disadvantage of having common peers. peers unfortunately has multiple meanings. The remote time servers that an ntpd is synced to are often refered to as peers. But these ntpds could be in a peer (bi-directional) or server (uni-directional) association. Systems which are in a peer association exchange their notion of time with each other. In a server association the client requests the time from the server. So, the new behavior is to select no candidates if they have common peers? A peer association will be discarded if both peers are have selected the same sys_peer (i.e. they are both synced to the same time source). Ahh! Okay, now I get it. As is often the case, context is everything. This would seem counter-intuitive from a reliability/redundancy standpoint. What will this ver 4.2.4 server do when it can no longer reach the master server? My guess is that it will either stop serving time or die since it has no other reference (local undisciplined clocks not configured). If true, this is an undesirable condition, and seems especially wasteful when there are other time sources available even if they may not be as precise as the master. An ntpd keeps running and continues to discipline the system clock with the last known frequency correction when all time sources become unreachable. So, no, it won't fall over. But what will happen is this ntpd will no longer be able to serve time to others unless it is configured with (a) the Undisciplined Local Clock or (b) Orphan Mode. Alright then... that makes more sense. Since all servers must be capable of Orphan mode in order to participate, my configuration will have to be based on undisciplined local clocks as backup references. I'm scheduling OS upgrades for our local servers throughout January 2009. We'll move to the Orphan mode configuration once we are able to host compatible versions. I also hope to have a GPS time source rolled out in the first quarter too. One thing you need to keep in mind is that the associations are not static. ntpd evaluates them at each poll and will select (as sys_peer or candidate) or discard associations as conditions change. Thank you. I have observed this behavior too. In your case the remaining servers will select the reachable server with the lowest stratum Undisciplined Local Clock when the master (server A) is unreachable. Assuming that you restarted ntpd with the revised configuration files. Good. You have alleviated my concerns. Thank you for your detailed explanations and your time. ./Cal ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
Calvin Webster [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Wed, 2008-12-03 at 09:08 +0100, Maarten Wiltink wrote: Cal Webster [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] I haven't restarted the servers yet in case I need to query some more info. Do you think this could be a contributing factor in this problem? If you haven't restarted the machines, that's okay. You never have to, restarting NTP is enough. If you haven't restarted the NTP daemons, they will not have the new configuration. Thank you for being specific Maarten. If I were a Linux novice that information would be very helpful. It's hard to judge skill level from a few posts. When I say servers I mean the ntpd daemons on each host. I only restart hosts for kernel updates or shutdown in case of destructive whether. :-) And thank you for taking the note in the spirit in which it was meant. 'Server' is unfortunately an ambiguous term and I thought I'd head off some possible confusion. Not necessarily yours. There is still some confusion on my part left unsettled, though. If you haven't restarted the NTP processes, they will not have the new configuration. Yes, that _would_ be a contributing factor - any problems that are due to the old configuration would have no reason to go away. How should I read that question? Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Wed, 2008-12-03 at 17:53 +0100, Maarten Wiltink wrote: [...] Thank you for being specific Maarten. If I were a Linux novice that information would be very helpful. It's hard to judge skill level from a few posts. When I say servers I mean the ntpd daemons on each host. I only restart hosts for kernel updates or shutdown in case of destructive whether. :-) And thank you for taking the note in the spirit in which it was meant. 'Server' is unfortunately an ambiguous term and I thought I'd head off some possible confusion. Not necessarily yours. There is still some confusion on my part left unsettled, though. If you haven't restarted the NTP processes, they will not have the new configuration. Yes, that _would_ be a contributing factor - any problems that are due to the old configuration would have no reason to go away. How should I read that question? I'm sorry if I wasn't clear in my response. I recognize also that it is sometimes hard to follow responses to one item in a thread when multiple contributors answer different parts of the problem. Let me try to reconstruct the portions that led to your question. In response to my original question, David Woolley replied [Tue, 02 Dec 2008 19:50:43 + (14:50 EST)]: --[quote]-- Orphan and local clock are mutually incompatible! --[unquote]-- I took this as a suggestion to remove the the configuration lines for the undisciplined local clocks. In my response to David Woolley [Tue, 02 Dec 2008 16:08:19 -0500] I was asking if he thought that having the undisciplined local clock configured could have contributed to the original problem (one server rejecting apparently good peers). --[quote]-- naughty boy will not be a well-behaved Orphan Child. Orphan and local clock are mutually incompatible! Okay, I've commented out those lines. Thanks. I haven't restarted the servers yet in case I need to query some more info. Do you think this could be a contributing factor in this problem? --[unquote]-- Although I did not get a direct response from David Woolley on this point, Steve Kostecke was kind enough to clarify it in his response [02 Dec 2008 21:03:21 GMT (16:03 EST)]: --[quote]-- ... Orphan Mode and the Undisciplined Local Clock are merely ways of providing a time source to ntpd. As with any set of time sources, how they are configured dictates which one takes precedence. Perhaps what you meant to say was using both does not provide any benefits. --[unquote]-- I took this to mean that leaving in the lines for the undisciplined local clock was not a contributor to this problem. In other words, in this context, leaving the lines in would not break anything. In point of fact, taking them out *would* have broken my particular setup because I did not have a working Orphan mode configuration. All participants were not capable of running in orphan mode. Should the master server become unreachable, the other servers would stop providing time service to clients without the undisciplined local clock as a time reference. Good think I delayed restarting the ntpd service on those hosts. In his most recent reply, Steve Kostecke took time to explain the peer loop in this context and what would happen in my case with no undisciplined local clocks configured [Wed, 03 Dec 2008 11:09:51 -0500]: --[quote]-- An ntpd keeps running and continues to discipline the system clock with the last known frequency correction when all time sources become unreachable. So, no, it won't fall over. But what will happen is this ntpd will no longer be able to serve time to others unless it is configured with (a) the Undisciplined Local Clock or (b) Orphan Mode. --[unquote]-- ...and with Steve Kostecke's generous gift of ntp.conf revisions from another response... --[quote]-- In your case the remaining servers will select the reachable server with the lowest stratum Undisciplined Local Clock when the master (server A) is unreachable. Assuming that you restarted ntpd with the revised configuration files. --[unquote]-- I hope that clears up any confusion I may have caused. Thanks for participating in this thread. :-) ./Cal ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Rejecting Good Peers
One of my NTP servers (Server D below) is rejecting both of its peers. They, on the other hand, each have consistent candidate status for both of *their* peers. This rejecting server does pick the master server as it's reference source but has no candidates listed. I don't see anything that would cause this. I'm worried that, should the master fail, this naughty boy will not be a well-behaved Orphan Child. Can someone explain why they think this might be happening and suggest a course of action? I've included some relevant data below. Note that some ntpq output has wrapped below. Please let me know if you need more info. ./Cal = NTP Versions: = Server A: ntp-4.1.2-0.rc1.2 Server B: ntp-4.2.0.a.20040617-6.el4 Server C: ntp-4.2.0.a.20040617-6.el4 Server D: ntp-4.2.4p2-6.fc8 Configs: Server A - Master [fluid]: -- tos orphan 5 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 1 driftfile /etc/ntp/drift broadcastdelay 0.008 keys/etc/ntp/keys -- Server B [jato]: tos orphan 5 server 192.168.3.132 peer 192.168.1.30 peer 192.168.2.6 server 127.127.1.0 fudge 127.127.1.0 stratum 12 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys/etc/ntp/keys Server C [pegasus]: --- tos orphan 5 server 192.168.3.132 peer 192.168.3.9 peer 192.168.1.30 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 8 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys/etc/ntp/keys --- Server D [axl]: --- tos orphan 5 server 192.168.3.132 peer 192.168.3.9 peer 192.168.2.6 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys/etc/ntp/keys --- = Associations: = (ntpq -c pe -c as) Server A: - remote refid st t when poll reach delay offset jitter == *LOCAL(0).LCL.1 l 17 64 3770.0000.000 0.015 ind assID status conf reach auth condition last_event cnt === 1 56268 9624 yes yes none sys.peer reachable 2 - Server B: - remote refid st t when poll reach delay offset jitter == *fluid LOCAL(0) 2 u 108 256 3770.275 -0.931 0.830 +axl 192.168.3.1323 u 59 256 377 23.2731.082 6.640 +pegasus 192.168.3.1323 u 217 256 333 24.6452.566 0.766 LOCAL(0)LOCAL(0)12 l 24 64 3770.0000.000 0.004 ind assID status conf reach auth condition last_event cnt === 1 63404 9614 yes yes none sys.peer reachable 1 2 63405 9414 yes yes none candidat reachable 1 3 63406 9414 yes yes none candidat reachable 1 4 63407 9014 yes yes nonereject reachable 1 - Server C: - remote refid st t when poll reach delay offset jitter == *fluid LOCAL(0) 2 u 793 1024 377 27.103 -4.505 2.406 +jato192.168.3.1323 u 221 256 166 24.675 -2.581 0.652 +axl 192.168.3.1323 u 998 512 374 31.983 -1.971 0.199 LOCAL(0)LOCAL(0) 8 l 45 64 3770.0000.000 0.001 ind assID status conf reach auth condition last_event cnt === 1 29660 9614 yes yes none sys.peer reachable 1 2 29661 9414 yes yes none candidat reachable 1 3 29662 9424 yes yes none candidat reachable 2 4 29663 9014 yes yes nonereject reachable 1 - Server D: - remote refid st t when poll reach delay offset jitter == *fluid LOCAL(0) 2 u 979 1024 377 24.665 -1.216 0.550 jato192.168.3.1323 u 177 256 376 24.585 -0.400 5.980 pegasus 192.168.3.1323 u 227 1024 377 31.9891.968 0.127 LOCAL(0).LOCL. 10 l 30 64 3770.0000.000 0.001 ind assID status conf reach auth condition last_event cnt === 1 48371 9624 yes yes none sys.peer reachable 2 2 48372 9024 yes yes nonereject reachable 2 3 48373 9024 yes yes nonereject reachable 2 4 48374 9024 yes yes nonereject reachable 2 - ___
Re: [ntp:questions] Rejecting Good Peers
Cal Webster wrote: One of my NTP servers (Server D below) is rejecting both of its peers. They, on the other hand, each have consistent candidate status for both of *their* peers. This rejecting server does pick the master server as it's reference source but has no candidates listed. I don't see anything that would cause this. I'm worried that, should the master fail, this That information will be in the result of doing read variables (rv) against the association IDs of the rejected servers. naughty boy will not be a well-behaved Orphan Child. Orphan and local clock are mutually incompatible! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Tue, 2008-12-02 at 19:50 +, David Woolley wrote: Cal Webster wrote: One of my NTP servers (Server D below) is rejecting both of its peers. They, on the other hand, each have consistent candidate status for both of *their* peers. This rejecting server does pick the master server as it's reference source but has no candidates listed. I don't see anything that would cause this. I'm worried that, should the master fail, this That information will be in the result of doing read variables (rv) against the association IDs of the rejected servers. The only thing I see that stands out is that the status codes differ between the server with rejected peers and those without. I don't know if there's more information embedded in the codes than what follows on that line. The server with rejections says 2 events versus sel_candidat on the normal servers. I'm not sure what to make of this. Can you point me to where I can find more information about these codes? I've included the output of an rv query for those assID's below as well as output from the other servers looking at the same machines. naughty boy will not be a well-behaved Orphan Child. Orphan and local clock are mutually incompatible! Okay, I've commented out those lines. Thanks. I haven't restarted the servers yet in case I need to query some more info. Do you think this could be a contributing factor in this problem? ./Cal == Taken from Server D [axl]: == (jato) ntpq -c rv 48372 -- assID=48372 status=9024 reach, conf, 2 events, event_reach, srcadr=jato, srcport=123, dstadr=192.168.1.30, dstport=123, leap=00, stratum=3, precision=-18, rootdelay=0.824, rootdispersion=56.168, refid=192.168.3.132, reach=336, unreach=0, hmode=1, pmode=1, hpoll=10, ppoll=10, flash=800 peer_loop, keyid=0, ttl=0, offset=2.237, delay=24.425, dispersion=20.550, jitter=1.242, reftime=cce010a6.1a7eb6bf Tue, Dec 2 2008 14:53:10.103, org=cce01460.f244e93e Tue, Dec 2 2008 15:09:04.946, rec=cce01460.f4857be7 Tue, Dec 2 2008 15:09:04.955, xmt=cce017cc.0410e751 Tue, Dec 2 2008 15:23:40.015, filtdelay=24.55 24.43 25.96 24.16 24.38 28.56 24.30 24.21, filtoffset=3.482.241.202.341.690.320.16 -0.27, filtdisp= 2.24 17.57 32.96 48.35 63.70 71.39 79.08 86.76 -- (pegasus) ntpq -c rv 48373 -- assID=48373 status=9024 reach, conf, 2 events, event_reach, srcadr=pegasus, srcport=123, dstadr=192.168.1.30, dstport=123, leap=00, stratum=3, precision=-20, rootdelay=24.796, rootdispersion=54.123, refid=192.168.3.132, reach=376, unreach=0, hmode=1, pmode=1, hpoll=10, ppoll=10, flash=800 peer_loop, keyid=0, ttl=0, offset=6.071, delay=32.321, dispersion=30.348, jitter=0.634, reftime=cce012f5.03480a5a Tue, Dec 2 2008 15:03:01.012, org=cce0152a.887e2824 Tue, Dec 2 2008 15:12:26.533, rec=cce0152a.8b487b8f Tue, Dec 2 2008 15:12:26.544, xmt=cce0161b.0410e834 Tue, Dec 2 2008 15:16:27.015, filtdelay=32.67 32.32 32.14 32.12 34.43 33.17 30.85 287.57, filtoffset=5.446.076.116.225.506.225.05 -125.27, filtdisp= 11.74 27.10 42.45 57.79 73.14 88.53 103.87 119.22 -- === Taken from Server B [jato]: === (pegasus) ntpq -c rv 63406 -- assID=63406 status=9414 reach, conf, sel_candidat, 1 event, event_reach, srcadr=pegasus, srcport=123, dstadr=192.168.3.9, dstport=123, leap=00, stratum=3, precision=-20, rootdelay=31.296, rootdispersion=46.875, refid=192.168.3.132, reach=376, unreach=0, hmode=1, pmode=1, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=1.638, delay=24.778, dispersion=26.226, jitter=2.574, reftime=cce01afa.fdec3dab Tue, Dec 2 2008 15:37:14.991, org=cce01b39.05479d4d Tue, Dec 2 2008 15:38:17.020, rec=cce01b39.08083126 Tue, Dec 2 2008 15:38:17.031, xmt=cce01c2f.b5fcc187 Tue, Dec 2 2008 15:42:23.710, filtdelay=24.78 29.32 26.06 25.00 24.07 25.43 24.89 26.66, filtoffset=1.644.212.794.114.234.394.66 5.35, filtdisp= 11.66 27.01 42.40 57.74 73.13 88.47 88.46 96.13 -- == Taken from Server C [pegasus]: == (jato) ntpq -c rv 29661 -- assID=29661 status=9414 reach, conf, sel_candidat, 1 event, event_reach, srcadr=jato, srcport=123, dstadr=192.168.2.6, dstport=123, leap=00, stratum=3, precision=-18, rootdelay=0.443, rootdispersion=57.144, refid=192.168.3.132, reach=277, unreach=0, hmode=1, pmode=1, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=-1.069, delay=23.641, dispersion=18.495, jitter=0.721, reftime=cce018a8.ea425aee Tue, Dec 2 2008 15:27:20.915, org=cce01c2f.b5fcc187 Tue, Dec 2 2008 15:42:23.710, rec=cce01c2f.b94983d7 Tue, Dec 2 2008 15:42:23.723, xmt=cce01b39.05479d4d Tue, Dec 2 2008
Re: [ntp:questions] Rejecting Good Peers
On 2008-12-02, David Woolley [EMAIL PROTECTED] wrote: naughty boy will not be a well-behaved Orphan Child. Orphan and local clock are mutually incompatible! Nonsense. Orphan Mode and the Undisciplined Local Clock are merely ways of providing a time source to ntpd. As with any set of time sources, how they are configured dictates which one takes precedence. Perhaps what you meant to say was using both does not provide any benefits. -- Steve Kostecke [EMAIL PROTECTED] 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] Rejecting Good Peers
Cal Webster wrote: ppoll=10, flash=800 peer_loop, keyid=0, ttl=0, offset=6.071, ^^^ Looks like it is objecting to to the client ultimately being its own server, which I guess is a reasonable thing to do. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
Steve Kostecke wrote: On 2008-12-02, David Woolley [EMAIL PROTECTED] wrote: naughty boy will not be a well-behaved Orphan Child. Orphan and local clock are mutually incompatible! Nonsense. Orphan Mode and the Undisciplined Local Clock are merely ways of providing a time source to ntpd. As with any set of time sources, how they are configured dictates which one takes precedence. Perhaps what you meant to say was using both does not provide any benefits. Using both on the same machine will result in only one of them being effective. I think, as the orphan mode was stratum 5 and the local clock was stratum 10, the orphan mode would be effective and the local clock would be ignored. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Tue, 2008-12-02 at 21:33 +, David Woolley wrote: Cal Webster wrote: ppoll=10, flash=800 peer_loop, keyid=0, ttl=0, offset=6.071, ^^^ Looks like it is objecting to to the client ultimately being its own server, which I guess is a reasonable thing to do. I saw that after sending my last reply but didn't know what it meant. How could any of the peers be clients of themselves? Only the master server is using the Undisciplined Local Clock as a reference. All the others appear to be correctly rejecting theirs and using the master server as their reference with peers as candidates. Could this have something to do with the Orphan mode settings? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On Tue, 2008-12-02 at 21:29 +, Steve Kostecke wrote: On 2008-12-02, Cal Webster [EMAIL PROTECTED] wrote: One of my NTP servers (Server D below) is rejecting both of its peers. They, on the other hand, each have consistent candidate status for both of *their* peers. This rejecting server does pick the master server as it's reference source but has no candidates listed. I don't see anything that would cause this. ntpd is pickier about peer associations than server associations. Server D is correctly rejecting peers that are synced to it's sys_peer. = NTP Versions: = Server A: ntp-4.1.2-0.rc1.2 Server B: ntp-4.2.0.a.20040617-6.el4 Server C: ntp-4.2.0.a.20040617-6.el4 Server D: ntp-4.2.4p2-6.fc8 Orphan Mode was introduced in version 4.2.2 ... so A, B, C don't have it. You should be seeing complaints about Orphan Mode in the syslog of those three machines. Yup, Server A complains about 'keyword tos unknown', whereas B C say 'keyword orphan unknown'. It sure would be nice if there were more documentation about Orphan mode. There is nothing in the man or info pages for any version. The only scraps I could find were a short blurb on the associations page at ntp.org and an archived mailing list post. Configs: [...] Thank you for the corrected config lines. I'm assuming that staggering the stratum of the undisciplined local clocks will settle any ambiguity if the master server dies. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
Cal Webster wrote: How could any of the peers be clients of themselves? Only the master I think that is the nature of peers. The relationship is symmetric. server is using the Undisciplined Local Clock as a reference. All the others appear to be correctly rejecting theirs and using the master server as their reference with peers as candidates. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
David Woolley [EMAIL PROTECTED] wrote: Cal Webster wrote: How could any of the peers be clients of themselves? Only the master I think that is the nature of peers. The relationship is symmetric. That still doesn't make sense to me. A peer is objecting to his peer using a fellow peer as a candidate? Why then does this behavior only present itself on the version 4.2.4 peer and none of the others? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Cal Webster) writes: Cal It sure would be nice if there were more documentation about Orphan Cal mode. There is nothing in the man or info pages for any version. The Cal only scraps I could find were a short blurb on the associations page Cal at ntp.org and an archived mailing list post. Stock NTP currently ships with only HTML docs. If you want to see (or search) the docs for various versions of NTP, try http://doc.ntp.org (thanks, Steve!). I intend to have man and info pages generated for NTP as well - those efforts are described at: http://ntpforum.isc.org/bin/view/Main/ForumProject3 and http://ntpforum.isc.org/bin/view/Main/ForumProject4 If nothing happens on these projects before next summer, I'll be listing the first one as anothe GSoC project. -- Harlan Stenn [EMAIL PROTECTED] http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Rejecting Good Peers
On 2008-12-03, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That still doesn't make sense to me. A peer is objecting to his peer using a fellow peer as a candidate? Why then does this behavior only present itself on the version 4.2.4 peer and none of the others? The difference between 4.2.4 and 4.2.0 is greater than one might be led to believe. -- Steve Kostecke [EMAIL PROTECTED] 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] Rejecting Good Peers
On 2008-12-02, Cal Webster [EMAIL PROTECTED] wrote: On Tue, 2008-12-02 at 21:29 +, Steve Kostecke wrote: Orphan Mode was introduced in version 4.2.2 It sure would be nice if there were more documentation about Orphan mode. The Official Distribution Documentation is maintained by one individual. And it (http://www.eecis.udel.edu/~mills/ntp/html) tracks the NTP development tree. The NTP Public Services Project operates a Distribution Documentation Archive at http://doc.ntp.org/. This archive contains frozen versions of the Distribution Documentation present in each stable release. There is nothing in the man or info pages for any version. The Official Distribution Documentation is maintained, and released, as HTML. Other forms of documenation (e.g. man pages, info, etc.) are maintained by third parties. The only scraps I could find were a short blurb on the associations page at ntp.org and an archived mailing list post. This is one reason why we have a Community Supported Documentation system (at http://support.ntp.org/support). Volunteers are welcome to add / correct / improve documentation. Configs: [...] Thank you for the corrected config lines. Those are complete replacements for your existing configuration files. There were a number on non-functional lines (e.g. broadcastdelay) which where elidded. I'm assuming that staggering the stratum of the undisciplined local clocks will settle any ambiguity if the master server dies. Yes, it will. -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
