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
