Re: [ntp:questions] NTP Cheat Sheet
David L. Mills schrieb: > David, > > The flag FLAG_FIXPOLL is defined for all reference clock driverss except > ACTS. With this flag defined, the poll interval is fixed at minpoll. See > ntp_refclock.c and ntp_proto.c. OK, that explains it :-) We use "minpoll 4 maxpoll 4" because we want the reference clock to be polled every 16s ... Looks like "minpoll" directly affects the maximum polling interval for refclocks (because there is no "minpoll" or "maxpoll", just a "fixpoll" functionality). > Having thought about it, there actually are two scenarios involving > failover, one with the local clock driver, the other with the modem > driver. These driver are disabled unless all other sources are lost or > not configured. For the local clock driver, this was done to avoid nasty > cases when the local clock driver escaped to the Internet at large, > which has in fact happened on occasion. The "Failover" mode is something engineers in most industry segments know and use for all kinds of mission critical stuff, it is often hard or impossible to convince them that for time synchronization a majority approach is the best solution. For some strange reason it sounds a little bit suspicious when a time server manufacturer tells you that "you should use four instead of two time servers to be protected against ..." :-) Heiko > > Dave > > David Woolley wrote: >> David L. Mills wrote: >> >>> >>> There is need to dispell urban legends here. First, the only >>> reference clock driver that uses anything other than minpoll is the >>> ACTS driver. >> >> >> You introduced the possibility that there were exceptions, yourself, >> earlier in the thread; I was just caveating what I wrote to cater for >> that. >> >>> All others do not increase the poll interval under any circumstances. >> >> >> Yes. That's how I read the code; however Heiko appears to have >> empirical evidence to the contrary. (One thought I had is that there >> seems to be more than one state variable involved and maybe ntpq peers >> doesn't show the actual poll interval) >> >>> Second, there is no failover at all. The design is that more than one >> >> >> I suspect failover is concept that customers and salesmen like. I do >> try to stress that ntpd averages multiple sources (and the weighting >> isn't tied to the current system peer). One other aspect of that >> particular myth is the concept of clock hopping. I think clock >> hopping can only happen if you have enough clocks that the set of >> retained clocks changes. I'm sure a lot of people believe that ntpd >> only uses data from the current "system peer". >> >> One caveat, as I understand it, if they used a prefer keyword, ntpd >> would failover from that server to an average of all the others. >> >>> reference clock driver is happily supported at the same time. Their >>> contributions are continuously evaluated and mitigated, so there is >>> no delay in using one or the other or both. If the intended behavior >>> is to "fail over" in the usual sense of those words, you should be >>> using something other than NTP> >> >> >> I think you meant Heiko should be. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual Mixer Time Difference (DMTD) instruments sought
Hello, > While it's unlikely that I will soon get to build such an instrument, I > am quite interested in how they are built, if only to understand what > can happen and why. Can you suggest some articles and/or books and/or > patents delving into both the theory and the practicalities of building > DMTD instruments? We (the time and frequency division of NBS/NIST) designed and built a dual-mixer systerm in 1980 (more or less). This same system is the one that still runs the atomic clock ensemble in Boulder. You can get the publications that describe this instrument from the publications database on our web site. Go to tf.nist.gov and click on the publications menu. When the menu appears, look for author Glaze. The stuff was published in about 1983 or so. There were several papers as I recall with various combinations of the folks who built the system and the software drivers for it. The system we built was totally analog, but a modern system would probably be fully digital. Our system had a resolution of about 0.2 ps and a stability of about 3-4 ps. A digital system could do better, mostly because the temperature sensitive stuff could be confined to the analog front end whereas we had to worry about temperature pretty much everywhere in the system. However, the job is not trivial, since even tiny impedance mismatches can cause problems at this sub-picosecond resolution. You should watch especially for the connectors and the cables. We typically use SMA connectors and rigid coax. The inputs are buffered with distribution amplifiers with a reverse isolation that is as good as we can make it. About -165 db, I think, although I have not looked at that recently. (Note that the problems are not adequate digital computing power but plain old analog electronics.) Even so, we have a detectable sensitivity to temperature at the level of ps. This noise level tends to be too small to affect the data from cesium standards, but it could be a problem if you were trying to calibrate the long-period performance of a device or a transmission system that had a small delay, since the residual diurnal temperature sensitivity could come to get you. If you are in this business then you need professional help. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Power-saving patch to NTP
I came across the following page: http://www.lesswatts.org/projects/powertop/known.php which says the following on ntpd: "By default, the ntp time synchronization daemon will wake up once per second, and will make the kernel do work on it's behalf even more. Red Hat has created a patch to ntp to fix this issue and ships it in their rawhide and FC7 ntp packages. You can download this patch from the Fedora cvs server." Has anyone here looked at that patch? Does it compromise correctness of the algorithms? Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Jan, A timer interrupt is required each second to update the clock frequency no matter what. In addition, a sweep is made through the associations to see if a poll is pending. It would be in principle posssible to implement a system of queues to avopid sweeping the associations each second, but that would save very few cycles, add some more cycles and additional complexity. My advice is to avoid the patch; however, be advised if used it might not work in future as the code is further refined. Dave Jan Ceuleers wrote: > I came across the following page: > > http://www.lesswatts.org/projects/powertop/known.php > > which says the following on ntpd: > > "By default, the ntp time synchronization daemon will wake up once per > second, and will make the kernel do work on it's behalf even more. Red > Hat has created a patch to ntp to fix this issue and ships it in their > rawhide and FC7 ntp packages. You can download this patch from the > Fedora cvs server." > > Has anyone here looked at that patch? Does it compromise correctness of > the algorithms? > > Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
"David L. Mills" <[EMAIL PROTECTED]> writes: >Jan, >A timer interrupt is required each second to update the clock frequency >no matter what. In addition, a sweep is made through the associations to I thought that the ntp daemon runs the per second routine only if the kernel discipline is not available. And Linux I thought has the kernel discipline. Now of course I suspect that the kernel has to wake itself even more often than once a second (eg the timer interrupt) and if it did not, the effect on the time discipline would be pretty bad. >see if a poll is pending. It would be in principle posssible to >implement a system of queues to avopid sweeping the associations each >second, but that would save very few cycles, add some more cycles and >additional complexity. My advice is to avoid the patch; however, be >advised if used it might not work in future as the code is further refined. >Dave >Jan Ceuleers wrote: >> I came across the following page: >> >> http://www.lesswatts.org/projects/powertop/known.php >> >> which says the following on ntpd: >> >> "By default, the ntp time synchronization daemon will wake up once per >> second, and will make the kernel do work on it's behalf even more. Red >> Hat has created a patch to ntp to fix this issue and ships it in their >> rawhide and FC7 ntp packages. You can download this patch from the >> Fedora cvs server." >> >> Has anyone here looked at that patch? Does it compromise correctness of >> the algorithms? >> >> Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Bill, Bill Unruh wrote: > Now of course I suspect that the kernel has to wake itself even more often > than once a second (eg the timer interrupt) and if it did not, the effect > on the time discipline would be pretty bad. The Linux kernel has recently gone tickless, meaning that it only schedules a wakeup for itself at the first time that it knows a timer will expire. A quick intro on that can be found here: http://www.lesswatts.org/documentation/silicon-power-mgmnt/#ticklessidle Cheers, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
