Interesting numbers. But I looked at the current doc and it still appears to be problem state only.
Also, do you numbers include setup or just program check handling? I figured FRRs would be a lot better than ESTAE(X). On Thu, 2 Apr 2020 19:28:13 -0500 Jim Mulder <d10j...@us.ibm.com> wrote: :> These are my results from a benchmark I did 4 years ago: :> :>Testcases which loop recovering/retrying from an :>operation exception. :>Using default system trace size - 1MB per CPU, with :>20 CPUs, so 20MB of data to snap) :>z13 machine :> :>Recovery Iterations CPU seconds Ratio :>---------------- ---------- ----------- ----- :>ESPIE x'200000' 3.53 1.0 :>FRR x'200000' 45.66 12.9 :>ESTAEX (no SNAPTRC) x' 20000' 98.95 28.0 :>ESTAEX (SNAPTRC) x' 1000' 102.83 14,914.7 :> :> :>Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. :>Poughkeepsie NY :>(845) 435-4741 :>D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) :> :>> From: "Lennie Dymoke-Bradshaw" <lenni...@rsmpartners.com> :>> To: IBM-MAIN@LISTSERV.UA.EDU :>> Date: 04/02/2020 08:13 PM :>> Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) :>> Sent by: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> :>> :>> I think the reason that handling interrupts in ESPIE is faster than :>> ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE :>> sets an exit to the SLIH. :>> :>> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd :>> Web: www.rsmpartners.com :>> Dance like no one is watching. Encrypt like everyone is. :>> :>> -----Original Message----- :>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On :>> Behalf Of Charles Mills :>> Sent: 02 April 2020 20:59 :>> To: IBM-MAIN@LISTSERV.UA.EDU :>> Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd :>sub-tasks) :>> :>> As Peter seems to imply, ESPIE interrupts are apparently noticeably :>> lower overhead than ESTAE interrupts. If data or addressing :>> exceptions were expected I definitely *would* use ESPIE. I would :>> save ESTAE for unexpected (well, expected unexpected) conditions. My :>> opinion: no benchmarks, no source code. :>> :>> Charles :> :> :> :>---------------------------------------------------------------------- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen <bdis...@dissensoftware.com> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
