Hal,
I should have been clear. The statement I disagreed with is:
" It does not really matter what the response times are,
the issue is that they are too slow"
I'm not sure where I can agree with you, and I still fail to see how near
perfect response time can be too slow.
Any volume averaging 0.3ms response time is pretty close to zero delay, where a
delay is something queued or waiting. I'm not sure why you don't believe this.
I've seen shorter response time with synthetic workloads designed to only use
local memory in the channel interface, but that's hardly applicable to
Lizette's problem.
I believe Response time does matter because it is a guide to the action
required. It just should not be considered as the only metric that decides if
IO is delaying an application.
In RMF III a cache hit is connect time only and counted as "Using." It will
not show up as a delay unless there is contention.
Ron
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
> Hal Merritt
> Sent: Thursday, July 22, 2010 7:49 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Any ROT for DASD Response time
>
> Short answer: yes. And you go on to agree. Let's take a look at the OP's
> issue: Not meeting SLA's. A logical first place to look is DASD, and we find
> 'delays'. What kind of delay and how long of a delay we don't know.
>
> The question is how long of a delay is normal and to be expected. A ROT for an
> acceptable range. I find it a little hard to believe that a DASD subsystem can
> deliver 0.3ms response times with measurable delays. Therefore, IMHO, any
> measurable delay should be investigated and, if feasible, reduced. To zero.
>
> Of course, I/O avoidance is almost always something we want to consider. But
> that does not address the OP's question.
>
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
> Ron Hawkins
> Sent: Wednesday, July 21, 2010 11:29 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Any ROT for DASD Response time
>
> Hal,
>
> Is that always true?
>
> If your application is getting 100% cache hits with 0.3ms response time, has a
> sub second service level, but issues 10,000 IO then there is no way you will
> meet your service level even though your response time is as near to perfect
> as it can be.
>
> The number of IO you can do can be as big a problem as the time the IO takes.
> Looking for some IO avoidance before handing over dollars for more cache,
> faster drives and SSD can will often result in improved Service Levels, while
> response stays the same, or even gets worse. It's all about reducing the net
> IO Time.
>
> For example a three level indexed KSDS can easily realize a 350-390% reduction
> in IO just by changing it to BLSR or SMB and using deferred writes. With that
> sort of saving would a DASD response time is 0.5ms or 10ms be important?
>
> Ron
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
> Of
> > Hal Merritt
> > Sent: Wednesday, July 21, 2010 10:32 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: [IBM-MAIN] Any ROT for DASD Response time
> >
> > Point is that you are not meeting your SLA goals. If DASD response time is
> an
> > issue, then it can be described as 'poor DASD performance'. It does not
> really
> > matter what the response times are, the issue is that they are too slow.
> >
> > In this context a ROT for any delay would be zero, IMHO.
> >
> > HTH and good luck.
> >
> >
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
> Of
> > Lizette Koehler
> > Sent: Wednesday, July 21, 2010 11:39 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Any ROT for DASD Response time
> >
> > We are running an EMC DMX4500 shared with the open system side. MVS has 9TB
> > and the open side has 500TB. So they win.
> >
> > We have points in time where our production application (DB2 Stored
> Procedures
> > with Native SQL) has slow responses.
> >
> > The DBAs are using RMF and TMON (DB2 and MVS) to isolate the problem.
> > However, they see DFHSM and say thats the problem.
> >
> > I think I am seeing delays on the dasd the DB2 system uses in RMF. But I am
> > not sure how to interpret the numbers.
> >
> > Is there a ROT that says if the delay rate is > ? then the dasd is poor
> > performaing?
> >
> > Thanks
> >
> > Lizette
> >
> >
> > NOTICE: This electronic mail message and any files transmitted with it are
> > intended
> > exclusively for the individual or entity to which it is addressed. The
> > message,
> > together with any attachment, may contain confidential and/or privileged
> > information.
> > Any unauthorized review, use, printing, saving, copying, disclosure or
> > distribution
> > is strictly prohibited. If you have received this message in error, please
> > immediately advise the sender by reply email and delete all copies.
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> NOTICE: This electronic mail message and any files transmitted with it are
> intended
> exclusively for the individual or entity to which it is addressed. The
> message,
> together with any attachment, may contain confidential and/or privileged
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution
> is strictly prohibited. If you have received this message in error, please
> immediately advise the sender by reply email and delete all copies.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
