Star
Allan Staller <allan.stal...@hcl.com> 於 2018年2月21日 星期三寫道： > GRS- Ring or Star? > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tommy Tsui > Sent: Wednesday, February 21, 2018 2:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DASD problem > > We use HDS instead not Ibm, we report this case to Ibm and perform the > same operation on monoplex lpar the result is around 7mins write 28gb data > using utility IEBDG, but use 12 mins while in sysplex lpar with same DASD, > only can find is high disconnect time from RMF report > > Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月21日 星期三寫道： > > > Tommy, > > > > The RTD at 30km is quite small, and the benefit of write spoofing will > > be small. > > > > There is an option to turn on write spoofing with the FCP PPRC links > > on IBM storage, but you should check with them that it is a benefit at > > small distances on your model of storage at all write rates. > > > > Ron > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Tommy Tsui > > Sent: Tuesday, February 20, 2018 8:22 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [IBM-MAIN] DASD problem > > > > Is there any way to improve the pprc command latency and round trip > > delay time? > > Anything can tune on DASD Hardware or switch side? > > Anything can tune on os side? BUFNO, > > > > Rob Schramm <rob.schr...@gmail.com> 於 2018年2月21日 星期三寫道： > > > > > It used to be 20 or 25 buffers to establish the I/o sweet spot. > > > Maybe with the faster dasd the amount is different. > > > > > > Rob > > > > > > On Tue, Feb 20, 2018, 7:53 PM Tommy Tsui <tommyt...@gmail.com> wrote: > > > > > > > Hi Ron, > > > > You are right when I changed BUFNO to 255, The overall elapsed > > > > time reduce from 12mins to 6 mins, So what can I do now,? Change > > > > BUFNO only ? How about vsam or db2 performance? > > > > > > > > > > > > Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月21日 星期三寫道： > > > > > > > > > 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 > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO > > > > IBM-MAIN > > > > > > > -- > > > > > > Rob Schramm > > > > > > -------------------------------------------------------------------- > > > -- 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 > ::DISCLAIMER:: > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------------------------------------------------ > -------------------------------------- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------------------------------------------------ > -------------------------------------- > > ---------------------------------------------------------------------- > 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
