Tommy, With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed are independent of one another, but the stepped down speed elongate the Remote IO.
In simple terms a block that you write from the host to the P-VOL takes 0.5ms to transfer on 16Gb FICON, and but then you do the synchronous write on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to transfer. This time is in addition to command latency and round-trip delay time. As described below, this impact will be less for long, chained writes because of the Host/PPRC overlap. I'm not sure how you simulate this on your monoplex, but I assume you set up a PPRC pair to the remote site. If you are testing with BSAM or QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the single block impact. If you are using zHPF, I think you can vary the BUFNO or NCP to get up to 255 chained blocks. I'm not aware of anything in GRS that adds to remote IO disconnect time. Ron -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tommy Tsui Sent: Tuesday, February 20, 2018 2:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] DASD problem Hi Ron, What happens to if our ficon card is 16gb, and fcp connection is 2gb, I try to do the simulation on monoplex lpar , the result is fine, now we are suspect the GRS or other system parm which will increase the disconnect time Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月 15日 星期四寫道： > Tommy, > > This should not be a surprise. The name "Synchronous Remote Copy" > implies the overhead that you are seeing, namely the time for the > synchronous write to the remote site. > > PPRC will more than double the response time of random writes because > they the Host write to cache has the additional time of controller > latency, round trip delay, and block transfer before the write is > complete. On IBM and HDS (not sure with EMC) the impact is greater for > single blocks, as chained sequential writes have some overlap between > the host write, and the synchronous write. > > Some things to check: > > 1) Buffer Credits on ISLs between the sites. If no ISLs then settings > on the storage host ports to cater for 30km B2B credits > 2) Channel speed step-down - If your FICON channels are 8Gb, and the > FCP connections are 2Gb, then PPRC writes will take up to four times > longer to transfer. It dep[ends on the block size. > 3) Unbalanced ISLs - ISLs do not automatically rebalance after one drops. > The more concurrent IO there is on an ISL, the longer the transfer > time for each PPRC write. There may be one opr more ISL that are not > being used, while others are overloaded > 4) Switch board connections not optimal - talk to your switch vendor > 5) Host adapter ports connections not optimal - talk to your storage > vendor > 6) Sysplex tuning may identify IO that can convert from disk to > Sysplex caching. Not my expertise, but I'm sure there are some red books. > > There is good information on PPRC activity in the RMF Type 78 records. > You may want to do some analysis of these to see how transfer rates > and PPRC write response time correlate with your DASD disconnect time. > > Final Comment: do you really need synchronous remote copy? If your > company requires zero data loss, then you don't get this from > synchronous replication alone. You must use the Critical=Yes option > which has it's own set of risks and challenges. If you are not using > GDPS and Hyperswap for hot failover, then synchronous is not much better than > asynchronous. > Rolling disasters, transaction roll back, and options that turn off > in-flight data set recovery can all see synchronous recovery time end > up with the same RPO as Asynchronous. > > Ron > > > > > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tommy Tsui > Sent: Thursday, February 15, 2018 12:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] DASD problem > > Hi, > The distance is around 30km, do you know any settings on sysplex > environment such as GRS and JES2 checkpoint need to aware? > Direct DASD via San switch to Dr site , 2GBPS interface , we check > with vendor, they didn't find any problem on San switch or DASD, I > suspect the system settings > > Alan(GMAIL)Watthey <a.watt...@gmail.com> 於 2018年2月15日 星期四寫道： > > > Tommy, > > > > This sounds like the PPRC links might be a bit slow or there are not > > enough of them. > > > > What do you have? Direct DASD to DASD or via a single SAN switch or > > even cascaded? What settings (Gbps) are all the interfaces running > > at (you can ask the switch for the switch and RMF for the DASD)? > > > > What type of fibre are they? LX or SX? What kind of length are they? > > > > Any queueing? > > > > There are so many variables that can affect the latency. Are there > > any of the above that you can improve on? > > > > I can't remember what IBM recommends but 80% sounds a little high to me. > > They are only used for writes (not reads). > > > > Regards, > > Alan Watthey > > > > -----Original Message----- > > From: Tommy Tsui [mailto:tommyt...@gmail.com] > > Sent: 15 February 2018 12:15 am > > Subject: DASD problem > > > > > > > > Hi all, > > > > > > Our shop found the most job elapse time prolong due to pprc > > synchronization versus without pprc mode. It's almost 4 times faster > > if without pprc synchronization. Is there any parameters we need to > > tune on z/os or disk subsystem side? We found the % disk util in RMF > > report over 80, Any help will be appreciated. Many thanks > > > > -------------------------------------------------------------------- > > -- 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 > > ---------------------------------------------------------------------- > 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
