Re: Calculating duration from subtracting TOD clocks
Thank you! On Thu, 26 Nov 2020 at 23:32, Charles Mills wrote: > I should add that I have code that does exactly what you are talking > about. That's why I am familiar with the problem. > > // Keep track of time in [particular function] > Platform::STCKF(); > > // call [a particular function here] > > // Keep track of time in [particular function] > Platform::STCKF(); > timeInFunction += (TOD - EntryTOD); > > Platform::STCKF() is an inline call to __stckf() which is a hardware STCKF. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Charles Mills > Sent: Thursday, November 26, 2020 1:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Calculating duration from subtracting TOD clocks > > @Steff, I totally "get" your question. You have some function that is > called repeatedly and you want to know the total elapsed time spent in that > function. So you want to get a TOD on the way in, subtract it from a TOD on > the way out, and then sum those differences. Makes perfect sense. And you > are worried that you are factoring in 12 irrelevant bits that may add up > over time. > > You are (mostly) mathematically correct but if it were me I would not > worry about it. First of all, I suspect that in modern machines the actual > clock resolution is a lot finer than 1 usecond, so not all of those 12 bits > are irrelevant. Second, I suspect much of the error would cancel itself > out. But yes, I don't really know, and worst case, you could be off by > almost a usecond on every difference, and after a few thousand sums it > might amount to something. > > What to do? Well, you could just AND off those 12 bits. Little harm, > although on a box with finer resolution you are throwing away information > that might be relevant. How about just using STCKF; it has two benefits: > first, as the name implies, it is FASTER than an STCK in certain > circumstances -- much faster (the exact circumstances are irrelevant to > this discussion, but trust me, it is a LOT faster sometimes). And second, > the PoOp says "For STORE CLOCK FAST, when the value of a running clock is > stored, bits to the right of the rightmost bit that is incremented are > stored as zeros." > > QED > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Steff Gladstone > Sent: Thursday, November 26, 2020 7:08 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Calculating duration from subtracting TOD clocks > > Could someone answer 4gb's 11-year-late question? > > On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > > > On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote: > > > Hi, > > > I need to subtract two TOD times to find elapsed time. Currently I > convert > > > the two TOD times with STCKCONV and determine the elaped time > individually, > > > and then compute the difference. This works. However I thought I could > > > optimize the conversion, a little bit and I was wondering why not > subtract the > > > two TOD times to begin with. > > > > > > As I understand TOD time is the number of mic seconds elapsed since > midnight > > > of 1900-01-01. So when I subtract one TOD value from another the > duration > > > must be in micro seconds. > > > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD > value before adding or subtracting them? Those low order bits are not > fractions of a microsecond, so including them in the math can produce up to > a micro second error. If you add a series of TOD values without clearing > the low bits that can add up to real money. > > -- > 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: Calculating duration from subtracting TOD clocks
On Fri, 27 Nov 2020 08:55:35 -0500, Peter Relson wrote: > >That fits with my understanding that those bits to the right are to >ensure STCK uniqueness in a multi-CPU system, and STCK doesn't >guarantee uniqueness on any system -- two readings may be taken >between increments. > > >STCK values are guaranteed to be unique within an LPAR (whether 1-CPU or >multi-CPU). > I stand corrected. Read "STCKF" for my second use of "STCK". Typo, I think. My understanding is that in the Bad Old Days when each CPU had its own TOD clock, the low-order bits were different for each CPU ensuring uniqueness. Thus it might be possible that if a task were dispatched on a different CPU between readings the interval might appear negative. I doubt that the re-dispatch could be performed so quickly. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Calculating duration from subtracting TOD clocks
>And you are worried that you are factoring in 12 irrelevant bits that may add up over time. The 12 bits really are not irrelevant. >bits to the right of the rightmost bit that is incremented are stored as zeros True. But do you know which is the rightmost bit that is incremented? It is not bit 51 of the TOD clock (that has been true for a long time). It is machine-dependent. That fits with my understanding that those bits to the right are to ensure STCK uniqueness in a multi-CPU system, and STCK doesn't guarantee uniqueness on any system -- two readings may be taken between increments. STCK values are guaranteed to be unique within an LPAR (whether 1-CPU or multi-CPU). STCKF values are not guaranteed to be unique. You can think of STCK as spinning until the increment occurs. STCKF does not need to spin. That spinning is the (potentially large) difference between the time taken by STCK and that taken by STCKF. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Calculating duration from subtracting TOD clocks
On Thu, 26 Nov 2020 13:15:36 -0800, Charles Mills wrote: > >... And second, the PoOp says "For STORE CLOCK FAST, when the value of a >running clock is stored, bits to the right of the rightmost bit that is >incremented are stored as zeros." > That fits with my understanding that those bits to the right are to ensure STCK uniqueness in a multi-CPU system, and STCK doesn't guarantee uniqueness on any system -- two readings may be taken between increments. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Calculating duration from subtracting TOD clocks
I should add that I have code that does exactly what you are talking about. That's why I am familiar with the problem. // Keep track of time in [particular function] Platform::STCKF(); // call [a particular function here] // Keep track of time in [particular function] Platform::STCKF(); timeInFunction += (TOD - EntryTOD); Platform::STCKF() is an inline call to __stckf() which is a hardware STCKF. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, November 26, 2020 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Calculating duration from subtracting TOD clocks @Steff, I totally "get" your question. You have some function that is called repeatedly and you want to know the total elapsed time spent in that function. So you want to get a TOD on the way in, subtract it from a TOD on the way out, and then sum those differences. Makes perfect sense. And you are worried that you are factoring in 12 irrelevant bits that may add up over time. You are (mostly) mathematically correct but if it were me I would not worry about it. First of all, I suspect that in modern machines the actual clock resolution is a lot finer than 1 usecond, so not all of those 12 bits are irrelevant. Second, I suspect much of the error would cancel itself out. But yes, I don't really know, and worst case, you could be off by almost a usecond on every difference, and after a few thousand sums it might amount to something. What to do? Well, you could just AND off those 12 bits. Little harm, although on a box with finer resolution you are throwing away information that might be relevant. How about just using STCKF; it has two benefits: first, as the name implies, it is FASTER than an STCK in certain circumstances -- much faster (the exact circumstances are irrelevant to this discussion, but trust me, it is a LOT faster sometimes). And second, the PoOp says "For STORE CLOCK FAST, when the value of a running clock is stored, bits to the right of the rightmost bit that is incremented are stored as zeros." QED Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: Thursday, November 26, 2020 7:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Calculating duration from subtracting TOD clocks Could someone answer 4gb's 11-year-late question? On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote: > > Hi, > > I need to subtract two TOD times to find elapsed time. Currently I convert > > the two TOD times with STCKCONV and determine the elaped time individually, > > and then compute the difference. This works. However I thought I could > > optimize the conversion, a little bit and I was wondering why not subtract the > > two TOD times to begin with. > > > > As I understand TOD time is the number of mic seconds elapsed since midnight > > of 1900-01-01. So when I subtract one TOD value from another the duration > > must be in micro seconds. > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD value before adding or subtracting them? Those low order bits are not fractions of a microsecond, so including them in the math can produce up to a micro second error. If you add a series of TOD values without clearing the low bits that can add up to real money. -- 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: Calculating duration from subtracting TOD clocks
@Steff, I totally "get" your question. You have some function that is called repeatedly and you want to know the total elapsed time spent in that function. So you want to get a TOD on the way in, subtract it from a TOD on the way out, and then sum those differences. Makes perfect sense. And you are worried that you are factoring in 12 irrelevant bits that may add up over time. You are (mostly) mathematically correct but if it were me I would not worry about it. First of all, I suspect that in modern machines the actual clock resolution is a lot finer than 1 usecond, so not all of those 12 bits are irrelevant. Second, I suspect much of the error would cancel itself out. But yes, I don't really know, and worst case, you could be off by almost a usecond on every difference, and after a few thousand sums it might amount to something. What to do? Well, you could just AND off those 12 bits. Little harm, although on a box with finer resolution you are throwing away information that might be relevant. How about just using STCKF; it has two benefits: first, as the name implies, it is FASTER than an STCK in certain circumstances -- much faster (the exact circumstances are irrelevant to this discussion, but trust me, it is a LOT faster sometimes). And second, the PoOp says "For STORE CLOCK FAST, when the value of a running clock is stored, bits to the right of the rightmost bit that is incremented are stored as zeros." QED Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: Thursday, November 26, 2020 7:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Calculating duration from subtracting TOD clocks Could someone answer 4gb's 11-year-late question? On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote: > > Hi, > > I need to subtract two TOD times to find elapsed time. Currently I convert > > the two TOD times with STCKCONV and determine the elaped time individually, > > and then compute the difference. This works. However I thought I could > > optimize the conversion, a little bit and I was wondering why not subtract the > > two TOD times to begin with. > > > > As I understand TOD time is the number of mic seconds elapsed since midnight > > of 1900-01-01. So when I subtract one TOD value from another the duration > > must be in micro seconds. > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD value before adding or subtracting them? Those low order bits are not fractions of a microsecond, so including them in the math can produce up to a micro second error. If you add a series of TOD values without clearing the low bits that can add up to real money. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Calculating duration from subtracting TOD clocks
On Thu, 26 Nov 2020 17:07:44 +0200, Steff Gladstone wrote: > >> On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote: >> > Hi, >> > I need to subtract two TOD times to find elapsed time. Currently I convert >> > the two TOD times with STCKCONV and determine the elaped time individually, >> > and then compute the difference. This works. However I thought I could >> > Subtracting converted times is certainly the long way around: borrow negative seconds from minutes; borrow negative minutes from hours; "Thirty days hath September ..." >> > optimize the conversion, a little bit and I was wondering why not subtract >> > the >> > two TOD times to begin with. >> > >> > As I understand TOD time is the number of mic seconds elapsed since >> > midnight >> > of 1900-01-01. So when I subtract one TOD value from another the duration >> > must be in micro seconds. > Actually. microseconds/4096. > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD >value before adding or subtracting them? Those low order bits are not >fractions of a microsecond, so including them in the math can produce up to >a micro second error. If you add a series of TOD values without clearing >the low bits that can add up to real money. > I see little reason to add two or more time values in whatever format: 1984 CE + 2020 CE = 4004 ??? In one convention, the low order bits of the (E)TOD clock contain the CPU ID. So, yes if the two TOD values are taken on different CPUs, an error is possible. STCKCONV of the difference of two plausible TOD values is likely to show a date/time in 1900 CE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Calculating duration by subtracting TOD clocks
Could someone answer 4gb's question? On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > Shouldn't you clear the low order 12 bits of each TOD value before adding or subtracting them? Those low order bits are not fractions of a microsecond, so including them in the math can produce up to a micro second error. If you add a series of TOD values without clearing the low bits that can add up to real money. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Calculating duration from subtracting TOD clocks
Could someone answer 4gb's 11-year-late question? On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote: > > Hi, > > I need to subtract two TOD times to find elapsed time. Currently I convert > > the two TOD times with STCKCONV and determine the elaped time individually, > > and then compute the difference. This works. However I thought I could > > optimize the conversion, a little bit and I was wondering why not subtract the > > two TOD times to begin with. > > > > As I understand TOD time is the number of mic seconds elapsed since midnight > > of 1900-01-01. So when I subtract one TOD value from another the duration > > must be in micro seconds. > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD value before adding or subtracting them? Those low order bits are not fractions of a microsecond, so including them in the math can produce up to a micro second error. If you add a series of TOD values without clearing the low bits that can add up to real money. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
