One of my few remaining brain cells is overheating :o) In most of my tiny known universe, a Queue Depth is a way to express work units waiting on a resource. So, from an application point of view, yes, I suppose a queue depth could be thought of as concurrent I/O. But not in z land. When we say concurrent we really mean concurrent: fully parallel. Nobody waiting on anybody. I find it odd (and confusing) that *nix would use such a name to describe a parallel process. Or does it? Are those I/O's really concurrent?
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron Hawkins Sent: Monday, August 18, 2008 1:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Here we go again (was z/OS Hot Topics 19) Chris, Yes, you obviously don't know 'NIX Internals :-) Q Depth is the number of concurrent IO that can be scheduled on a SCSI resource. Typically it is a setting on a HBA. It is not a count of Queued IO in the OS. In SCSI the TID is pretty close to being the same as a UCB, but there is no attempt to queue on the TID in the OS. The throttle on the number of concurrent IO from an OS to a LUN is the Q-Depth. With Q-Depth set to 8 you can have 8 concurrent IO scheduled on a LUN. With two HBA and Multi-path software you can have 16. I believe the name evolved from how the target device will queue the requests in pre cache days. This still happens for cache-miss IO requests on the Disk Drives for CKD and FCP - it's all SCSI by the time it gets to the HDD. Don't misunderstand the name. Q-depth is named for what happens on the target device. If I took the label PAV literally I would be waiting for my IO to arrive on a yummy piece of meringue with whipped cream, peaches, and a dollop of passion fruit. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Blaicher, Chris > Sent: Monday, August 18, 2008 9:07 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: [IBM-MAIN] Here we go again (was z/OS Hot Topics 19) > > Ron, > > I don't know 'NIX internals, but I would find a queue depth of 4, let > alone 16 or 32 as totally unacceptable in z/OS land. That is what PAV > is for, to reduce the queue depth. > > Given enough PAV addresses, you should never see much if and queue > depth. > > Chris Blaicher > Personal opinion only. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Ron Hawkins > Sent: Monday, August 18, 2008 10:43 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Here we go again (was z/OS Hot Topics 19) > > John, > > Big Honkin' volumes in 'NIX land usually operate with Queue Depths of 8 > or > 16, and occasionally 32. I don't see any reason why HiperPAV would be > any > different. > > Ron > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > Behalf Of John Eells > > Sent: Monday, August 18, 2008 8:12 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: [IBM-MAIN] Here we go again (was z/OS Hot Topics 19) > > > > Hal Merritt wrote: > > > Some performance improvements in that process are included. > > > > > > Also, a (extra cost?) 'hyper PAV' that uses a 'ucb' from a pool > only > > for > > > the duration of the I/O. Talk about instant gratification :-) > > <snip> > > > > HyperPAV (yes, it costs more for the DS8000 feature) generally > requires > > the use of fewer PAV aliases, which chew up fewer subchannels. For > Big > > Honkin' Volumes...er, that is, EAVs, I'd expect that having the > systems > > manage the PAV aliases dynamically would be a reasonably big plus, > > because I'd expect most or all EAVs to have higher peak data rates > than > > their non-EAV counterparts on the average. > > > > -- > > John Eells > > z/OS Technical Marketing > > IBM Poughkeepsie > > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > - > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
