IO TIME vs COMputable - VMS

This is a discussion on IO TIME vs COMputable - VMS ; Hello, I am looking for the reel IO time for a batch. It's seem at the end of the batch report, there is information like : Charged CPU time: 0 00:10:21.34 Elapsed time: 0 00:25:18.93 i know that the IO ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: IO TIME vs COMputable

  1. IO TIME vs COMputable

    Hello,

    I am looking for the reel IO time for a batch.

    It's seem at the end of the batch report, there is information like :
    Charged CPU time: 0 00:10:21.34 Elapsed time: 0 00:25:18.93

    i know that the IO time = ELapsed - CPU Time.

    But , if the batch wait the processor (COMputable state) during the
    executing, the IO time was wrong. (i think)

    how can i find the reel "IO TIME" ou COMputable TIME for the batch process.

    is this information available?
    or i am wrong in my reasoning ?

    Thanks you.
    Best regards
    Eric

  2. Re: IO TIME vs COMputable

    In article , "e.e" writes:
    >
    > i know that the IO time = ELapsed - CPU Time.


    Basically: Wait Time = Elapsed Time - CPU Time
    Waiting for I/O is only one reason to wait.

    > But , if the batch wait the processor (COMputable state) during the
    > executing, the IO time was wrong. (i think)


    CPU time is "CUR" time, not "COM" time.


  3. Re: IO TIME vs COMputable

    Bob Koehler a écrit :
    > In article , "e.e" writes:
    >> i know that the IO time = ELapsed - CPU Time.

    >
    > Basically: Wait Time = Elapsed Time - CPU Time
    > Waiting for I/O is only one reason to wait.
    >
    >> But , if the batch wait the processor (COMputable state) during the
    >> executing, the IO time was wrong. (i think)

    >
    > CPU time is "CUR" time, not "COM" time.
    >


    yes absolutely... lapsus..

    thanks..
    Eric

  4. Re: IO TIME vs COMputable

    On Nov 7, 11:20 am, "e.e" wrote:
    > Bob Koehler a écrit :
    >
    > > In article , "e.e" writes:
    > >> i know that the IO time = ELapsed - CPU Time.


    Just FYI... You know you posted this question twice right?
    The other topic received more replies

    http://groups.google.com/group/comp....85ca1421021c6b

    Hein.


  5. Re: IO TIME vs COMputable

    Hein RMS van den Heuvel a écrit :
    > On Nov 7, 11:20 am, "e.e" wrote:
    >> Bob Koehler a écrit :
    >>
    >>> In article , "e.e" writes:
    >>>> i know that the IO time = ELapsed - CPU Time.

    >
    > Just FYI... You know you posted this question twice right?
    > The other topic received more replies
    >
    > http://groups.google.com/group/comp....85ca1421021c6b
    >
    > Hein.
    >

    yes i saw..

    a cancel of this post doesn't work..
    everything cannot work fine like VMS.. ;-)

    Thanks.
    Eric

  6. Re: IO TIME vs COMputable

    In article , "e.e" writes:
    >
    > It's seem at the end of the batch report, there is information like :
    > Charged CPU time: 0 00:10:21.34 Elapsed time: 0 00:25:18.93
    >
    > i know that the IO time = ELapsed - CPU Time.


    Actually everything that the software waits for is included in
    that difference, not just I/O.

    I don't know of any tracking of I/O time in VMS.


  7. Re: IO TIME vs COMputable

    In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    > In article , "e.e" writes:
    >
    >> But , if the batch wait the processor (COMputable state) during the
    >> executing, the IO time was wrong. (i think)

    >
    > CPU time is "CUR" time, not "COM" time.


    Yes, but if he's in COM instead of CUR, then he's not doing I/O,
    which is what he wants to know about.


  8. Re: IO TIME vs COMputable

    Bob Koehler wrote:

    > Yes, but if he's in COM instead of CUR, then he's not doing I/O,
    > which is what he wants to know about.


    What is the definition of "doing I/O" ?

    What if he is doing IO to a device that requires a driver calculate PI
    to 5 million decimals for every character received ? That would put the
    process in COM while it is doing IO.

    Also, you need to consider asynchronous IO. Your process could be busy
    computing the meaning of live in its main loop while there are
    asynchronous IOs that complete and trigger ASTs.

    Or, after realising there is no meaning to life, your process could
    decide to SYS$HIBER indefinitely, at which point, it will be in HIB and
    not computing much, but IOs would still be able to be done and complete
    via triggering of ASTs.


  9. Re: IO TIME vs COMputable

    JF Mezei wrote:

    >
    > What is the definition of "doing I/O" ?


    Usualy, in 9 cases of 10, the definition is "waiting".
    And knowing how long your process is "waiting" can
    in many cases be just as interesting as knowing how
    much time it's actualy "working"...

    Jan-Erik.


  10. Re: IO TIME vs COMputable

    In article <490a146a$0$18948$c3e8da3@news.astraweb.com>, JF Mezei writes:
    > Bob Koehler wrote:
    >
    >> Yes, but if he's in COM instead of CUR, then he's not doing I/O,
    >> which is what he wants to know about.

    >
    > What is the definition of "doing I/O" ?
    >
    > What if he is doing IO to a device that requires a driver calculate PI
    > to 5 million decimals for every character received ? That would put the
    > process in COM while it is doing IO.


    In which case he's CUR, not doing I/O. When doing I/O you are
    generally in LEF.

    > Also, you need to consider asynchronous IO. Your process could be busy
    > computing the meaning of live in its main loop while there are
    > asynchronous IOs that complete and trigger ASTs.


    In which case he's CUR, while doing I/O.

    > Or, after realising there is no meaning to life, your process could
    > decide to SYS$HIBER indefinitely, at which point, it will be in HIB and
    > not computing much, but IOs would still be able to be done and complete
    > via triggering of ASTs.


    And you point is? I don't think you're following up on issues that
    the OP is interested in.


  11. Re: IO TIME vs COMputable

    Bob Koehler wrote:
    > I don't know of any tracking of I/O time in VMS.


    Not exactly tracking I/O time as defined in this thread, but
    nevertheless very useful, is the ability of OpenVMS to track response
    times for Fibre Channel I/Os, creating a histogram of response times
    versus I/O size, and tracking reads and writes separately. See the
    output of SDA> FC PERF [devicename]

    T4's Fibre Channel Monitor (FCM) data collector also collects response
    time data for Fibre Channel disks, which is then easy to visualize using
    TLviz.

  12. Re: IO TIME vs COMputable

    Keith Parris wrote:
    >
    > Bob Koehler wrote:
    > > I don't know of any tracking of I/O time in VMS.

    >
    > Not exactly tracking I/O time as defined in this thread, but
    > nevertheless very useful, is the ability of OpenVMS to track response
    > times for Fibre Channel I/Os, creating a histogram of response times
    > versus I/O size, and tracking reads and writes separately. See the
    > output of SDA> FC PERF [devicename]
    >
    > T4's Fibre Channel Monitor (FCM) data collector also collects response
    > time data for Fibre Channel disks, which is then easy to visualize using
    > TLviz.


    Remember CSVPNG, also. Runs on VMS and can be used in batch (hands-off,
    lights-out, unattended).

    D.J.D.

+ Reply to Thread