John McKown writes: >2) new type of CP: IFP - Integrated Firmware Processor, like a SAP, but for >the "native PCIe" features such as 10 Gb RoGE and zEDC Express
Yes, but you don't even have to think about it. The system comes pre-configured with the IFP at no additional charge, it's invisible, and they are not orderable. >5) SMT (hyperthreading) only on IFL and zIIP engines (not CPs). Apparently >when running SMT, the individual threads can't match the speed of a non-SMT >CP, but their aggregate power may. The aggregate throughput with SMT enabled on IFLs and zIIPs "almost always" exceeds (not just matches) the aggregate throughput without SMT. That's why it's there, and that's why it's generally recommended. There's a really simple illustration in one of the presentations I saw with two pictures: a one lane road with a 60 mile per hour speed limit and a two lane road with a 45 mile per hour speed limit. (Let's assume speed limits are respected.) Those numbers are not necessarily representative of relative single thread performance, but that's the idea. You now have the option to double the lanes per IFL and per zIIP with an elongation of execution time per thread. Very, very often that's a superb choice to make, but of course your mileage may vary, which is why you can choose and also why you can change your mind. Yes, there's a lot of information already available (with some more coming) to help you make an informed decision. >8) HMC can also be in a 1U rack mounted machine (in the box? it doesn't >say). You can use a preexisting rack you already have, or you can order one from IBM if you need one. In either event we recommend placing the HMC within the 22U to 26U range for best ergonomic results, but that's up to you. >10) Curious statement: ><quote> >If only Linux on z Systems is to be run under z/VM, then a z/VM mode LPAR >is not required, >and we suggest that a Linux-only LPAR be used instead. ></quote I think others have responded to this question pretty well. I agree, it really has nothing to do with licensing per se. It's a configuration suggestion, as noted. On the other hand, if you'd like your Linux guests to at least have the occasional ability to borrow some CP capacity (whether you actually end up doing so or not), then a z/VM Mode LPAR would be suggested. z/VM Mode LPARs are capable of spanning IFLs and other engine types. Often that's quite useful, and that's why we have that LPAR type. But if you don't plan to take advantage of that feature, and if you prefer to keep Linux in its Linux IFL zone (as it were), then we suggest a Linux-only LPAR. Let me give an example of when you might do this. Let's suppose your z/OS LPARs peak during the day, at let's say 9:00 a.m., and that it's a pretty big peak relative to the rest of your workday. Your Linux environments, however, peak at 1:00 a.m. when they're busy running (for example) IBM InfoSphere BigInsights for Hadoop-driven analysis. But at 1:00 a.m. you've got plenty of underutilized capacity over on your CPs. In that case it might be perfectly reasonable to have a z/VM Mode LPAR to span the engine types, keeping in mind that you will need to license z/VM and your other software for the number of engines used. But that could be a very sensible way to take advantage of your server capacity most efficiently. There are also many dev/test use cases where you'd have the same sort of patterns. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
