Re: Hipersockets Performance Metrics
Part of the limiting factor is the engine speed at either end. If one of the ends is subcapacity, it will be part of the bottleneck. Knutson, Sam wrote: Hi, I had a co-worker who is setting up a Hipersocket connection ask if there is any active or historical way to monitor performance? My consideration was to look at the FTP throughput. I cannot imagine you could saturate a Hipersocket pipe? Would the limiting factor outside of I/O on either end be utilization of a SAP process the data movement? Anyone have any more information or pointers to what goes on inside the covers to execute the data movement from one LPAR to another? Conceptually transfer of data at memory speed is fine but there has to be an engine involved my WAG was the SAP handled it but I am trying to find out. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets Performance Metrics
Sam, On the z/OS side of things, you can always look at the channel stats for the IQD CHIPID. If you are having any performance issues it will show up there. On the IP side you will want to make sure the MTU size on the link matches the HCD defined size. Brad S. Carson Manager z/Series Technical Support Enterprise Systems Laboratory Corporation of America (336) 436-8294 >>> [EMAIL PROTECTED] 6/12/2008 11:33:03 AM >>> Hi, I had a co-worker who is setting up a Hipersocket connection ask if there is any active or historical way to monitor performance? My consideration was to look at the FTP throughput. I cannot imagine you could saturate a Hipersocket pipe? Would the limiting factor outside of I/O on either end be utilization of a SAP process the data movement? Anyone have any more information or pointers to what goes on inside the covers to execute the data movement from one LPAR to another? Conceptually transfer of data at memory speed is fine but there has to be an engine involved my WAG was the SAP handled it but I am trying to find out. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the LabCorp Privacy Officer at [EMAIL PROTECTED] or call (877) 23-HIPAA / (877) 234-4722. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
On Tue, 9 Oct 2007 11:01:28 +0200, R.S. wrote: >Jan MOEYERSONS wrote: >>>>>> STOR 'NULLFILE' >>>125 Storing data set NULLFILE >>> >>> ... I wonder where it went? >> >> Would that not be the equivalent of a dummy file? I seem to remember that >> >> //NONO DD DSN=NULLFILE >> >> is the same as >> >> //NONO DD DUMMY >> True, unless John G. is lurking to dispute what it says in the RM. >It is the same. However NULLFILE can be used in FTP (as file name), >while DD DUMMY would require special syntax. >What's funny, NULLFILE requires RACF authorization. At least in ftp. > My puzzlement arose when I discovered that some UNIX-like utilities such as ftp and cp fail when //'NULLFILE' is supplied as a source file, but (ftp at least) can use it as a target file. RACF seems not to be the answer because I don't believe RACF supports allowing write access to a data set while prohibiting read access. My conjecture now is that such utilities will supply default DCB attributes for an output data set, but not for an input data set: it makes little sense to try to guess characteristics of an input data set which has never been opened, while a reasonable guess can be made for creating a new data set. It's disappointing that such utilities don't follow through with their support of Classic data sets by displaying Classic messages such as IEC141I 013-nn which are well described in M&C. (I'm guessing at the code; LOOKAT seems broken just now.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
Jan MOEYERSONS wrote: >>> STOR 'NULLFILE' 125 Storing data set NULLFILE ... I wonder where it went? Would that not be the equivalent of a dummy file? I seem to remember that //NONO DD DSN=NULLFILE is the same as //NONO DD DUMMY It is the same. However NULLFILE can be used in FTP (as file name), while DD DUMMY would require special syntax. What's funny, NULLFILE requires RACF authorization. At least in ftp. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
>>>> STOR 'NULLFILE' >125 Storing data set NULLFILE > >... I wonder where it went? > Would that not be the equivalent of a dummy file? I seem to remember that //NONO DD DSN=NULLFILE is the same as //NONO DD DUMMY Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
On Sat, 6 Oct 2007 18:43:25 -0400, John S. Giltner, Jr. wrote: > >transfers. I never tried to ftp to /dev/null. > Don't bother: Command: syst >>> SYST 215 MVS is the operating system of this server. FTP Server is running on z/OS. Command: get 'SYS1.maclib(splevel)' /dev/null Get fails: /dev/null is a character special file. Command: Most FTP servers and clients will deal only with regular files (OS X seems to be an exception). For the server, this may be due caution; for the client it's a foolish and needless limitation. Further: Command: get 'NULLFILE' foo.bar >>> PORT 127,0,0,1,4,203 200 Port request OK. >>> RETR 'NULLFILE' 550 Data set NULLFILE not found But: Command: put 'sys1.maclib(splevel)' 'NULLFILE' >>> SITE FIXrecfm 80 LRECL=80 RECFM=FB BLKSIZE=27920 200 SITE command was accepted >>> PORT 127,0,0,1,4,204 200 Port request OK. >>> STOR 'NULLFILE' 125 Storing data set NULLFILE 250 Transfer completed successfully. 30176 bytes transferred in 0.005 seconds. Transfer rate 6035.20 Kbytes/sec. ... I wonder where it went? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
Mark, Never thought about just doing a copy to see what we would get. When doing the ftp's invloving z/OS the CPU utlization was under 40% busy, using 1/2 track blocking, and binary transfers (no EBCDIC to ASCII overhead). Doing the transfers between Linux images the only thing running was ftp transfers. I never tried to ftp to /dev/null. I was using a 700MB file. -- John Giltner [EMAIL PROTECTED] wrote: John, What sort of data rate do you see just copying this file to another using TSO COPY or IEBGENER, for example? That would give you an idea of what your disk subsystem was capable of. Considering the TCPIP and FTP protocol overhead, 40 MB/sec doesn't sound too bad. I have also had customers come to me with issues about slow FTP performance which, on inspection, was caused by use of inappropriate blocksizes on the z/OS output file. Something they wouldn't normally have a problem with if specifying DCB parms in a JCL deck, but don't think about when they are FTP'ing. Also note that hipersocket performance is affected by CPU utilization utilization. I don't know what the exact relationship is, but I have measured that is does occur. Finally, I should explain the 200 MB/sec results I mentioned in my previous post. They were produced during testing to see what sort of throughput hipersockets could actually deliver using FTP (in order to correct misinformation floating around the shop that "hipersockets is slower than the regular network"). I was FTPing between two virtual Linux servers running on the same single-IFL z9-109. CPU utilization was <10% at the time. In order to remove DASD performance as a variable, LINUXA had a 256MB file, in cache. LINUXB did an FTP "get" from LINUXA, directing the output into /dev/null. Elapsed time was on the order of 1.2 seconds. SCP of the same file, on the other hand, only ran at about 8 MB/sec. Investigation showed that each Linux virtual machine was running at >45% CPU - encrypting the file on one end and decrypting it on the other (in software, since we don't have a hardware crypto facility). Dunno why one would need to encrypt data over a hipersocket link, but someone is bound to do so. So heads up, y'all, if they come to complain... Mark Wheeler, 3M Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
John, What sort of data rate do you see just copying this file to another using TSO COPY or IEBGENER, for example? That would give you an idea of what your disk subsystem was capable of. Considering the TCPIP and FTP protocol overhead, 40 MB/sec doesn't sound too bad. I have also had customers come to me with issues about slow FTP performance which, on inspection, was caused by use of inappropriate blocksizes on the z/OS output file. Something they wouldn't normally have a problem with if specifying DCB parms in a JCL deck, but don't think about when they are FTP'ing. Also note that hipersocket performance is affected by CPU utilization utilization. I don't know what the exact relationship is, but I have measured that is does occur. Finally, I should explain the 200 MB/sec results I mentioned in my previous post. They were produced during testing to see what sort of throughput hipersockets could actually deliver using FTP (in order to correct misinformation floating around the shop that "hipersockets is slower than the regular network"). I was FTPing between two virtual Linux servers running on the same single-IFL z9-109. CPU utilization was <10% at the time. In order to remove DASD performance as a variable, LINUXA had a 256MB file, in cache. LINUXB did an FTP "get" from LINUXA, directing the output into /dev/null. Elapsed time was on the order of 1.2 seconds. SCP of the same file, on the other hand, only ran at about 8 MB/sec. Investigation showed that each Linux virtual machine was running at >45% CPU - encrypting the file on one end and decrypting it on the other (in software, since we don't have a hardware crypto facility). Dunno why one would need to encrypt data over a hipersocket link, but someone is bound to do so. So heads up, y'all, if they come to complain... Mark Wheeler, 3M Company "John S. Giltner, Jr." <[EMAIL PROTECTED] To .NET> IBM-MAIN@BAMA.UA.EDU Sent by: IBM cc Mainframe Discussion List Subject <[EMAIL PROTECTED] Re: Hipersockets performance .EDU> 10/05/2007 06:56 PM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> On a z990-303 with a single IFL and 3 CP's using 56K MTU's. No matter what I did I could only get 40MB ps using FTP. However, I could get somewhere between 3-5 FTP streams running concurrently with 40MB ps each, total of 120-200 MB ps -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
George Soley wrote: We've been testing a hipersockets connection between z/OS V1R7 and linux partitions. After following the setup steps in the Hipersockets Red Book transmit speeds using ftp or scp have been disappointing. Either our testing process is incorrect or the configuration is wrong. Does anyone have experience with this environment? On a z990-303 with a single IFL and 3 CP's using 56K MTU's. No matter what I did I could only get 40MB ps using FTP. However, I could get somewhere between 3-5 FTP streams running concurrently with 40MB ps each, total of 120-200 MB ps The IFL was running z/VM (V4 something) with 2GB central and 1GB expanded. We had two Linux images up and running and each configured with 2GB of "RAM". We had 2 z/OS images, one with 2GB central (system programmer sand box) and one with 8GB central. All systems were sharing 6 FICON connections to a single DS8100. I have no clue how the DS8100 was configure or how the DASD was split up. For all I know I could have been ftp'ing files to/from the same array. It did not matter what I did: z/OS to z/OS Linux to Linux z/OS client to Linux server Linux client to z/OS server We did no tuning either on the z/OS IP stack or the Linux stack. We were going to go back and look at how the DASD was setup and do some tuning on z/OS and Linux stacks, but never got to it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
What is the MTU size set to on your system(s)? With HiperSockets you can go to large MTU and not be stuck with the old size of 1492. I believe 64K is not too unreasonable. >We've been testing a hipersockets connection between z/OS V1R7 and linux >partitions. After following the setup steps in the Hipersockets Red Book >transmit speeds using ftp or scp have been disappointing. Either our >testing process is incorrect or the configuration is wrong. Does anyone >have experience with this environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hipersockets performance
George, FTP is going to be limitted by the speed of your disk. SCP, unless you have crypto hardware, is likely going to be limitted by CPU. I've FTP'd between Linux virtual machines over a real hipersocket on single-IFL z9-109 at over 200 megabytes per second. Just a note that FTP get is MUCH faster then FTP put. Best regards, Mark Wheeler, 3M Company George Soley <[EMAIL PROTECTED] V> To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List <[EMAIL PROTECTED] Subject .EDU> Hipersockets performance 10/05/2007 08:06 AM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> We've been testing a hipersockets connection between z/OS V1R7 and linux partitions. After following the setup steps in the Hipersockets Red Book transmit speeds using ftp or scp have been disappointing. Either our testing process is incorrect or the configuration is wrong. Does anyone have experience with this environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
