Rempel, Horst writes: > I am a little bit confused because on of your german IBM colleagues told me > that hipersocket transfers is the > job of the service processor (I/O processor) and will allways run at full > speed independent of the capacity setting for the cpu.
The redbook "HiperSockets Implementation Guide" (SG24-6816) available from http://www.redbooks.ibm.com/abstracts/sg246816.html explains the common case in section 1.3: HiperSockets operations are executed on the CP where the I/O request is initiated. HiperSockets starts read or write operations. The completion of a data move is indicated by the sending side to the receiving side with a Signal Adapter (SIGA) instruction. Optionally, the receiving side can use dispatcher polling instead of handling SIGA interrupts. The I/O processing is performed reducing demand on the System Assist Processor (SAP®). This new implementation is also called “thin interrupt”. However, when looking for low level detail, I usually head for the IBM Journal of R&D and the Hipersockets paper in the z900 edition includes an extra twist: "zSeries features for optimized sockets-based messaging: HiperSockets and OSA-Express" (Baskey et al) http://www.research.ibm.com/journal/rd/464/baskey.html For optimization of latency, the performance-critical data transfer between operating system images for the message-passing functionality has been implemented in millicode. That code executes synchronously on the processor that initiates the network traffic using the SIGA instruction. Since the data transfer is executed synchronously on the issuing processor, the number of executed instructions must be kept small for this implementation. Therefore, the data transfer is limited to a maximum of 64 KB per SIGA instruction, and all data associated with a single SIGA instruction must be directed toward the same target operating system image. That way only IP unicast operations are executed synchronously on the CP, while IP multicast operations are asynchronously executed on the SAP. So it looks as through IP multicast sending is handled by the SAP instead of the CP (thought it's possible of course that things have changed in z990 and later). In the case of a sub-uni, I wonder what the difference in performance would be between unicasting to the target LPAR and multicasting to a group containing only a single IP address for the LPAR. Yet another example where, as Alan says, the best thing to do is measure in the desired environment. --Malcolm -- Malcolm Beattie System z SWG/STG, Europe IBM UK
