Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] Look, an SNTP client is not supposed to act as a server. Period. Unless... its clock is disciplined by means external to NTP. For example, by a reference clock. Not all reference clocks must necessarily be NTP servers; there are other ways to use them to make sure that some clock in the next computer over runs Very Close to UTC. It has been said right here that many if not most of the black box stratum-1 servers operate by the exact mechanism you condemn: an SNTP client polling a local refclock at some suitably short interval, presumably with a simple feedback loop but without the full NTP and its higher math other assorted magic. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On Mar 25, 7:21 am, David Woolley [EMAIL PROTECTED] wrote: Note that Microsfoft's SNTP implementation claims stratum 2, when acting as an a server with an illegal time source. This is not true in Windows 2003 and newer. Considering that Windows 2000 sales ended in 2003, and mainstream support ended in 2005, I think your statement needs qualification. Windows Time Service (w32time) is an RFC-1305-compliant NTP (not SNTP!) implementation, and has been for 5 years or more. It reports the correct statum, has the clock discipline algorithms, etc. Yes, it has some limitations (precision is -6), and is easy to mis-configure (so is ntpd), but it mostly just works. I advise most of my clients to use it rather than messing with the complexity of ntpd on Windows if possible. I know a lot of people hate MSFT, but let's not let that get in the way of the actual facts. Not everyone can or should run the reference ntpd implementation. There will always be other commercial and open source implementations of the NTP and SNTP protocols. This is a very good thing from a security perspective, and also from a competitive perspective. Would we have the pool scheme in the development versions of ntpd now if OpenNTPD hadn't implemented it first? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp discipline of local time?
Unruh wrote: How does ntp actually discipline the local clock? I have a gps received If you are using the kernel time discipline, which you should be using for high accuracy, nptd doesn't discipline the clock; it is the kernel code that does that, based on measurements provided by ntpd. attached to a computer which is disciplined by a remote clock over an ADSL line. (Ie, the gps does not act as a refclock -- it is purely to measure the actual offset of the system. It is only the remote server that actaully acts the ntp reference source.) I can watch how ntp alters the local clock in response to remote offsets. The response is not linear. rather it is curved as though the rate of the local clock were exponentially eliminating the offset. But this That sounds very plausible. The clock discipline code solves for both frequency and phase errors. The phase error is probably being filtered using an IIR filter, and that is what you are seeing, and also the mechanism ntpd uses to stop wandering off if it stops receiving updates (the frequency measurement error can produce unbounded phase errors, but the phase error correction is bounded). is between two succesive runnings of the loopstats. Where is this behaviour determined? -- ie which routines determines the response of the system between to successive measurements of the offset? If you don't use the kernel discipline, on Unix-like systems, it will implement the same filters in user space and apply phase adjustments at each kernel update. For ntpv3, those updates were every 4 seconds; for ntpv4, I believe it does them every second. A normal Unix-like system will implement the phase change by increasing or decreasing the amount by which the software clock is updated for every tick by +/- 500ppm, until the adjustment is complete. Windows has a different kernel interface, and I believe that ntpd modulates the effective length of a tick. Note, in spite of what other replies may imply, the physical clock frequency is never actually changed; what is actually changed is the amount by which the software clock is incremented for ever n-cycles of whatever is used for the reference frequency. If you want the actual code and fine details, you will be able to find them as easily as I will, so I'll leave that as an exercise for the reader. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Ryan Malayter wrote: This is not true in Windows 2003 and newer. Considering that Windows Depends on the service pack. I believe it was finally fixed about two years ago. The reference implementation is still better. 2000 sales ended in 2003, and mainstream support ended in 2005, I think your statement needs qualification. But noting that Windows XP support life has been extended because users refused to move to Vista. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On 2008-03-25, Ryan Malayter [EMAIL PROTECTED] wrote: On Mar 25, 7:21 am, David Woolley wrote: Note that Microsfoft's SNTP implementation claims stratum 2, when acting as an a server with an illegal time source. This is not true in Windows 2003 and newer. Considering that Windows 2000 sales ended in 2003, and mainstream support ended in 2005, I think your statement needs qualification. Windows Time Service (w32time) is an RFC-1305-compliant NTP (not SNTP!) implementation, and has been for 5 years or more. We all now how long older versions of Windows remain in service well past the EOL. What _version_ of w32time is RFC-1305 compliant? Would we have the pool scheme in the development versions of ntpd now if OpenNTPD hadn't implemented it first? Really? They did? Are you sure that the person who wrote the pool configuration directive code for the Reference Implementation of NTP pays any attention to OpenNTPD? -- 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] SNTP server + ntpd 4.2.4 client
Steve Kostecke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 2008-03-25, Ryan Malayter [EMAIL PROTECTED] wrote: [...] Would we have the pool scheme in the development versions of ntpd now if OpenNTPD hadn't implemented it first? Really? They did? The NTP Pool was implemented at first as a bunch of public NTP servers, with clever use of DNS to make it work. The point I'm trying to make is that it worked before and without any NTP implementation knowing about it. It does work better when the NTP client is aware of the need to re-resolve hostnames under certain circumstances, but those same circumstances occur outside the pool, just not as often or as pressing. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp discipline of local time?
David Woolley [EMAIL PROTECTED] writes: Unruh wrote: How does ntp actually discipline the local clock? I have a gps received If you are using the kernel time discipline, which you should be using for high accuracy, nptd doesn't discipline the clock; it is the kernel code that does that, based on measurements provided by ntpd. I do not think that this is right, unless you are referring to a PPS sounce. ntp sets the frequency of the kerhel clock (Is that change in frequency what you mean by kernel time discipline) by a very simple second order PDE feedback, and the offset by and exponential first order feedback scheme. At least that is what it looks like to me trying to read ntp_loopfilter.c attached to a computer which is disciplined by a remote clock over an ADSL line. (Ie, the gps does not act as a refclock -- it is purely to measure the actual offset of the system. It is only the remote server that actaully acts the ntp reference source.) I can watch how ntp alters the local clock in response to remote offsets. The response is not linear. rather it is curved as though the rate of the local clock were exponentially eliminating the offset. But this That sounds very plausible. The clock discipline code solves for both frequency and phase errors. The phase error is probably being filtered using an IIR filter, and that is what you are seeing, and also the mechanism ntpd uses to stop wandering off if it stops receiving updates (the frequency measurement error can produce unbounded phase errors, but the phase error correction is bounded). is between two succesive runnings of the loopstats. Where is this behaviour determined? -- ie which routines determines the response of the system between to successive measurements of the offset? If you don't use the kernel discipline, on Unix-like systems, it will implement the same filters in user space and apply phase adjustments at each kernel update. For ntpv3, those updates were every 4 seconds; for ntpv4, I believe it does them every second. A normal Unix-like system will implement the phase change by increasing or decreasing the amount by which the software clock is updated for every tick by +/- 500ppm, until the adjustment is complete. It is the linux system I am interested in. It looks to me like it adjusts the frequency with a simply second order feedback loop using the ntp_adjtime system call, and then drives the offset to zero with an exponential run once a second (?? I cannot disentangle the code to really be sure of this) using the adjtime system call. That exponential has a huge time constant-- something like 16 times the poll interval. Windows has a different kernel interface, and I believe that ntpd modulates the effective length of a tick. Note, in spite of what other replies may imply, the physical clock frequency is never actually changed; what is actually changed is the amount by which the software clock is incremented for ever n-cycles of whatever is used for the reference frequency. Of course. There is no way that the physical clock can be influenced by software. The system simply changes the relation between harware cpu cycle counts and time. If you want the actual code and fine details, you will be able to find them as easily as I will, so I'll leave that as an exercise for the reader. I guess I was hoping that perhaps the person/people who actually wrote the code could tell me what was going on in the code. While the code is reasonably annotated, those annotations do not give me at least a good sense of the overall picture. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp discipline of local time?
Unruh, The kernel discipline is almost identical to the daemon discipline with the exception that the fancy code to combine the PLL and FLL near the Allan intercept is absent. Without the PPS signal, the discipline behaves as a second-order loop; with the PPS it behaves as two separate first-order loops, one for phase, the other for frequency. When necessary to set the freque directly, ther kernel is use for that. Note that the peripheral functions, like the clock state machine and poll-adjust algorithm continue in the daemon. Dave Unruh wrote: David Woolley [EMAIL PROTECTED] writes: Unruh wrote: How does ntp actually discipline the local clock? I have a gps received If you are using the kernel time discipline, which you should be using for high accuracy, nptd doesn't discipline the clock; it is the kernel code that does that, based on measurements provided by ntpd. I do not think that this is right, unless you are referring to a PPS sounce. ntp sets the frequency of the kerhel clock (Is that change in frequency what you mean by kernel time discipline) by a very simple second order PDE feedback, and the offset by and exponential first order feedback scheme. At least that is what it looks like to me trying to read ntp_loopfilter.c attached to a computer which is disciplined by a remote clock over an ADSL line. (Ie, the gps does not act as a refclock -- it is purely to measure the actual offset of the system. It is only the remote server that actaully acts the ntp reference source.) I can watch how ntp alters the local clock in response to remote offsets. The response is not linear. rather it is curved as though the rate of the local clock were exponentially eliminating the offset. But this That sounds very plausible. The clock discipline code solves for both frequency and phase errors. The phase error is probably being filtered using an IIR filter, and that is what you are seeing, and also the mechanism ntpd uses to stop wandering off if it stops receiving updates (the frequency measurement error can produce unbounded phase errors, but the phase error correction is bounded). is between two succesive runnings of the loopstats. Where is this behaviour determined? -- ie which routines determines the response of the system between to successive measurements of the offset? If you don't use the kernel discipline, on Unix-like systems, it will implement the same filters in user space and apply phase adjustments at each kernel update. For ntpv3, those updates were every 4 seconds; for ntpv4, I believe it does them every second. A normal Unix-like system will implement the phase change by increasing or decreasing the amount by which the software clock is updated for every tick by +/- 500ppm, until the adjustment is complete. It is the linux system I am interested in. It looks to me like it adjusts the frequency with a simply second order feedback loop using the ntp_adjtime system call, and then drives the offset to zero with an exponential run once a second (?? I cannot disentangle the code to really be sure of this) using the adjtime system call. That exponential has a huge time constant-- something like 16 times the poll interval. Windows has a different kernel interface, and I believe that ntpd modulates the effective length of a tick. Note, in spite of what other replies may imply, the physical clock frequency is never actually changed; what is actually changed is the amount by which the software clock is incremented for ever n-cycles of whatever is used for the reference frequency. Of course. There is no way that the physical clock can be influenced by software. The system simply changes the relation between harware cpu cycle counts and time. If you want the actual code and fine details, you will be able to find them as easily as I will, so I'll leave that as an exercise for the reader. I guess I was hoping that perhaps the person/people who actually wrote the code could tell me what was going on in the code. While the code is reasonably annotated, those annotations do not give me at least a good sense of the overall picture. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp discipline of local time?
Unruh wrote: David Woolley [EMAIL PROTECTED] writes: If you are using the kernel time discipline, which you should be using for high accuracy, nptd doesn't discipline the clock; it is the kernel code that does that, based on measurements provided by ntpd. I do not think that this is right, unless you are referring to a PPS sounce. ntp sets the frequency of the kerhel clock (Is that change in frequency what you mean by kernel time discipline) by a very simple second order PDE feedback, and the offset by and exponential first order feedback scheme. At least that is what it looks like to me trying to read ntp_loopfilter.c 2.4 kernel (2.4.33): /usr/src/linux/kernel/timer.c 417 /* 418 * Compute the phase adjustment for the next second. In 419 * PLL mode, the offset is reduced by a fixed factor 420 * times the time constant. In FLL mode the offset is 421 * used directly. In either mode, the maximum phase 422 * adjustment for each second is clamped so as to spread 423 * the adjustment over not more than the number of 424 * seconds between updates. 425 */ loopfilter.c feeds the kernel with offset when it has a time update and it is in PLL mode. Note that a simple exponential decay is an IIR filter: From ntp v4.2p4: ntpd/ntp_loopfilter.c 172 #define MOD_BITS (MOD_OFFSET | MOD_MAXERROR | MOD_ESTERROR | \ 173 MOD_STATUS | MOD_TIMECONST) gives the default set of ntpadjtime mode options. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On Mar 25, 9:47 am, Steve Kostecke [EMAIL PROTECTED] wrote: What _version_ of w32time is RFC-1305 compliant? Microsoft's documentation indicates that all versions of w32time in Windows 2003 are RFC-1305 compliant. I know from testing that the versions in Windows 2003 SP1 (releleased March 30 2005) and later are RFC-1305 compliant when configured properly. I did not test the RTM version of Windows 2003. Would we have the pool scheme in the development versions of ntpd now if OpenNTPD hadn't implemented it first? Really? They did? Yes, they did, back in 2004. See the servers keyword: http://www.openbsd.org/cgi-bin/man.cgi?query=ntpd.confapropos=0sektion=0manpath=OpenBSD+3.6arch=i386format=html Are you sure that the person who wrote the pool configuration directive code for the Reference Implementation of NTP pays any attention to OpenNTPD? No, I am not sure. But I do recall the OpenNTPD servers keyword being mentioned on the NTP Pool project mailing list long before the pool directive appeared in the development versions NTPD. Shouldn't any software developer be looking at other solutions in the same problem space for ideas? Especially in an open souce world? -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp discipline of local time?
David Woolley [EMAIL PROTECTED] writes: Unruh wrote: David Woolley [EMAIL PROTECTED] writes: If you are using the kernel time discipline, which you should be using for high accuracy, nptd doesn't discipline the clock; it is the kernel code that does that, based on measurements provided by ntpd. I do not think that this is right, unless you are referring to a PPS sounce. ntp sets the frequency of the kerhel clock (Is that change in frequency what you mean by kernel time discipline) by a very simple second order PDE feedback, and the offset by and exponential first order feedback scheme. At least that is what it looks like to me trying to read ntp_loopfilter.c 2.4 kernel (2.4.33): /usr/src/linux/kernel/timer.c 417 /* 418 * Compute the phase adjustment for the next second. In 419 * PLL mode, the offset is reduced by a fixed factor 420 * times the time constant. In FLL mode the offset is 421 * used directly. In either mode, the maximum phase 422 * adjustment for each second is clamped so as to spread 423 * the adjustment over not more than the number of 424 * seconds between updates. 425 */ The program interacts with the kernel through ntp_adjtime ( adjtimex on linux) I believe, so lets keep the discussion at that level. From what I see in ntp_loopfilter.c in loopfilter.c feeds the kernel with offset when it has a time update and it is in PLL mode. Note that a simple exponential decay is an IIR filter: NO, it also feeds it a frequency offset. I am not objecting to a simple exponential decay being an IIR filter. It is a very specific IIR filter. From ntp v4.2p4: ntpd/ntp_loopfilter.c 172 #define MOD_BITS (MOD_OFFSET | MOD_MAXERROR | MOD_ESTERROR | \ 173 MOD_STATUS | MOD_TIMECONST) gives the default set of ntpadjtime mode options. And then line 595-597 ntv.modes |= MOD_FREQUENCY; ntv.freq = (int32)((clock_frequency + drift_comp) * 65536e6); And then the whole of /* * adj_host_clock - Called once every second to update the local clock. * * LOCKCLOCK: The only thing this routine does is increment the * sys_rootdispersion variable. */ whose key line is adjustment = clock_offset / (CLOCK_PLL * min(ULOGTOD(sys_poll), allan_xpt)); clock_offset -= adjustment; adj_systime(adjustment + drift_comp); Now it is not clear to me that this is actually run once a second, or if this is only run once a second under certain conditions, or what. This certainly produces an exponential decay. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
