Re: CPU Timerons/Seconds vs Wall-clock Time
What are you trying to solve? Jobs get swapped in and out depending on what work they are doing. Are you trying to relate wall clock to cpu time? I have seen jobs run 2 hours wall clock time and only take 10 mins of CPU time. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lindy Mayfield > Sent: Sunday, April 09, 2017 8:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CPU Timerons/Seconds vs Wall-clock Time > > This may or may not be the dumbest question I've asked this week, but I've > been working with Linux a lot lately so that's my excuse. > > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), > can I assume that it at least took 10 seconds of elapsed time to run? > > Regards, > Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
Yes providing you are only running app on one cpu .e., not multi threading etc. On 09/04/17 16:48, Lindy Mayfield wrote: This may or may not be the dumbest question I've asked this week, but I've been working with Linux a lot lately so that's my excuse. For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), can I assume that it at least took 10 seconds of elapsed time to run? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
On Sun, 9 Apr 2017 15:48:12 +, Lindy Mayfield wrote: >This may or may not be the dumbest question I've asked this week, but I've >been working with Linux a lot lately so that's my excuse. > (It's only Sunday.) (On what day does Finland(?) start the week?) >For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), >can I assume that it at least took 10 seconds of elapsed time to run? > How do multiple CPUs count? Might it be 10 seconds/number of CPUs active? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
I only have CPU time from SMF 30 but I don't have elapsed time which is very important. I'd like to somewhat infer that a high CPU time means the job ran a long time. /Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: sunnuntai 9. huhtikuuta 2017 18.55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU Timerons/Seconds vs Wall-clock Time What are you trying to solve? Jobs get swapped in and out depending on what work they are doing. Are you trying to relate wall clock to cpu time? I have seen jobs run 2 hours wall clock time and only take 10 mins of CPU time. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lindy Mayfield > Sent: Sunday, April 09, 2017 8:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CPU Timerons/Seconds vs Wall-clock Time > > This may or may not be the dumbest question I've asked this week, but > I've been working with Linux a lot lately so that's my excuse. > > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I > think), can I assume that it at least took 10 seconds of elapsed time to run? > > Regards, > Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
you got me on that one, gil. :) trying to exploit the ambiguity of a Sunday. guilty. i got a side gig to figure out some performance problems, and it ain't on linux, but on a real machine. and nothing is good on tv at the moment. as Lizette pointed out, elapsed time is one thing independent on cpu. and vince pointed out my lack of knowledge. on unix (linux) cpu can go over 100%. but for some reason I thought that no matter what on mvs, 1 cpu second (unless multithreaded) equaled 1 second at least wall clock time, no matter the cpu configuration. I could have perhaps asked this a better and more mainframe way: In the JES log from a batch job, will I ever see an elapsed time less than the CPU time? /Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: sunnuntai 9. huhtikuuta 2017 19.03 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU Timerons/Seconds vs Wall-clock Time On Sun, 9 Apr 2017 15:48:12 +, Lindy Mayfield wrote: >This may or may not be the dumbest question I've asked this week, but I've >been working with Linux a lot lately so that's my excuse. > (It's only Sunday.) (On what day does Finland(?) start the week?) >For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), >can I assume that it at least took 10 seconds of elapsed time to run? > How do multiple CPUs count? Might it be 10 seconds/number of CPUs active? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
[Default] On 9 Apr 2017 09:41:33 -0700, in bit.listserv.ibm-main lindy.mayfi...@sas.com (Lindy Mayfield) wrote: >I only have CPU time from SMF 30 but I don't have elapsed time which is very >important. I'd like to somewhat infer that a high CPU time means the job ran >a long time. There is a step start time and date in the SMF 30 type 4 record. I am not certain if there is a step stop time and date since I don't want to take the time to bring up the appropriate manual and I don't have access to the Assembler Macros. There may be other records that have start and stop times and the SMF 26 records may have execution time but only for the job. Clark Morris > >/Lindy > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Lizette Koehler >Sent: sunnuntai 9. huhtikuuta 2017 18.55 >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > >What are you trying to solve? > >Jobs get swapped in and out depending on what work they are doing. > > >Are you trying to relate wall clock to cpu time? I have seen jobs run 2 hours >wall clock time and only take 10 mins of CPU time. > >Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Lindy Mayfield >> Sent: Sunday, April 09, 2017 8:48 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: CPU Timerons/Seconds vs Wall-clock Time >> >> This may or may not be the dumbest question I've asked this week, but >> I've been working with Linux a lot lately so that's my excuse. >> >> For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I >> think), can I assume that it at least took 10 seconds of elapsed time to run? >> >> Regards, >> Lindy > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
from one single record I cannot get elapsed time, but from a set of records I can. please, don't look it up. I already have. :) I'm only dealing with a few fields from that record, captured elsewhere, so even if it were there I couldn't use it. thank you, Clark. a number of the smf recs layouts used to hang from my door at one time, all the way to the floor. they don't anymore. /lindy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: sunnuntai 9. huhtikuuta 2017 20.01 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU Timerons/Seconds vs Wall-clock Time [Default] On 9 Apr 2017 09:41:33 -0700, in bit.listserv.ibm-main lindy.mayfi...@sas.com (Lindy Mayfield) wrote: >I only have CPU time from SMF 30 but I don't have elapsed time which is very >important. I'd like to somewhat infer that a high CPU time means the job ran >a long time. There is a step start time and date in the SMF 30 type 4 record. I am not certain if there is a step stop time and date since I don't want to take the time to bring up the appropriate manual and I don't have access to the Assembler Macros. There may be other records that have start and stop times and the SMF 26 records may have execution time but only for the job. Clark Morris > >/Lindy > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >On Behalf Of Lizette Koehler >Sent: sunnuntai 9. huhtikuuta 2017 18.55 >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > >What are you trying to solve? > >Jobs get swapped in and out depending on what work they are doing. > > >Are you trying to relate wall clock to cpu time? I have seen jobs run 2 hours >wall clock time and only take 10 mins of CPU time. > >Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Lindy Mayfield >> Sent: Sunday, April 09, 2017 8:48 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: CPU Timerons/Seconds vs Wall-clock Time >> >> This may or may not be the dumbest question I've asked this week, but >> I've been working with Linux a lot lately so that's my excuse. >> >> For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I >> think), can I assume that it at least took 10 seconds of elapsed time to run? >> >> Regards, >> Lindy > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
If you take a look at the logs for the job you will see the start, end and lapsed time along with the CPU time for all steps run. Elapsed time will ALWAYS be longer than CPU time. Why? 1. System is multi tasking so runs many jobs at the same time depending on capabilities. 2. Overheads for various external processes that look after the job/s. 3. Speed of operators (including robots) to load any required tapes or exchangeable disk packs if used. 4. Others, but you get the idea. Try running similar job/s on a PC at least under Linux within a script with a prefix of time you will see the same. For example running :- -- #!/bin/bash time rsync -avvuhh --stats --delete --exclude=/home/vince/.VirtualBox --exclude="/home/vince/VirtualBox VMs" --exclude=/home/vince/Music2 /home /home/vince/Music2/Backups > rsync-home.log 2>rsync-home.err exit 0 -- Output is :- -- [vince@Applewood ~]$ sudo ./rsync-home.sh [sudo] password for vince: real1m10.523s user0m13.190s sys 0m10.720s -- So CPU is 13.19 + 10.72 = 23.81 lapsed 70.52 seconds. This was run on a multi user / tasking system with web, ftp, mysql and other servers running. A M/F may not break down CPU time between system and the application depending on O/S used. Vince On 09/04/17 17:42, Lindy Mayfield wrote: I only have CPU time from SMF 30 but I don't have elapsed time which is very important. I'd like to somewhat infer that a high CPU time means the job ran a long time. /Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: sunnuntai 9. huhtikuuta 2017 18.55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU Timerons/Seconds vs Wall-clock Time What are you trying to solve? Jobs get swapped in and out depending on what work they are doing. Are you trying to relate wall clock to cpu time? I have seen jobs run 2 hours wall clock time and only take 10 mins of CPU time. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lindy Mayfield Sent: Sunday, April 09, 2017 8:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU Timerons/Seconds vs Wall-clock Time This may or may not be the dumbest question I've asked this week, but I've been working with Linux a lot lately so that's my excuse. For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), can I assume that it at least took 10 seconds of elapsed time to run? Regards, Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- - IMPORTANT – This email and the information in it may be confidential, legally privileged and/or protected by law. It is intended solely for the use of the person to whom it is addressed. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Please also delete all copies of this email & any attachments from your system. If this is an encrypted email it is your responsibility to maintain the 1024 byte key system even for one-use keys. Once mail has been sent the sending key is not kept and therefore a replacement mail cannot be resent. We cannot guarantee the security or confidentiality of non encrypted email communications. We do not accept any liability for losses or damages that you may suffer as a result of your receipt of this email including but not limited to computer service or system failure, access delays or interruption, data non-delivery or mis-delivery, computer viruses or other harmful components. Copyright in this email and any attachments belongs to Applewood Computers. Should you communicate with anyone at Applewood Computers by email, you consent to us monitoring and reading any such correspondence. Nothing in this email shall be taken or read as suggesting, proposing or relating to any agreement concerted practice or other practice that could infringe UK or EC competition legislation (unless it is against Security requirements). This Email and its attachments (if any) are scanned for virii using Clamd and ClamAV 0.99.2 or later (Linux x64). Dykegrove Limited T/A Applewood Computers is a company registered in England (no. 01681349) whose registered office is at Applewood House, 17 Stag Green Avenue, Hatfield, Hertfordshire, AL9 5EB, UK. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
vbc...@gmail.com (Vince Coen) writes: > A M/F may not break down CPU time between system and the application > depending on O/S used. as undergraduate in the 60s, I remember rewritting some CP/67 (precursor to vm370) so that it world accurately account for all time. More than a decade later I saw code in unix that was similar to the 60s cp/67 code. I conjectured that was because some of the CTSS people had gone to the 5th flr to work on multics and others had gone to the ibm science center on the 4th flr and did cp/40-cms, cp/67-cms, invented GML, bunch of online stuff, etc. Folklore that the people that had originally done Unix had previously been working on Multics and "Unix" is a play on simplified Multics. About the time I encountered the Unix code ... MVS was claiming that unaccounted (cpu) time could easily be 50-60% aka "capture ratio", they calculated wallclock cpu "wait" time, so the inverse was wallclock cpu use, "capture ratio" was the accounted for cpu divided by (wallclock elapsed time minus wait time). This showed up when internal datacenters were bursting at the seams with largest POK mainframes ... and were looking at offloading lots of the MVS workload to distributed 4341s out in departmental areas ... and were not correctly taking into account "capture ratio". Some of these very large MVS applications weren't able to run on vm/370-cms. The issue was that the original os/360 system services simulation was only 64kbytes ... and a much more complete implementation somehow got lost when head of POK convinced corporate to kill vm370 product in the mid-70s (and transfer the people to work on MVS/XA) ... Endicott did eventually manage to resurrect the VM370 product administration ... but had to reconstitute a group from scratch. as referenced in this old email (discussing "capture ratio" and other things) ... it only took another 12kbytes of system services simulation to get the MVS applications into VM/370-CMS production http://www.garlic.com/~lynn/2006v.html#email800717 -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
If a job executes in parallel threads on multiple CPUs, the CPU time could be more than the elapsed time. A massive number cruncher could run for an hour and consume 59 minutes of CPU. An interactive application that waits on a user could run for an hour and consume only seconds of CPU. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lindy Mayfield > Sent: Sunday, April 09, 2017 9:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > I only have CPU time from SMF 30 but I don't have elapsed time which is very important. > I'd like to somewhat infer that a high CPU time means the job ran a long time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
I am not sure that looking at one SMF record can tell the story. If the job ran long, was it due to I/O Looping Code Larger than normal Data Load And so on. Maybe other can provide better insight. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lindy Mayfield > Sent: Sunday, April 09, 2017 9:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > I only have CPU time from SMF 30 but I don't have elapsed time which is very > important. I'd like to somewhat infer that a high CPU time means the job ran > a long time. > > /Lindy > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: sunnuntai 9. huhtikuuta 2017 18.55 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > What are you trying to solve? > > Jobs get swapped in and out depending on what work they are doing. > > > Are you trying to relate wall clock to cpu time? I have seen jobs run 2 hours > wall clock time and only take 10 mins of CPU time. > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Lindy Mayfield > > Sent: Sunday, April 09, 2017 8:48 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: CPU Timerons/Seconds vs Wall-clock Time > > > > This may or may not be the dumbest question I've asked this week, but > > I've been working with Linux a lot lately so that's my excuse. > > > > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I > > think), can I assume that it at least took 10 seconds of elapsed time to > run? > > > > Regards, > > Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
That funny enough is interesting. In accumulating total CPU usage however no account appears to show up the secondary (offloaded) processes such as in the block or char controllers etc. Under *nix you can account for all i/p and if one knows the processors used can therefore work it out but life is too short. All counts at least for accountants :) But there again I am (was) not... Vincent On 09/04/17 19:10, Anne & Lynn Wheeler wrote: vbc...@gmail.com (Vince Coen) writes: A M/F may not break down CPU time between system and the application depending on O/S used. as undergraduate in the 60s, I remember rewritting some CP/67 (precursor to vm370) so that it world accurately account for all time. More than a decade later I saw code in unix that was similar to the 60s cp/67 code. I conjectured that was because some of the CTSS people had gone to the 5th flr to work on multics and others had gone to the ibm science center on the 4th flr and did cp/40-cms, cp/67-cms, invented GML, bunch of online stuff, etc. Folklore that the people that had originally done Unix had previously been working on Multics and "Unix" is a play on simplified Multics. About the time I encountered the Unix code ... MVS was claiming that unaccounted (cpu) time could easily be 50-60% aka "capture ratio", they calculated wallclock cpu "wait" time, so the inverse was wallclock cpu use, "capture ratio" was the accounted for cpu divided by (wallclock elapsed time minus wait time). This showed up when internal datacenters were bursting at the seams with largest POK mainframes ... and were looking at offloading lots of the MVS workload to distributed 4341s out in departmental areas ... and were not correctly taking into account "capture ratio". Some of these very large MVS applications weren't able to run on vm/370-cms. The issue was that the original os/360 system services simulation was only 64kbytes ... and a much more complete implementation somehow got lost when head of POK convinced corporate to kill vm370 product in the mid-70s (and transfer the people to work on MVS/XA) ... Endicott did eventually manage to resurrect the VM370 product administration ... but had to reconstitute a group from scratch. as referenced in this old email (discussing "capture ratio" and other things) ... it only took another 12kbytes of system services simulation to get the MVS applications into VM/370-CMS production http://www.garlic.com/~lynn/2006v.html#email800717 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
On Sun, Apr 9, 2017 at 12:01 PM, Clark Morris wrote: > [Default] On 9 Apr 2017 09:41:33 -0700, in bit.listserv.ibm-main > lindy.mayfi...@sas.com (Lindy Mayfield) wrote: > > >I only have CPU time from SMF 30 but I don't have elapsed time which is > very important. I'd like to somewhat infer that a high CPU time means the > job ran a long time. > > There is a step start time and date in the SMF 30 type 4 record. I am > not certain if there is a step stop time and date since I don't want > to take the time to bring up the appropriate manual and I don't have > access to the Assembler Macros. There may be other records that have > start and stop times and the SMF 26 records may have execution time > but only for the job. > The SMF record is written when the step ends. Therefore, I have alway _assumed_ that the SMF date&time written field (which exists on all SMF records) is the "step end time". > > Clark Morris > > -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
My question I guess was a bit more theoretical. If I submitted an assembler job that ran in a tight loop doing nothing but using CPU, it went straight into the RDR, high service class, and ran for 10 CPU seconds. I'd expect the job to run at least 10 seconds wall clock time, plus the overhead of the system, but never under 10 seconds unless it is multithreaded perhaps. >From SMF recs I can identify jobs sorted on cpu and excp to try to get the >worst offenders in all cases, but then I have to go into the individual job >log and see elapsed time. I have already discovered huge wait times that I >cannot explain due to what I think is taking 20 minutes to not find a dataset, >perhaps some sort of catalog search problem. So, as Lizette pointed out, my scheme has flaws because there are too many factors that influence elapsed time, including locating system issues from RMF3 and other nasty SMF record types. It's easier to write a program to parse the job logs. :) Thanks for all you help and knowledge. I joined this group about 17 years ago, and I'm still the baby of the group. :) /Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: sunnuntai 9. huhtikuuta 2017 22.16 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU Timerons/Seconds vs Wall-clock Time I am not sure that looking at one SMF record can tell the story. If the job ran long, was it due to I/O Looping Code Larger than normal Data Load And so on. Maybe other can provide better insight. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lindy Mayfield > Sent: Sunday, April 09, 2017 9:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > I only have CPU time from SMF 30 but I don't have elapsed time which > is very important. I'd like to somewhat infer that a high CPU time > means the job ran a long time. > > /Lindy > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: sunnuntai 9. huhtikuuta 2017 18.55 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > What are you trying to solve? > > Jobs get swapped in and out depending on what work they are doing. > > > Are you trying to relate wall clock to cpu time? I have seen jobs run > 2 hours wall clock time and only take 10 mins of CPU time. > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lindy Mayfield > > Sent: Sunday, April 09, 2017 8:48 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: CPU Timerons/Seconds vs Wall-clock Time > > > > This may or may not be the dumbest question I've asked this week, > > but I've been working with Linux a lot lately so that's my excuse. > > > > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I > > think), can I assume that it at least took 10 seconds of elapsed > > time to > run? > > > > Regards, > > Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
Guessing once again, if for "offending" you mean jobs using lot of CPU within one interval, it's better to look at SMF30 subtype other than 4 (2,3, or 6 maybe). Usually this "prunes" problems like jobs waiting for init or HSM recall and so on and gives you a good understanding about ASs using more CPU. With SMFINTVL little (reasonably) enough it can be a good point view. Regards. Massimo 2017-04-10 10:48 GMT+02:00 Lindy Mayfield : > My question I guess was a bit more theoretical. > > If I submitted an assembler job that ran in a tight loop doing nothing but > using CPU, it went straight into the RDR, high service class, and ran for > 10 CPU seconds. > > I'd expect the job to run at least 10 seconds wall clock time, plus the > overhead of the system, but never under 10 seconds unless it is > multithreaded perhaps. > > From SMF recs I can identify jobs sorted on cpu and excp to try to get the > worst offenders in all cases, but then I have to go into the individual job > log and see elapsed time. I have already discovered huge wait times that I > cannot explain due to what I think is taking 20 minutes to not find a > dataset, perhaps some sort of catalog search problem. > > So, as Lizette pointed out, my scheme has flaws because there are too many > factors that influence elapsed time, including locating system issues from > RMF3 and other nasty SMF record types. It's easier to write a program to > parse the job logs. :) > > Thanks for all you help and knowledge. I joined this group about 17 years > ago, and I'm still the baby of the group. :) > > /Lindy > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: sunnuntai 9. huhtikuuta 2017 22.16 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > I am not sure that looking at one SMF record can tell the story. > > If the job ran long, was it due to > > I/O > > Looping Code > > Larger than normal Data Load > > And so on. > > Maybe other can provide better insight. > > Lizette > > > > -Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Lindy Mayfield > > Sent: Sunday, April 09, 2017 9:42 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > > > I only have CPU time from SMF 30 but I don't have elapsed time which > > is very important. I'd like to somewhat infer that a high CPU time > > means the job ran a long time. > > > > /Lindy > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Lizette Koehler > > Sent: sunnuntai 9. huhtikuuta 2017 18.55 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time > > > > What are you trying to solve? > > > > Jobs get swapped in and out depending on what work they are doing. > > > > > > Are you trying to relate wall clock to cpu time? I have seen jobs run > > 2 hours wall clock time and only take 10 mins of CPU time. > > > > Lizette > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lindy Mayfield > > > Sent: Sunday, April 09, 2017 8:48 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: CPU Timerons/Seconds vs Wall-clock Time > > > > > > This may or may not be the dumbest question I've asked this week, > > > but I've been working with Linux a lot lately so that's my excuse. > > > > > > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I > > > think), can I assume that it at least took 10 seconds of elapsed > > > time to > > run? > > > > > > Regards, > > > Lindy > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
On Sun, 9 Apr 2017 15:48:12 +, Lindy Mayfield wrote: The easy answer is no it is not reasonable to think that. Min elapsed time = corrected recorded CPU time / # CPs Avram Friedman >This may or may not be the dumbest question I've asked this week, but I've >been working with Linux a lot lately so that's my excuse. > >For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), >can I assume that it at least took 10 seconds of elapsed time to run? > >Regards, >Lindy > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
On Sun, 9 Apr 2017 15:48:12 +, Lindy Mayfield wrote: >if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), can I assume >that it at least took 10 seconds of elapsed time to run? If it is a single task application, yes. If it runs multiple tasks, not necessarily. For example, if you have an application that attaches 4 additional tasks and each of the 5 tasks uses 5 seconds of CPU during the 10 seconds elapsed time, it would use a total of 25 seconds of CPU time. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
On 2017-04-09, at 10:57, Lindy Mayfield wrote: > you got me on that one, gil. :) trying to exploit the ambiguity of a Sunday. > guilty. > > i got a side gig to figure out some performance problems, and it ain't on > linux, but on a real machine. and nothing is good on tv at the moment. > Isn't Linux available on at least one "real machine"? 😊 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
>>> On 4/10/2017 at 12:13 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > Isn't Linux available on at least one "real machine"? Linux runs on just about every type of machine, "real" or not. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
On 4/9/2017 8:48 AM, Lindy Mayfield wrote: For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), can I assume that it at least took 10 seconds of elapsed time to run? Not unless you're 100% certain there was no multitasking and nothing was redirected to a specialty engine. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Timerons/Seconds vs Wall-clock Time
> Date:Tue, 11 Apr 2017 11:39:53 -0700 >From:Ed Jaffe >Subject: Re: CPU Timerons/Seconds vs Wall-clock Time >On 4/9/2017 8:48 AM, Lindy Mayfield wrote: >> For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), >> can I assume that it at least took 10 seconds of elapsed time to run? >Not unless you're 100% certain there was no multitasking and nothing was >redirected to a specialty engine. >Edward E Jaffe Good point Edward. If they use the default (shipped in SAMPLIB) IEFACTRT the CPU time reported is the time on CP plus the time on zIIP multiplied by the zIIP speed normalization factor (SMF30SNF). On a sub-capacity model the reported CPU time can be many times the elapsed. G. Tom Russell “Stay calm. Be brave. Wait for the signs” — Jasper FriendlyBear “… and remember to leave good news alone.” — Gracie HeavyHand -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: CPU Timerons/Seconds vs Wall-clock Time
> Elapsed time will ALWAYS be longer than CPU time. This is only true if there is no multitasking / multithreading in the job. Lindy asked quite generally if a job's elapsed time would always be longer than the cpu time it used. And the general answer would be no. My DB2 colleagues run DB2 reorgs as batch jobs. Just lately, I saw one of these job using 670% (yes, that is six-seven-zero) of cpu over a really long time (can't check the exact number right now). If that job would be given the access, the cpu usage in say 30 minutes of elapsed would be some 200 minutes. An extreme example, I admit. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN