Power-saving patch to NTP - NTP

This is a discussion on Power-saving patch to NTP - 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 ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 62

Thread: Power-saving patch to NTP

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

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

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

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

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

  6. Re: Power-saving patch to NTP

    Steve Kostecke schreef:

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


    IMHO just a matter of conflicting design goals.

    This medal has 2 sides: while it may not make too much sense to use
    Linux if you need to build a "proper" ntp server, it's probably also not
    a very good idea to use full-blown ntp for keeping the clocks of
    workstations, PDA's, embedded devices, etc. within acceptable range.

    I think people should avoid "full ntp" as standard, general-purpose
    timekeeping solution for every small device on the planet. It is not.

    N

  7. Re: 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 "free"runing with a stable clock.)

    But with distributed systems the requirements are different.

    uwe


  8. Re: Power-saving patch to NTP

    On May 19, 2:32 am, David Woolley
    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

  9. Re: Power-saving patch to NTP

    On Mon, May 19, 2008 at 3:13 AM, Uwe Klein
    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

  10. Re: Power-saving patch to NTP

    Ryan Malayter wrote:
    > On Mon, May 19, 2008 at 3:13 AM, Uwe Klein
    > 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

    Thank you for the link.
    Something for under the pillow at night.

    uwe


  11. Re: Power-saving patch to NTP

    > From: David Woolley
    > Date: Mon, 19 May 2008 08:32:37 +0100
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > 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 system to maximize the time spent
    in C3 and below by trying to schedule as many tasks as possible at the
    same time. The power savings can, again, be very significant and server
    owners are pushing to make this work as well as possible since power
    (both electrical and cooling) have become the primary expense in
    collocation facilities.

    Unfortunately, it looks like this will require some re-thinking of how
    ntp operates as keeping a server running at higher power levels to keep
    ntp happy will hit the owners of these systems right in the pocket
    books.

    I am not a ACPI guru by any means and I don't fully understand all of
    the details. I certainly don't understand all of the inner workings of
    ntp. I just hope this helps clarify what people are talking about.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

    _______________________________________________
    questions mailing list
    questions@lists.ntp.org
    https://lists.ntp.org/mailman/listinfo/questions

    --- StripMime Report -- processed MIME parts ---
    multipart/mixed
    multipart/signed
    text/plain (text body -- kept)
    application/pgp-signature
    text/plain (text body -- kept)
    ---

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


  13. Re: Power-saving patch to NTP

    On May 19, 12:53 pm, "David L. Mills" 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/cont...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.

  14. Re: Power-saving patch to NTP

    Evandro Menezes wrote:
    > On May 19, 2:32 am, David Woolley
    > 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.


    I think you mis-interpreted the double negatives there. I was saying
    that Linux has always used HLT. The only system I'm aware of that
    doesn't use it properly is MS-DOS, although the main problem in
    achieving power saving is Windows applications that think they the only
    thing running, so use spare capacity to speed up their interactivity.
    They are becoming uncommon, though.

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

  16. Re: Power-saving patch to NTP

    Jan Ceuleers wrote:
    >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.


    Yes, is seems once per second is nothing to be worried about. I checked one
    random idle linux desktop here and it showed a total of 13.0 wakeups per
    second. For example, the ethernet adapter caused 3.2 wakeups per second
    (from broadcast traffic, I guess).

  17. Re: Power-saving patch to NTP

    In article ,
    Martin Burnicki 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
    wollman@csail.mit.edu| 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

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

  19. Re: Power-saving patch to NTP

    David Woolley wrote:

    > My argument is that these aren't or shouldn't be important for servers.


    My ( and other posters ) opinion is that this is no longer the case.

    The trusty server chugging along at constant speed never getting cold
    never getting up a heat is a beast of the past, extinct when the
    currently running oned ( already well aged ) do their last shutdown.
    >
    >> 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).


    The "Collocation Dedicacted Server" and VM people are very adamant about
    stopping VMs or taking a "real" machine as far as possible into powerdown
    when the payload app is idle.

    ntp is not an app but infrastructure in this context.

    > Also, as I understand it, enterprise (i.e. expensive) virtualisation
    > software can move running guests between hosts, so, whilst that would be

    Yes , XEN forex provides "seamless" migration across a network of hosts
    ( though there is not much connection to expensive, most Linux Distributions
    provide packages to run VM hosts/guests )

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

    RealTime and migration don't seem to be made for mariage, or?

    uwe

  20. Re: Power-saving patch to NTP

    Garrett,

    Garrett Wollman wrote:
    > In article ,
    > Martin Burnicki 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

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