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
Re: [ntp:questions] Power-saving patch to NTP
Jan Ceuleers wrote: 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: Given the Linux kernel developers' past history of breaking NTP, have they made all the necessary enhancements to gettimeofday to ensure that it progresses the kernel discipline correctly to account for the missing updates. (Of course it also needs to do the same when it does schedule a clock event. Have they considered the resulting increased processing time, and more importantly, variability in processing time of gettimeofday? To really go tickless well with NTP you need to move the kernel time discipline into the hardware! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
David Woolley wrote: Have they considered the resulting increased processing time, and more importantly, variability in processing time of gettimeofday? That's why I'm raising the question here. If anyone on the ntpd team has contacts at Red Hat, a brief discussion about this would be of considerable help. KR, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual Mixer Time Difference (DMTD) instruments sought
In article [EMAIL PROTECTED], jlevine [EMAIL PROTECTED] wrote: 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. This is precisely the kind of pointer I was hoping for. Thanks. 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. That isn't bad for 1980 analog electronics. I think that the 5120 is the digital realization, as discussed in other postings. That said, the 5120 is temperature sensitive, and one had to allow many hours for temperatures to stabilize, but then the resolution appeared to be about 0.01 pS. I assume that the improvement from 0.2 pS was due to the fancy matched-mixers trick, combined with use of a very low noise oscillator. 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.) As I said, I don't think I will be building such an instrument. But it's just this kind of nitty gritty detail I want to be aware of, for interest, and for self-protection in the lab. 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. What we were doing was to measure the temperature coefficient of electrical length of a temperature-stable 10 MHz distribution amplifier, the goal being a tempco not exceeding 1.0 pS per degree centigade. Some of the tested amps achieve ~0.5 pS/degree C, in a total delay of ~4.5 nanoseconds, or ~111 ppm per degree C, call it 100 ppm. The test consisted of measuring changes in total delay at three temperatures, 17, 24, and 31 degrees C. The problem is that it took at least an hour for the amplifier to stabilize at each temperature, so instrument drift is a significant source of error. The measured RC time constant of delay of the amplifier in chamber is 14 minutes. My solution was to compare the amplifier under test to a mechanical variable delay unit (Colby Instruments PDL-100A-625PS-5.0NS), using a fast sampling scope (200 femtosecond rms jitter(?), averaged down to ~50 fS) as the null detector. The specific circuit is a low-noise oscillator (Symmetricom 1050A) driving the first splitter, one output driving the scope sync input, the other driving the input of the second splitter. One output of the second splitter drives the reference path, which contains the variable delay unit. The other output drives the device path, which contains the amplifier under test. Both device and reference path cables pass through the environmental chamber, with the heated lengths held equal. The cables are low tempco as well (~1.5 ppm per degree C). Everything was 50-ohm, at least nominally, but no attempt at precision matching or isolation was made, and the connectors and adapters were a mix of whatever could be scrounged up in the lab. This setup yielded clean data, easily sufficient to the purpose. The main limits to accuracy appear to be hysteresis in the amplifiers under test, and the cyclic temperature variation of the environmental chamber itself. If you are in this business then you need professional help. Heh. I've been told this before, but the issue
Re: [ntp:questions] Power-saving patch to NTP
I've built some RPMs for CentOS using the latest SRC from the FC9 branch. They include that patch and I've noticed no discernable difference in time keeping and everything appears to be functioning as it should. Jason 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, I have no idea what you are talking about in the timer interrupt issue. By timer interrupt I mean the kernel facility to create a program interrupt at specified times, in this case once each second. Even if the kernel discipline is in use the one-second interrupt is still used to scan for poll events and several other things, like key expiry, interface scan, etc. In modern machines a timer interupt takes about one microsecond and to scan through the one-second code is really quick. So, we are talking about an overhead in the order of .1 percent. A more contentious issue is that the interrupt could cause a swapped-out ntpd process to be dragged back in. If this could be the case, the use of NTP is not justified in the first place and should be replaced by something else. Dave Bill Unruh wrote: 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
David L. Mills [EMAIL PROTECTED] writes: Bill, I have no idea what you are talking about in the timer interrupt issue. The 18 or 100 or 250 or 1000 Hz timer interrupt. And if they do not occur (lost ticks) problems arise. By timer interrupt I mean the kernel facility to create a program interrupt at specified times, in this case once each second. Even if the Which I believe rides on the coattails of the harware time interrupt. kernel discipline is in use the one-second interrupt is still used to scan for poll events and several other things, like key expiry, interface scan, etc. In modern machines a timer interupt takes about one microsecond and to scan through the one-second code is really quick. So, we are talking about an overhead in the order of .1 percent. A more contentious issue is that the interrupt could cause a swapped-out ntpd process to be dragged back in. If this could be the case, the use of NTP is not justified in the first place and should be replaced by something else. Fair enough. Dave Bill Unruh wrote: 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
Miroslav, You said it exactly slam-dunk right on the head. Timer queue facilities are tricky and can be absolutely awful to debug when something doesn't work right. I know this, as I built what might now be called a tickless kernel for the PDP11 fuzzball in 1979. It did avoid program interrupts to increment timers, which was important in those old, slow machines, but it did require considerable overhead to scan, insert and remove queue entries and worry about hash tables. If you have been with this project for many years, you know a timer queue facility was once implemented in xntpd and carried over to early ntpd. However, it was fragile, poorly implemented, impossible to maintain and eventually was ripped out. You can understand my reluctance to repeat that adventure. Over the years there have been a number of occasions where somebody dumps something on the distributution and then disappears. Ten years later I stumble over it because it has broken something, then realize it never did work properly, so I rip it out. But the real slam-dunk issue is who is going to maintain the facility if it is incorporated in ntpd? How will it affect future enhancements? Is it to be optional and enabled by defines and configure? If Linux folks think it necessary and maintain it, nobody here needs to worry. However, the Linux folks might have to worry if something in the distribution changes and the patch doesn't work any more. Dave Miroslav Lichvar wrote: On Thu, May 15, 2008 at 06:51:24PM +0200, 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? A bug report for this issue is here: https://support.ntp.org/bugs/show_bug.cgi?id=802 There are two different patches, the first one is just looking ahead for the next event and it should be safe to use (at least on Linux). The second patch implements a queue timer, it is more complex and harder to maintain. In the Fedora CVS is maintained the first patch, a version for the latest stable ntp release can also be found there. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 16, 12:29 pm, David L. Mills [EMAIL PROTECTED] wrote: In modern machines a timer interupt takes about one microsecond and to scan through the one-second code is really quick. So, we are talking about an overhead in the order of .1 percent. In terms of performance, yes, but in terms of power, no. If NTP gets the CPU out of a deep stand-by state, then it may take hundreds of milliseconds for the CPU to go back to that state. Moreover, NTP 1s- timer may prevent the CPU from going to even deeper stand-by states. With this in mind, if NTP wakes the CPU up in order to do nothing, it's not doing the right thing, IMHO. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 15, 9:28 pm, David L. Mills [EMAIL PROTECTED] wrote: 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. NTP could set a reminder for itself not for the next second, in case there's a poll pending, but for the minimum period left among all polled servers. This would be pretty simple and power-friendly. Mind you, a CPU uses orders of magnitude less power in a stand-by state, even a simple halt-instruction, than running. See page 3 of http://download.intel.com/technology/itj/2006/volume10issue02/vol10_art03.pdf for more info. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Bill, I've have reports of folks using kernel timer interrupts at 10,000 Hz in Linux. That has nothing to do with ntpd, only the fact that ntpd expects to be called by the kernel timer routines once per second. Dave David L. Mills [EMAIL PROTECTED] writes: Bill, I have no idea what you are talking about in the timer interrupt issue. The 18 or 100 or 250 or 1000 Hz timer interrupt. And if they do not occur (lost ticks) problems arise. By timer interrupt I mean the kernel facility to create a program interrupt at specified times, in this case once each second. Even if the Which I believe rides on the coattails of the harware time interrupt. kernel discipline is in use the one-second interrupt is still used to scan for poll events and several other things, like key expiry, interface scan, etc. In modern machines a timer interupt takes about one microsecond and to scan through the one-second code is really quick. So, we are talking about an overhead in the order of .1 percent. A more contentious issue is that the interrupt could cause a swapped-out ntpd process to be dragged back in. If this could be the case, the use of NTP is not justified in the first place and should be replaced by something else. Fair enough. Dave Bill Unruh wrote: 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
Evandro, With respect, you miss the point. The ntpd does not require a tickle every second just to scan for polls; it requires that tickle in order to discipline the clcok frequency. The additional cycles necessary to link to the next association structure, then increment and test a variable, are way, way down in the noise. Folks might not appreciate just how many counters are coincident with the one-second interrupt. Every association has both a poll counter and headway counter. Every cryptotraphic key has a lifetime counter. Several drivers, includiing the WWVB and ACTS drivers, have internal counters for protocol purposes. There are seconds counters for interface refresh, autokey protocol cookie refresh, leapsecond countdown and hourly statistics. While some of these functions could be managed by a timer queue facility, most of the counters are routinely preempted. With a timer queue facility, these operations would require overhead to sort queues and manage hash tables. Since a one-second interrupt is necessary anyway, extra complexity is simply not justified. Dave Evandro Menezes wrote: On May 15, 9:28 pm, David L. Mills [EMAIL PROTECTED] wrote: 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. NTP could set a reminder for itself not for the next second, in case there's a poll pending, but for the minimum period left among all polled servers. This would be pretty simple and power-friendly. Mind you, a CPU uses orders of magnitude less power in a stand-by state, even a simple halt-instruction, than running. See page 3 of http://download.intel.com/technology/itj/2006/volume10issue02/vol10_art03.pdf for more info. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] How does NTP calculate peer accuracy?
I'm fine with that as long as it doesn't break the current usage. This all belongs in the parser and the ntp_config.c code. Danny David L. Mills wrote: Danny, You might recall the message that started the discussion was from a dude that wanted to selectively listen on one broadcast subnet but not another. I proposed to add a list of addresses to the broadcastclient command and include both original broadcast as well as multicast, just like the broadcast command now. I did not intend to remove the curent multicastclient command nor novolley option in the interest of backward compatibility. You invite me to change the manycast commands, presumably because nobody uses them and backwards compatibilty doesn't matter. You might be right. Dave Danny Mayer wrote: Dave, My concern there was with the config file, user confusion and compatibility. On the matter of manycast I believe that is in the ntp_config.c code and you can change it in any way you choose. Danny David L. Mills wrote: Danny, I prposed unifying the broadcastclient and multicastclient commands and making the distinction on the basis of specified address. This is similar to the way the broadcast command works now and would lesson confusion. As I recall, you were not thrilled with that idea. I did not intend to make a pissing contest over this, only a suggestion. Whether the code to do this is in the I/O scope or related, I am incompetent to muck there. Dave ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Evandro and others, Now it's me that missed the point. I didn't realize you were concerned about a milliwatt or two every second. My first kneejerk reaction was why would you use ntpd on a laptop under conditions where it might sleep? Better to kill it before sleeping and restart when waking up. My second jerk was, even if the seconds interrupt could be avoided, there are still arriving and departing packets. I assume this wakes the beast, although at 1024 s poll, that might not be a problem. Well, let's consider the case of a tickless ntpd and see what breaks. The first thing that breaks is the frequency discipline. As somebody mentioned, that can be done in the kernel on the assumption that tick interrupts dyill work. At a tick interrupt rate of 1000 Hz, this doesn't seem a good idea. Or maybe the hardware can be programmed to adjust the frequency. The frequency needs to be desciplined to the order of a few parts in 10^9, which would require some unusual chipset capabilities. A second approach might be to abandon frequency discipline except when a packet shows up, which with laptops I know will considerably degrade the accuracy, probablly to many tens of milliseconds, but this might not matter if the machine is sleeping. When it comes awake; however, there will ee nasty transient. Even more clever, anticipate the change due to the calibrated frequency error and yank accordingly. To do this, however, means a substantial modification of the clock discipline algorithm and some kind os switch to know when to do this. Next, just dropping in a timer queue facility makes no sense unless those peskty seconds counters can be replaced by calculated intervals that may have to be recalculated when some event or other happens. To do this is a major redesign job. Even considering the effort and testing requiree, it might be a worthwhile project better suited to an implementation other than ntpd. Maybe openNTP or chrony would be a better place to start. Better yet, take the ntp_proto.c module from thedistribution, throw everything else out and rebuild the infrastructure specialized for laptops. I must disclose I have an ulterior motive here, since an approach like this is needed for spacecraft. Dave Evandro Menezes wrote: On May 16, 12:29 pm, David L. Mills [EMAIL PROTECTED] wrote: In modern machines a timer interupt takes about one microsecond and to scan through the one-second code is really quick. So, we are talking about an overhead in the order of .1 percent. In terms of performance, yes, but in terms of power, no. If NTP gets the CPU out of a deep stand-by state, then it may take hundreds of milliseconds for the CPU to go back to that state. Moreover, NTP 1s- timer may prevent the CPU from going to even deeper stand-by states. With this in mind, if NTP wakes the CPU up in order to do nothing, it's not doing the right thing, IMHO. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
