Thank you! On Thu, 26 Nov 2020 at 23:32, Charles Mills <[email protected]> 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(&EntryTOD); > > // call [a particular function here] > > // Keep track of time in [particular function] > Platform::STCKF(&TOD); > 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:[email protected]] On > Behalf Of Charles Mills > Sent: Thursday, November 26, 2020 1:16 PM > To: [email protected] > 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:[email protected]] On > Behalf Of Steff Gladstone > Sent: Thursday, November 26, 2020 7:08 AM > To: [email protected] > 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, [email protected] 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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
