Re: [ntp:questions] Power-saving patch to NTP
Garrett Wollman wrote: In article [EMAIL PROTECTED], Martin Burnicki [EMAIL PROTECTED] wrote: AFAIK ntpd has to manage the binding to interfaces at least if autokey is enabled since the signature hash also includes the IP address of the interface via which a packet is sent. At least some operating systems (don't know about Linux) allow this to be controlled using a control message. For example, from the FreeBSD 6.3 ip(4) manual page: The source address to be used for outgoing UDP datagrams on a socket that is not bound to a specific IP address can be specified as ancillary data with a type code of IP_SENDSRCADDR. The msg_control field in the msghdr structure should point to a buffer that contains a cmsghdr structure fol- lowed by the IP address. The cmsghdr fields should have the following values: cmsg_len = sizeof(struct in_addr) cmsg_level = IPPROTO_IP cmsg_type = IP_SENDSRCADDR For convenience, IP_SENDSRCADDR is defined to have the same value as IP_RECVDSTADDR, so the IP_RECVDSTADDR control message from recvmsg(2) can be used directly as a control message for sendmsg(2). The IPV6_PKTINFO message is used for analogous functions in IPv6. -GAWollman We are aware of sendmsg(), recvmsg() and friends. The problem, however, is that there are many platforms that do not support this yet. It's a major effort to deal with this. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Martin Burnicki wrote: Garrett, Garrett Wollman wrote: In article [EMAIL PROTECTED], Martin Burnicki [EMAIL PROTECTED] wrote: AFAIK ntpd has to manage the binding to interfaces at least if autokey is enabled since the signature hash also includes the IP address of the interface via which a packet is sent. At least some operating systems (don't know about Linux) allow this to be controlled using a control message. For example, from the FreeBSD 6.3 ip(4) manual page: The source address to be used for outgoing UDP datagrams on a socket that is not bound to a specific IP address can be specified as ancillary data with a type code of IP_SENDSRCADDR. The msg_control field in the msghdr structure should point to a buffer that contains a cmsghdr structure fol- lowed by the IP address. The cmsghdr fields should have the following values: cmsg_len = sizeof(struct in_addr) cmsg_level = IPPROTO_IP cmsg_type = IP_SENDSRCADDR For convenience, IP_SENDSRCADDR is defined to have the same value as IP_RECVDSTADDR, so the IP_RECVDSTADDR control message from recvmsg(2) can be used directly as a control message for sendmsg(2). The IPV6_PKTINFO message is used for analogous functions in IPv6. -GAWollman That's interesting. However, I'm neither familiar with those techniques, nor do I know whether such an approach would be useful for ntpd, especially since ntpd is targeted for multiple platforms (Frank? Danny?) Martin See BIND9 which uses it where possible. The requirements are different on NTP but there are different issues that need to be addressed. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Garrett, Garrett Wollman wrote: In article [EMAIL PROTECTED], Martin Burnicki [EMAIL PROTECTED] wrote: AFAIK ntpd has to manage the binding to interfaces at least if autokey is enabled since the signature hash also includes the IP address of the interface via which a packet is sent. At least some operating systems (don't know about Linux) allow this to be controlled using a control message. For example, from the FreeBSD 6.3 ip(4) manual page: The source address to be used for outgoing UDP datagrams on a socket that is not bound to a specific IP address can be specified as ancillary data with a type code of IP_SENDSRCADDR. The msg_control field in the msghdr structure should point to a buffer that contains a cmsghdr structure fol- lowed by the IP address. The cmsghdr fields should have the following values: cmsg_len = sizeof(struct in_addr) cmsg_level = IPPROTO_IP cmsg_type = IP_SENDSRCADDR For convenience, IP_SENDSRCADDR is defined to have the same value as IP_RECVDSTADDR, so the IP_RECVDSTADDR control message from recvmsg(2) can be used directly as a control message for sendmsg(2). The IPV6_PKTINFO message is used for analogous functions in IPv6. -GAWollman That's interesting. However, I'm neither familiar with those techniques, nor do I know whether such an approach would be useful for ntpd, especially since ntpd is targeted for multiple platforms (Frank? Danny?) Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe Klein wrote: Martin Burnicki wrote: Agreed. However, you can at least configure the dynamic interface scan interval using the -U parameter, so you can decide if you prefer short response times or a longer response time with maybe decreased power requirements. push a trigger for this into ntpdc? I think that would be an ugly workaround. The proper solution would be to use the mechanisms which are available for such purposes. [...] A question: what would happen if one throws out binding to select interfaces and instead pushes this out to the firewall/ip-tables infrastructure? I don't know whether this would be possible, and if it would make sense. AFAIK ntpd has to manage the binding to interfaces at least if autokey is enabled since the signature hash also includes the IP address of the interface via which a packet is sent. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
In article [EMAIL PROTECTED], Martin Burnicki [EMAIL PROTECTED] wrote: AFAIK ntpd has to manage the binding to interfaces at least if autokey is enabled since the signature hash also includes the IP address of the interface via which a packet is sent. At least some operating systems (don't know about Linux) allow this to be controlled using a control message. For example, from the FreeBSD 6.3 ip(4) manual page: The source address to be used for outgoing UDP datagrams on a socket that is not bound to a specific IP address can be specified as ancillary data with a type code of IP_SENDSRCADDR. The msg_control field in the msghdr structure should point to a buffer that contains a cmsghdr structure fol- lowed by the IP address. The cmsghdr fields should have the following values: cmsg_len = sizeof(struct in_addr) cmsg_level = IPPROTO_IP cmsg_type = IP_SENDSRCADDR For convenience, IP_SENDSRCADDR is defined to have the same value as IP_RECVDSTADDR, so the IP_RECVDSTADDR control message from recvmsg(2) can be used directly as a control message for sendmsg(2). The IPV6_PKTINFO message is used for analogous functions in IPv6. -GAWollman -- Garrett A. Wollman | The real tragedy of human existence is not that we are [EMAIL PROTECTED]| nasty by nature, but that a cruel structural asymmetry Opinions not those | grants to rare events of meanness such power to shape of MIT or CSAIL. | our history. - S.J. Gould, Ten Thousand Acts of Kindness ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe Klein wrote: David Woolley wrote: Evandro Menezes wrote: HLT instructions are a complete red herring here. They've been available Modern CPUs, chipsets and OSes have a wide range of features to manage I'm aware of that. power _and_ these are heavily used on any platform, be it PDA, Laptop, embedded device .. or Numbercrunching Cluster. My argument is that these aren't or shouldn't be important for servers. The current trend seems to be dedicated boxes or myriads of VM-boxes on a mainframe which depends heavily on a VM-box being suspended when it is idle. That only requires the 1970s (or earlier) HLT technology and multi-tasking friendly applications; generally Unix applications are friendly but some Windows applications, particularly from five or more years ago, aren't (although they tend to be desk top ones). I haven't looked into how the VM people handle timekeeping though. A typical solution is to run ntpd on the host system and run some code that is virtualisation aware and can peek at the host system, to, in some proprietary way, align the virtual software clock with the host software clock. Trying to run time synchronisation directly on the guest is a recipe for disaster. One impact of virtualisation is that the virtual machines cannot coordinate their timer interrupts unless they include extensive virtualisation aware code. My impression is that the VMWare code doesn't go anything like that far. Also, as I understand it, enterprise (i.e. expensive) virtualisation software can move running guests between hosts, so, whilst that would be rather bad for timing critical applications, one imagines the best power management strategy is to concentrate the active systems on a few hosts and completely power down any others. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe, Uwe Klein wrote: [...] There is actually another situation where currently ntp is just killed of and started again: network interface changes. This could be handled in a less disruptive way as well. The next releases (i.e. v4.2.4p5 and v4.2.6) will support interface changes much better than older versions, at least after startup. That means ntpd detects when new interfaces have appeared, or interfaces have disappeared, and handles those cases well. That also means those versions of ntpd work well if started before any interfaces are available, and initial DNS resolution is delayed until it succeeds. Unfortunately Linux uses an implementation of network sockets which differs from the implementation in other Unices, so ntpd does not receive notifications on interface changes under Linux. Instead, ntpd has to scan the interfaces in certain intervals to see if something has changed. Also, those versions of ntpd will still not redo DNS lookups for existing associations, e.g. to discover when the IP address of an upstream NTP server has changed. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ 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: Evandro Menezes wrote: And, please, don't consider the power used by NTP itself, but rather the power used by the CPU idling in a higher power state than before NTP woke it up. Modern processors can draw 100W without doing anything useful, but it falls down to less than 10W it it's allowed run the HALT instruction instead when there's nothing to do. HLT instructions are a complete red herring here. They've been available Modern CPUs, chipsets and OSes have a wide range of features to manage power _and_ these are heavily used on any platform, be it PDA, Laptop, embedded device .. or Numbercrunching Cluster. But you've already told us that you get a 90% power saving before you go to the deep state. In my view, a server that is running at a sufficiently low CPU load that going deeper that HLT is useful is badly over-dimensioned. The current trend seems to be dedicated boxes or myriads of VM-boxes on a mainframe which depends heavily on a VM-box being suspended when it is idle. I haven't looked into how the VM people handle timekeeping though. If high load depends on time of day, you will have to dimension air conditioning for peak loading (which means times when you will never go .. efficiency costs. I am not into collocation management, but: My guess is that the required power and AC scaling is similar to what you get in telephone exchange scaling ( i.e. it evens out rather fast across all boxes. Primary issue is simultaneous PowerUp for a complete site. ( You fix that via staging ) Tactics for smoothing the load and achieving high productive utilisation where common when capital cost was the main issue. Cost distribution has changed. boxes are cheap, manpower not, energy costs are rising fast. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Hi Martin, Martin Burnicki wrote: The next releases (i.e. v4.2.4p5 and v4.2.6) will support interface changes much better than older versions, at least after startup. Unfortunately Linux uses an implementation of network sockets which differs from the implementation in other Unices, so ntpd does not receive notifications on interface changes under Linux. Instead, ntpd has to scan the interfaces in certain intervals to see if something has changed. polling is imho the least pleasant solution. The trend (in linux) is towards waiting on events/signaling. IMHO having ntp react to signaling of some kind or other would suffice. d-bus or the if-up if-down scripts should be able to give all the information wanted? uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Hi Uwe, Uwe Klein wrote: Hi Martin, Martin Burnicki wrote: The next releases (i.e. v4.2.4p5 and v4.2.6) will support interface changes much better than older versions, at least after startup. Unfortunately Linux uses an implementation of network sockets which differs from the implementation in other Unices, so ntpd does not receive notifications on interface changes under Linux. Instead, ntpd has to scan the interfaces in certain intervals to see if something has changed. polling is imho the least pleasant solution. Agreed. However, you can at least configure the dynamic interface scan interval using the -U parameter, so you can decide if you prefer short response times or a longer response time with maybe decreased power requirements. The trend (in linux) is towards waiting on events/signaling. That's what the network routing socket support would do (I think this is called the netlink layer under Linux). However, someone would have to implement this for Linux, and also for Windows. See: https://support.ntp.org/bugs/show_bug.cgi?id=992 (Linux) https://support.ntp.org/bugs/show_bug.cgi?id=991 (Windows) IMHO having ntp react to signaling of some kind or other would suffice. d-bus or the if-up if-down scripts should be able to give all the information wanted? AFAIK this would currently only be possible by adding/removing upstream servers via ntpdc, which can be run from the if-up if-down scripts. I'm not sure where this had to be done if the network manager is used instead of if-up/if-down, e.g. in openSUSE. Supporting d-bus would also require some Linux-specific code which had to be written by someone. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Martin Burnicki wrote: Hi Uwe, Uwe Klein wrote: Hi Martin, Martin Burnicki wrote: The next releases (i.e. v4.2.4p5 and v4.2.6) will support interface changes much better than older versions, at least after startup. Unfortunately Linux uses an implementation of network sockets which differs from the implementation in other Unices, so ntpd does not receive notifications on interface changes under Linux. Instead, ntpd has to scan the interfaces in certain intervals to see if something has changed. polling is imho the least pleasant solution. Agreed. However, you can at least configure the dynamic interface scan interval using the -U parameter, so you can decide if you prefer short response times or a longer response time with maybe decreased power requirements. push a trigger for this into ntpdc? The trend (in linux) is towards waiting on events/signaling. That's what the network routing socket support would do (I think this is called the netlink layer under Linux). However, someone would have to implement this for Linux, and also for Windows. See: https://support.ntp.org/bugs/show_bug.cgi?id=992 (Linux) https://support.ntp.org/bugs/show_bug.cgi?id=991 (Windows) IMHO having ntp react to signaling of some kind or other would suffice. d-bus or the if-up if-down scripts should be able to give all the information wanted? AFAIK this would currently only be possible by adding/removing upstream servers via ntpdc, which can be run from the if-up if-down scripts. I'm not sure where this had to be done if the network manager is used instead of if-up/if-down, e.g. in openSUSE. No idea, networkmanager is rather new to me ( you can still select between if-up/down/networkmanager while configuring interfaces) Supporting d-bus would also require some Linux-specific code which had to be written by someone. Yeah, right, one just can't get rid of human intervention ;-) ( I have been thinking about a d-bus package for tcl...) A question: what would happen if one throws out binding to select interfaces and instead pushes this out to the firewall/ip-tables infrastructure? Martin uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Nero Imhard wrote: I think people should avoid full ntp as standard, general-purpose timekeeping solution for every small device on the planet. It is not. N If I have a hammer at hand every problem is a nail ;-) There seem to be not that many alternatives? ntp, the original Chrony OpenNTPd Openrdate libmsntp I used to insert just the DCF77 Signal as a bit in aquired data.(10ms/sample) and later decode and align the data to the served up time. ( Having the system freeruning with a stable clock.) But with distributed systems the requirements are different. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 19, 2:32 am, David Woolley [EMAIL PROTECTED] wrote: HLT instructions are a complete red herring here. They've been available for over 35 years, to my personal knowledge, and probably a lot more than that. No mainstream Linux, and probably no Linux has not used them. Quite the contrary. Linux has been using HLT for over a decade now ans has always sported better power efficiency than Windows until it started to do so too with Windows 2000. HLT is special in power management terms in that it doesn't require heuristics on anything better than MSDOS, for any application that is at all multi-tasking friendly. Mind you, HLT is merely the first line of defense in power management. HLT makes the CPU enter C1-state, but then the OS guides it when to enter the deeper power-saving C2 and C3 states. But you've already told us that you get a 90% power saving before you go to the deep state. In my view, a server that is running at a sufficiently low CPU load that going deeper that HLT is useful is badly over-dimensioned. Would you deal with an ideal world or with what is out there? the duty cycle resulting from the heuristics used by the hardware or the OS to decide when to place the CPU in a deep C-state. [A] I suspect it is actually single figure nano-seconds on modern machines. No, it's not. And I don't say it out of a vague suspicion, but out of knowledge gained when designing the algorithms at AMD, later used by both Windows and Linux. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On Mon, May 19, 2008 at 3:13 AM, Uwe Klein [EMAIL PROTECTED] wrote: I haven't looked into how the VM people handle timekeeping though. I have. The answer is... rather poorly. But probably as best as can be done without the OS knowing it is being virtualized. For more information, see: http://www.vmware.com/pdf/vmware_timekeeping.pdf -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
From: David Woolley [EMAIL PROTECTED] Date: Mon, 19 May 2008 08:32:37 +0100 Sender: [EMAIL PROTECTED] Evandro Menezes wrote: And, please, don't consider the power used by NTP itself, but rather the power used by the CPU idling in a higher power state than before NTP woke it up. Modern processors can draw 100W without doing anything useful, but it falls down to less than 10W it it's allowed run the HALT instruction instead when there's nothing to do. HLT instructions are a complete red herring here. They've been available for over 35 years, to my personal knowledge, and probably a lot more than that. No mainstream Linux, and probably no Linux has not used them. The recovery time to a HLT state from an interrupt service routine should be 10s of nanoseconds[A], although high level language ISRs may compromise this, and from user level, should be of the order of half the context switch time, which ought to be well under one microsecond. These are the normal exit times, and may actually be shorter than to busy idle. HLT is special in power management terms in that it doesn't require heuristics on anything better than MSDOS, for any application that is at all multi-tasking friendly. The picture that Red Hat refers to is that the CPU is removed from a deep C-state in order to run NTP for microseconds and then it remains in the running state for a few fractions of a second until it goes back to a deep C-state. So it's not a matter of NTP's duty cycle, but But you've already told us that you get a 90% power saving before you go to the deep state. In my view, a server that is running at a sufficiently low CPU load that going deeper that HLT is useful is badly over-dimensioned. If high load depends on time of day, you will have to dimension air conditioning for peak loading (which means times when you will never go deeper than HLT), which will determine capital costs, and probably some of the running costs. If you are getting significant energy bills, you are likely to be on a peak usage tariff, and from an environmental point of view, is it much better, once you've created the manufacturing costs for the server, to get maximum economic value from it by marketing low priority work for it. This also applies to the electricity generation and transmission infrastructure, which needs to be dimensioned for maximum load, and needs to contain components, which tend not to be environmentally friendly, to server short terms peaks (not everyone can pump water uphill in low demand times, and even that has capital and efficiency costs. Tactics for smoothing the load and achieving high productive utilisation where common when capital cost was the main issue. the duty cycle resulting from the heuristics used by the hardware or the OS to decide when to place the CPU in a deep C-state. [A] I suspect it is actually single figure nano-seconds on modern machines. I've been following this thread for a while and it is clear that many (most?) people are not aware of modern power management at the hardware level in modern systems. It has changes a LOT since the days of the simple HLT instruction. Most of this was originally developed for mobile systems, but now it has migrated to servers where power savings are increasingly important. In olden days, when the CPU had nothing to do, it was halted. This reduced the power required to around 10% (depending on details of the particular CPU design). This has been the case for years and continues to be the case. This is not the time or place for an ACPI tutorial, but ACPI allows for much finer grained power management that not only reduces the power required by the CPU, but by much of the system through the use of power states. Now days, if the OS supports it, when a system is halted it does not simply halt the CPU. It initiates a series of power saving steps according to the rules set up by the OS. These are normally referred to as sleep states and has nothing to do with suspend operations such as suspend to RAM or suspend to disk. On most newer systems, if the OS enables it, if the system remains halted for over one CPU clock cycle, it drops from C1 state halted into C2 deeper sleep and this further reduces power use. It just takes a bit longer to get going again. If the system remains halted for a longer time, it drops into C3 state which further reduces power use. On my laptop, this takes 85 clock cycles to recover and start processing instructions again. Some systems now support even more sleep states, some taking hundreds of clock cycles to fully wake up. My laptop running FreeBSD typically spends over 80% of the time in C3 or C4 and the power savings when these states are enabled is substantial. To enhance the effects of this capability, many OSes, notably Linux, have started making significant modifications to the kernel and especially the scheduler to allow the
Re: [ntp:questions] Power-saving patch to NTP
Evandro, I don't know wwhat CPU you have, but mine doesn't boil 100 W all the time. You realize that is 30 A at 3.3 V. As I have said several times, if you expect ntpd to discipline the frequency, the CPU needs to nudge the time on a regular basis, like once per second. It could be less often with the penalty being increased sawtooth error. If this is objectional, for goodness sake don't use ntpd. I feel very stongly that the present discussion is a colossal red herring and has nothing whatsoever to do with the present ntpd design. The present design is optimized as a compromise between a casual workstation and a busy server with 3000 packets per second. Make a new product specification and discontinue any mention of ntpd. Dave Evandro Menezes wrote: On May 16, 6:44 pm, David L. Mills [EMAIL PROTECTED] wrote: 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. I don't pretend to know NTP innards, but wouldn't it be possible to select the scale of updates? And, please, don't consider the power used by NTP itself, but rather the power used by the CPU idling in a higher power state than before NTP woke it up. Modern processors can draw 100W without doing anything useful, but it falls down to less than 10W it it's allowed run the HALT instruction instead when there's nothing to do. The picture that Red Hat refers to is that the CPU is removed from a deep C-state in order to run NTP for microseconds and then it remains in the running state for a few fractions of a second until it goes back to a deep C-state. So it's not a matter of NTP's duty cycle, but the duty cycle resulting from the heuristics used by the hardware or the OS to decide when to place the CPU in a deep C-state. 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 19, 12:53 pm, David L. Mills [EMAIL PROTECTED] wrote: I don't know wwhat CPU you have, but mine doesn't boil 100 W all the time. You realize that is 30 A at 3.3 V. Worse yet, given that the typical core voltage is 1.5V, that's actually 67A! You read that right. But you're free to check for yourself an example on page 32 of http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/30417.pdf where the CPU core current can be anywhere between 66A under load and 8A in the halted stated. I feel very stongly that the present discussion is a colossal red herring and has nothing whatsoever to do with the present ntpd design. I really think that it'll bite you eventually, but if you prefer to ignore it at the moment... Thanks. ___ 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 wrote: Uwe, Problem is that, while GPS could in principle provide guidance beyond Earth space, the signal strength is not sufficient for Moon navigation. Right. emphasis was on GPS _like_ This would have to be a new system. Are there any nonregular effects in space transmissions? I think not. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Danny Mayer wrote: It's not doing nothing. If the CPU is on standby nothing, including ntpd, should be running. ntp would then need to accomodate thinks like a sleep mode? and a trigger of type Query the associations now ( on linux forex be d-bus aware? ) The basic assumptions about the host systems ntp runs on are changing fast! uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe Klein wrote: Danny Mayer wrote: It's not doing nothing. If the CPU is on standby nothing, including ntpd, should be running. ntp would then need to accomodate thinks like a sleep mode? and a trigger of type Query the associations now ( on linux forex be d-bus aware? ) The impression I get is that ntpd should be treated as infrastructure, and have power management states, but Red Hat are treating it as an errant application that needs to be modified to avoid upsetting the power management apple cart. E.g. after resume from RAM, it needs to progress the clock discipline algorithm forwards (including extra corrections for temperature excursions) before anything is allowed to read the value of the clock, and after resume from disk, it should probably do a restart. The latter greatly increases the importance of fast convergence, and without specific compensation for temperature variation, even resume from RAM needs the ability to respond fast to frequency hits, possibly conditioned on just having done a resume. The basic assumptions about the host systems ntp runs on are changing fast! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe Klein [EMAIL PROTECTED] writes: David Woolley wrote: Uwe Klein wrote: Danny Mayer wrote: It's not doing nothing. If the CPU is on standby nothing, including ntpd, should be running. ntp would then need to accomodate thinks like a sleep mode? and a trigger of type Query the associations now ( on linux forex be d-bus aware? ) The impression I get is that ntpd should be treated as infrastructure, and have power management states, but Red Hat are treating it as an errant application that needs to be modified to avoid upsetting the power management apple cart. Hello David, I am not surprised. Linux presents afaik the biggest userbase for ntp (and is simultanously the most derided group of questioneers in this NG, though i think compared to the installed instances linux is imho underrepresented). If a large group is beat over the head in a somewhat regular fashion ( which may have been just a cats and dogs thing ) it is rather unsurprising to find those people working around this obstacle. I certainly have no idea what you are talking about. What derision? What beat over the head? What obstacle? E.g. after resume from RAM, it needs to progress the clock discipline algorithm forwards (including extra corrections for temperature excursions) before anything is allowed to read the value of the clock, and after resume from disk, it should probably do a restart. Well it should start with ntp getting signaled to prepare for various modes of sleep or cpu frequency slowdown. Save as much state as is possible, then ack for sleep. There is actually another situation where currently ntp is just killed of and started again: network interface changes. This could be handled in a less disruptive way as well. The latter greatly increases the importance of fast convergence, and without specific compensation for temperature variation, even resume from RAM needs the ability to respond fast to frequency hits, possibly conditioned on just having done a resume. Whichever way one does this ntp needs to be able to respond to finer grained external triggers. It can not any longer be King of the Castle. No idea what this means either. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Unruh wrote: I am totally confused. The cpu is in sleep mode. The cpu is not doing anything. ntp is NOT running. ntp cannot wake up the cpu because ntp is not running. Only external events can wake up the cpu, and ntp is not an external event. So, once the cpu is woken up, and ntp can run, what does it matter if ntp then runs? Ntp runs whenever one of the pieces of hardware it watches reports an event. One of those is the once-per-second wakeup call. But as I said elsewhere in this thread, I don't think that the important thing is ntpd's own power footprint, but rather the implications of the platform's attempts at saving power. Or as someone else put it: the basic assumptions ntpd makes of the behaviour of the platform (hardware and OS) while it's _not_ running (i.e. between invocations of itself). Cheers, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Unruh wrote: I am totally confused. The cpu is in sleep mode. The cpu is not doing anything. ntp is NOT running. ntp cannot wake up the cpu because ntp is not running. Only external events can wake up the cpu, and ntp is not an external event. So, once the cpu is woken up, and ntp can run, what does it matter if ntp then runs? you've got it assbackwards. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On 2008-05-17, Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, David Woolley [EMAIL PROTECTED] said: I'm not convinced this is even about laptops. I think it is about PDAs, or about embedded systems that may run for a year on a couple of AA bateries, or may run on small photocell arrays. It is about pretty much anything running Linux, from embedded devices to servers. Large colocation factilities have discovered that the limiting factor is not space anymore, but power and cooling. Anything that can be done that makes the servers use less power is a big win. A system functioning as an NTP server (i.e. one which answers polls from clients) needs to be ready to respond to a poll at any time. It stands to reason the such a system would likely never be completely quiescent. And that such a system probably could not, or should not, take advantage of this power-saving patch, A system funtioning as an NTP client (i.e. a leaf node with no polling clients) merely has to be awake enough to poll its time sources and discipline its clock in compliance with its time stability requirements. This discussion is arguing the merits of a patch without any consideration of when its use is indicated. As stated elsewhere in this thread, one size does _not_ fit all. -- 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] Power-saving patch to NTP
On 2008-05-18, Unruh [EMAIL PROTECTED] wrote: Uwe Klein [EMAIL PROTECTED] writes: Linux presents afaik the biggest userbase for ntp (and is simultanously the most derided group of questioneers in this NG, I certainly have no idea what you are talking about. What derision? The Linux kernel maintainer are regularly criticised for making changes which are hostile to NTP. Frequent statments have been made that Linux is an inferior plaform for NTP (e.g. WRT to lost interrrupts, etc.) though i think compared to the installed instances linux is imho underrepresented). If a large group is beat over the head in a somewhat regular fashion ( which may have been just a cats and dogs thing ) it is rather unsurprising to find those people working around this obstacle. What beat over the head? What obstacle? If a group is frequently criticized, or their requests are dismissed out of hand they may very well implement their own solutions. Whichever way one does this ntp needs to be able to respond to finer grained external triggers. It can not any longer be King of the Castle. No idea what this means either. King of the Castle == the most important code running on the system. -- 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] Power-saving patch to NTP
Another item is due to the consecutive namechanges ntp -- xntp -- ntp and the linux standardisation effort LSB. when xntp was recent the LSB ( Linux Standards Base ) fixed some names for required functionality which lead to some distributions still naming the timekeeping package xntp and the rcscript rcxntp though the distributed ntp version is as recent as can be. This still leads to some friendly greeting to first update their ancient version of (x)ntp for linuxers asking for help. I assume that this is a bit of a cats and dogs issue. All the ntpregulars seem to be very friendly on all other occasions ;-) But it certainly has been habit forming on both sides. uwe ___ 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, 6:44 pm, David L. Mills [EMAIL PROTECTED] wrote: 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. I don't pretend to know NTP innards, but wouldn't it be possible to select the scale of updates? And, please, don't consider the power used by NTP itself, but rather the power used by the CPU idling in a higher power state than before NTP woke it up. Modern processors can draw 100W without doing anything useful, but it falls down to less than 10W it it's allowed run the HALT instruction instead when there's nothing to do. The picture that Red Hat refers to is that the CPU is removed from a deep C-state in order to run NTP for microseconds and then it remains in the running state for a few fractions of a second until it goes back to a deep C-state. So it's not a matter of NTP's duty cycle, but the duty cycle resulting from the heuristics used by the hardware or the OS to decide when to place the CPU in a deep C-state. 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 18, 12:39 am, [EMAIL PROTECTED] (Danny Mayer) wrote: It's not doing nothing. If the CPU is on standby nothing, including ntpd, should be running. One thing is the CPU in standby, something else the whole system. In modern x86 systems running Linux, the CPU enters C1 state when there's no task to run. When the CPU is in the C1 state, the internal circuitry is shutdown, reducing the power used by the by about one order of magnitude. Some processors will automatically enter deeper CPU standby states, others require OS intervention. Linux will use all available CPU standby states as often as possible by default. So even after a few fractions of a second in the C1 state, it can put the CPU in C2 (or C3) state, when the processor disconnects the core from the bus interface keeping caches coherent (or not), reducing the power to a fraction of the C1 state. Amazingly enough, servers spend most of the time in a C state, whether waiting for disk access or for network replies. Therefore, it's a critical part of power management in data-center. In data-centers, every W used by equipment will require another W in AC. With several systems, it's not difficult to end up with a few kWh everyday due to NTP, which translates into possibly hundreds of dollars in additional costs. HTH ___ 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 wrote: packet shows up, which with laptops I know will considerably degrade the I'm not convinced this is even about laptops. I think it is about PDAs, or about embedded systems that may run for a year on a couple of AA bateries, or may run on small photocell arrays. ___ 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 wrote: 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. Hi David, Hand in Hand to having IP connectivity to missions? Any mission that uses ntp (or lookalike) already? What about all the other hassle: doppler shift, changing pathlength ( and thus changing transmit delays ) ... uwe ___ 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: packet shows up, which with laptops I know will considerably degrade the I'm not convinced this is even about laptops. I think it is about PDAs, or about embedded systems that may run for a year on a couple of AA bateries, or may run on small photocell arrays. I think that the lesswatts.org initiative (which should of course have been called fewerwatts.org but that's another story) is about reducing the power consumption of _all_ hardware that runs Linux, including laptops, desktops, servers, embedded devices etc. I also think that ntpd runs on a sizeable percentage of all such hardware that's in service out there. But that's not why I raised the question here. Ntpd's once-per-second interrupt is nothing compared with the hundreds-to-thousands of wakeups per second initiated by certain poorly-written hardware device drivers. I just wanted to prompt a discussion on understanding the implications of Red Hat's patch. Application writers do (I think) have a responsibility to the planet to verify/justify their application's impact on the platform's total power consumption (and the lesswatts.org website provides tools for doing that, e.g. powertop), but as I said I don't think that ntpd is an especially power-hungry application. The lesswatts.org site also mentions a range of other power-saving measures in recent Linux kernels, including the bunching together of wakeup events. Some applications have no need for very precise timers, they just want to be woken up more-or-less-2s-from-now. The kernel is then able to schedule a bunch of these imprecise timers at the same time such that the number of wakeups is minimised. Clearly ntpd does need precision and therefore probably must not use this new class of imprecise timers, but I also don't know whether anyone knows if the existence of the imprecise timers has a knock-on effect on the precision of the standard timers. On the other hand, perhaps ntpd _can_ use the imprecise timers provided it also has access to an accurate platform time stamp when the timer fires. Cheers, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe, See http://www.eecis.udel.edu/~mills/ipin.html, which described our previous project. Dave Uwe Klein wrote: David L. Mills wrote: 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. Hi David, Hand in Hand to having IP connectivity to missions? Any mission that uses ntp (or lookalike) already? What about all the other hassle: doppler shift, changing pathlength ( and thus changing transmit delays ) ... uwe ___ 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 wrote: Uwe, See http://www.eecis.udel.edu/~mills/ipin.html, which described our previous project. Hey, Thanks for the link. Would not a GPS like distribution system that does all 4 axes be of merit? uwe ___ 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 wrote: 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 Did you mean milli-Joule? What they are concerned about is the several 10s of watts that result if the machine is idle, other than ntpd and they require more than 1 second of idle time before doing a suspend to RAM, or the 10s or 100s of Joules if ntpd does longer term periodic processing at a different time from other applications, resulting in energy being expended to get out of suspend to RAM, and energy being used until the scheduler decides that the system is more likely not to do anything for a long time than not, and triggers a suspend to RAM, and finally the actual suspend to RAM operation. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe, Problem is that, while GPS could in principle provide guidance beyond Earth space, the signal strength is not sufficient for Moon navigation. Davd Uwe Klein wrote: David L. Mills wrote: Uwe, See http://www.eecis.udel.edu/~mills/ipin.html, which described our previous project. Hey, Thanks for the link. Would not a GPS like distribution system that does all 4 axes be of merit? uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
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. It's not doing nothing. If the CPU is on standby nothing, including ntpd, should be running. Danny ___ 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
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] 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] 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
[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
