After I switched the zhpf to No , the elapsed time reduce from 12 to 7 mins? How comes, is it the switch or director no support the concurrent i/o from zhpf?
Tommy Tsui <[email protected]> 於 2018年2月21日 星期三寫道： > 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 <[email protected]> 於 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:[email protected]] On >> Behalf Of Tommy Tsui >> Sent: Tuesday, February 20, 2018 8:22 PM >> To: [email protected] >> 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 <[email protected]> 於 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 <[email protected]> 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 <[email protected]> 於 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:[email protected]] >> > On >> > > > Behalf Of Tommy Tsui >> > > > Sent: Tuesday, February 20, 2018 2:42 AM >> > > > To: [email protected] >> > > > 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 <[email protected]> 於 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:[email protected] >> > ] >> > > > > On Behalf Of Tommy Tsui >> > > > > Sent: Thursday, February 15, 2018 12:41 AM >> > > > > To: [email protected] >> > > > > 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 <[email protected]> 於 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:[email protected]] >> > > > > > 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 [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 >> > > > > > >> > > > > >> > > > > ------------------------------------------------------------ >> > ---------- >> > > > > 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 >> > > > > >> > > > >> > > > ------------------------------------------------------------------ >> > > > ---- 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 >> > > > >> > > >> > > -------------------------------------------------------------------- >> > > -- For IBM-MAIN subscribe / signoff / archive access instructions, >> > > send email to [email protected] with the message: INFO >> > > IBM-MAIN >> > > >> > -- >> > >> > Rob Schramm >> > >> > ---------------------------------------------------------------------- >> > 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 >> >> ---------------------------------------------------------------------- >> 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
