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
