jwgli...@gmail.com (John Gilmore) writes: > Lynn's most recent response is unsatisfactory, in substance evasive. > > Let us for the sake of the argument stipulate, though this is not > usually the case, that some "non-mainframe server" can perform some > single I/O operation faster than some mainframe. > > It turns out that this stipulation does not much help Lynn's argument. > > Mainframes handle aggregate I/O workloads, comprised of many single > I/O operations, faster and with much less CP involvement than any > "non-mainframe server". CPU involvement is much lower, and many I/O > operations are handled concurrently. The channels, which for some > reason Lynn seems to want to disparage, do most of the work. > > Mark Post's point nevertheless remains crucial. Every case is indeed > different. There are single applications that, particularly when they > are considered in isolation, are easy enough to accomplish on a > "non-mainframe" server. It is when many such applications are > aggregated together that the mainframe comes into its own as an > alternative, a highly attractive one, to server farms.
recent discussion in a.f.c. about fibre-channel standard (work started 1988) ... in the 90s, some POK mainframe channel engineers started to participate ... working on layering mainframe channel conventions on top of fibre-channel ... which drastically cuts the throughput (compared to underlying fibre-channel) ... and eventually turns into FICON. http://www.garlic.com/~lynn/2012o.html#24 Assembler vs. COBOL--processing time, space needed in the past couple years ... there has been some work on FICON with introduction of TCW & zHPF to coming closer to approx. the underlying fibre-channel throughput (looks to give FICON about factor of three times improvement). recent posts mentioning TCW enhancement to FICON http://www.garlic.com/~lynn/2012m.html#4 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#5 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#11 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#13 Intel Confirms Decline of Server Giants HP, Dell, and IBM http://www.garlic.com/~lynn/2012m.html#28 I.B.M. Mainframe Evolves to Serve the Digital World http://www.garlic.com/~lynn/2012m.html#43 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012n.html#19 How to get a tape's DSCB http://www.garlic.com/~lynn/2012n.html#44 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe? http://www.garlic.com/~lynn/2012n.html#51 history of Programming language and CPU in relation to each http://www.garlic.com/~lynn/2012n.html#70 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe? http://www.garlic.com/~lynn/2012n.html#72 Mainframes are still the best platform for high volume transaction processing IBM has z196 benchmark with peak of 2m IOPS with 104 FICON channels, 14 storage subsystems, and 14 system assist processors. It mentions that the 14 SAPs are capable of peak 2.2m SSCH/sec running at 100% cpu busy, but recommends SAPs run at 70% or less (i.e. 1.5m SSCH/sec). there is also a recent emulex announcement single fibre-channel for e5-2600 capable of over one millions IOPS (compared to z196 peak of 2m IOPS using 104 FICON channels) other aside, lots of past posts getting to play (IBM) disk engineer in bldgs. 14&15 ... and working on mainframe channel & disk thruput http://www.garlic.com/~lynn/subtopic.html#disk -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
