Re: Time reset - NTP

This is a discussion on Re: Time reset - NTP ; Hi, I need to experiment a bit to give some stats on CPU load and DISK I/O when crond tasks are run. Venu...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Re: Time reset

  1. Re: Time reset

    Hi,

    I need to experiment a bit to give some stats on CPU load
    and DISK I/O when crond tasks are run.

    Venu

  2. Re: Time reset

    neo.venu@gmail.com (Venu Gopal) wrote in
    news:875dfa3d0803050226r16a94674k40c01387b90ebb5@m ail.gmail.com:

    > Hi,
    >
    > I need to experiment a bit to give some stats on CPU load
    > and DISK I/O when crond tasks are run.
    >
    > Venu


    Hi all,

    To measure the CPU load and DISK I/O I've used "iostat"
    while running the crons weekly tasks of updatring the
    "whatis" database. Below is the slice of the log :

    --------------------------------------------------------

    avg-cpu: %user %nice %sys %idle
    77.00 0.00 16.00 7.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 132.50 1032.00 68.00 2064 136

    avg-cpu: %user %nice %sys %idle
    91.00 0.00 4.50 4.50

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 50.50 296.00 2492.00 592 4984

    avg-cpu: %user %nice %sys %idle
    82.00 0.00 2.00 16.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 43.50 420.00 0.00 840 0

    avg-cpu: %user %nice %sys %idle
    99.00 0.00 1.00 0.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 1.00 4.00 4.00 8 8

    avg-cpu: %user %nice %sys %idle
    98.00 0.00 2.00 0.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 22.00 0.00 2412.00 0 4824

    avg-cpu: %user %nice %sys %idle
    97.50 0.00 2.50 0.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 1.00 0.00 8.00 0 16

    avg-cpu: %user %nice %sys %idle
    98.50 0.00 1.50 0.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 59.50 0.00 3340.00 0 6680

    avg-cpu: %user %nice %sys %idle
    98.00 0.00 2.00 0.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 1.00 0.00 8.00 0 16

    avg-cpu: %user %nice %sys %idle
    14.00 0.00 1.00 85.00

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 4.00 36.00 8.00 72 16

    --------------------------------------------------------

    Its clear that CPU is heavily loaded which might be
    leading to loss of ticks. Yet to check the DMA status for
    IDE DISK. I'll be out for about a week, after returning I'll
    give few more stats based on combination of CPU load, Disk I/O
    and Network I/O.

    Venu

  3. Re: Time reset

    Venu Gopal wrote:

    > Its clear that CPU is heavily loaded which might be
    > leading to loss of ticks. Yet to check the DMA status for


    CPU loading doesn't cause lost timer interrupts. (More precisely
    overruns.)

    > IDE DISK. I'll be out for about a week, after returning I'll
    > give few more stats based on combination of CPU load, Disk I/O
    > and Network I/O.


  4. Re: Time reset

    David Woolley wrote:
    > Venu Gopal wrote:
    >
    >> Its clear that CPU is heavily loaded which might be leading to loss of
    >> ticks. Yet to check the DMA status for

    >
    > CPU loading doesn't cause lost timer interrupts. (More precisely
    > overruns.)
    >


    So its the DISK I/O thats causing loss of ticks ?

    >> IDE DISK. I'll be out for about a week, after returning I'll
    >> give few more stats based on combination of CPU load, Disk I/O
    >> and Network I/O.


  5. Re: Time reset

    D.Venu Gopal wrote:
    > David Woolley wrote:
    >> Venu Gopal wrote:
    >>
    >>> Its clear that CPU is heavily loaded which might be leading to loss of
    >>> ticks. Yet to check the DMA status for

    >>
    >> CPU loading doesn't cause lost timer interrupts. (More precisely
    >> overruns.)
    >>

    >
    > So its the DISK I/O thats causing loss of ticks ?
    >
    >>> IDE DISK. I'll be out for about a week, after returning I'll
    >>> give few more stats based on combination of CPU load, Disk I/O
    >>> and Network I/O.


    There have been several examples of drivers which kept interrupts disabled
    for too long, so that timer ticks couldn't get through. In most cases
    (AFAIK) this have been drivers for IDE disks, especially if they didn't use
    DMA.

    This has happened across several operating systems (I remember Linux,
    Windows, and formerly OS/2), with drivers which had not been designed
    properly. So this depends on a specific version of the OS and a specific
    version of a specific driver. You can not say in general that IDE drivers
    cause lost timer ticks, but they are good candidates.

    Unfortunately the new clock routines in the Linux kernel seem to be causing
    problems sometime. This seems to be due to certain combination of a clock
    module which handles a particulare timer on the mainboard and the
    particular timer the implementation of which may vary by the chipset.

    This is not exactly the same as lost timer ticks, but the results are
    similar, i.e. the clock drift can be so large or changing so much that ntpd
    fails to correct it.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  6. Re: Time reset

    Hi Martin,

    Thanks for the insight.

    I was struggling to convince people here (technically!).
    Never knew that its a well know issue that has been
    discussed several times in the forum.

    Thanks to Harlan for his references.

    Venu

    Martin Burnicki wrote:
    > D.Venu Gopal wrote:
    >> David Woolley wrote:
    >>> Venu Gopal wrote:
    >>>
    >>>> Its clear that CPU is heavily loaded which might be leading to loss of
    >>>> ticks. Yet to check the DMA status for
    >>> CPU loading doesn't cause lost timer interrupts. (More precisely
    >>> overruns.)
    >>>

    >> So its the DISK I/O thats causing loss of ticks ?
    >>
    >>>> IDE DISK. I'll be out for about a week, after returning I'll
    >>>> give few more stats based on combination of CPU load, Disk I/O
    >>>> and Network I/O.

    >
    > There have been several examples of drivers which kept interrupts disabled
    > for too long, so that timer ticks couldn't get through. In most cases
    > (AFAIK) this have been drivers for IDE disks, especially if they didn't use
    > DMA.
    >
    > This has happened across several operating systems (I remember Linux,
    > Windows, and formerly OS/2), with drivers which had not been designed
    > properly. So this depends on a specific version of the OS and a specific
    > version of a specific driver. You can not say in general that IDE drivers
    > cause lost timer ticks, but they are good candidates.
    >
    > Unfortunately the new clock routines in the Linux kernel seem to be causing
    > problems sometime. This seems to be due to certain combination of a clock
    > module which handles a particulare timer on the mainboard and the
    > particular timer the implementation of which may vary by the chipset.
    >
    > This is not exactly the same as lost timer ticks, but the results are
    > similar, i.e. the clock drift can be so large or changing so much that ntpd
    > fails to correct it.
    >
    > Martin


  7. Re: Time reset


    > So its the DISK I/O thats causing loss of ticks ?


    My first Red Hat system defaulted to no-DMA for IDE disks. (Yes,
    that was a long time ago.) With that setup, it was simple to generate
    lots of lost timer interrupts: just keep the disk busy doing reads.
    (Seeks don't count. Read consecutive sectors.)

    My problem went away when I turned on DMA.

    I have a hack that I originally wrote for measuring disk
    transfer rates. I'll dust it off and put it on the wiki
    if people think it will be helpful for discussions like this.

    It compiles on Linux. It should be easy to get it to work on
    other *nix systems.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  8. Re: Time reset

    Hal Murray wrote:
    >> So its the DISK I/O thats causing loss of ticks ?

    >
    > My first Red Hat system defaulted to no-DMA for IDE disks. (Yes,
    > that was a long time ago.) With that setup, it was simple to generate
    > lots of lost timer interrupts: just keep the disk busy doing reads.
    > (Seeks don't count. Read consecutive sectors.)
    >
    > My problem went away when I turned on DMA.
    >
    > I have a hack that I originally wrote for measuring disk
    > transfer rates. I'll dust it off and put it on the wiki
    > if people think it will be helpful for discussions like this.
    >

    Ok Hal. This will be certainly helpful.

    > It compiles on Linux. It should be easy to get it to work on
    > other *nix systems.
    >


  9. Re: Time reset

    Hi Hal,

    Can you post the Twiki URL after posting it.

    Venu

    Hal Murray wrote:
    >> So its the DISK I/O thats causing loss of ticks ?

    >
    > My first Red Hat system defaulted to no-DMA for IDE disks. (Yes,
    > that was a long time ago.) With that setup, it was simple to generate
    > lots of lost timer interrupts: just keep the disk busy doing reads.
    > (Seeks don't count. Read consecutive sectors.)
    >
    > My problem went away when I turned on DMA.
    >
    > I have a hack that I originally wrote for measuring disk
    > transfer rates. I'll dust it off and put it on the wiki
    > if people think it will be helpful for discussions like this.
    >
    > It compiles on Linux. It should be easy to get it to work on
    > other *nix systems.
    >


  10. Disk read hack

    I didn't find a reasonable place to insert it in the wiki so
    I parked it here for now.

    This is a hack that just reads a disk as fast as it can.
    It was very "good" at tickling the lost-interrupt problem
    on an old RH system which was not using DMA on the disks.

    http://www.megapathdsl.net/~hmurray/hacks/read.c

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  11. Re: Disk read hack

    Thanks a lot !

    Hal Murray wrote:
    > I didn't find a reasonable place to insert it in the wiki so
    > I parked it here for now.
    >
    > This is a hack that just reads a disk as fast as it can.
    > It was very "good" at tickling the lost-interrupt problem
    > on an old RH system which was not using DMA on the disks.
    >
    > http://www.megapathdsl.net/~hmurray/hacks/read.c
    >


  12. Re: Disk read hack

    >>> In article , hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:

    Hal> I didn't find a reasonable place to insert it in the wiki so I parked
    Hal> it here for now.

    Hal> http://www.megapathdsl.net/~hmurray/hacks/read.c

    How about attaching it to:

    http://support.ntp.org/Support/KnownOsIssues

    And I can see that it might be Good to refactor that page into separate
    pages.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  13. Re: Disk read hack

    In article ,
    Harlan Stenn writes:
    >>>> In article , hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:

    >
    >Hal> I didn't find a reasonable place to insert it in the wiki so I parked
    >Hal> it here for now.
    >
    >Hal> http://www.megapathdsl.net/~hmurray/hacks/read.c
    >
    >How about attaching it to:
    >
    > http://support.ntp.org/Support/KnownOsIssues
    >
    >And I can see that it might be Good to refactor that page into separate
    >pages.


    I inserted a section on lost interrupts. Feel free to correct, fix,
    move, reorganize...

    --
    These are my opinions, not necessarily my employer's. I hate spam.


+ Reply to Thread