Power-saving patch to NTP - NTP

This is a discussion on Power-saving patch to NTP - NTP ; Once upon a time, David Woolley 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 ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 62

Thread: Power-saving patch to NTP

  1. Re: Power-saving patch to NTP

    Once upon a time, David Woolley 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.
    --
    Chris Adams
    Systems and Network Administrator - HiWAAY Internet Services
    I don't speak for anybody but myself - that's enough trouble.

  2. Re: 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


  3. Re: 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

  4. Re: 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.

  5. Re: 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


  6. Re: Power-saving patch to NTP

    Evandro Menezes wrote:
    > On May 16, 12:29 pm, "David L. Mills" 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 .00001 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

  7. Re: 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



  8. Re: 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

  9. Re: 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!


  10. Re: Power-saving patch to NTP

    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.


    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".

    G!
    uwe


  11. Re: Power-saving patch to NTP

    Uwe Klein writes:

    >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!


    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?



    >uwe


  12. Re: Power-saving patch to NTP

    Uwe Klein 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.



  13. Re: 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

  14. Re: 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

  15. Re: Power-saving patch to NTP

    On 2008-05-18, Unruh wrote:
    > Uwe Klein 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
    NTP Public Services Project - http://support.ntp.org/

  16. Re: Power-saving patch to NTP

    On 2008-05-17, Chris Adams wrote:

    > Once upon a time, David Woolley 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
    NTP Public Services Project - http://support.ntp.org/

  17. Re: 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




  18. Re: Power-saving patch to NTP

    On May 18, 12:39 am, ma...@ntp.isc.org (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

  19. Re: Power-saving patch to NTP

    On May 16, 6:44 pm, "David L. Mills" 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

  20. Re: Power-saving patch to NTP

    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.

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast