Re: ancient history - MP3000 CTC network on SLES9
On Aug 17, 2020, at 8:33 PM, r.stricklin wrote: > Ugh, I solved it. The IOCP and devices were all fine. I was trying to start > the link, rather than the device, in my PROFILE TCPIP. But now I'm having a new problem. ssh into the install system is hanging on key exchange (it worked fine when I was using LCS so I'm confident it's not something wrong with ssh itself). On closer investigation it seems possibly MTU related? I can ping from the FTP server (which it is successfully downloading the initial installer components from) into the LPAR with ICMP packets >1400 bytes, but if I use telnet to get a shell on the installer system, I can't ping the other direction with ICMP packets >548 bytes. Why should it be so asymmetric? The CPU is not being chewed up by the LCS, though, and that does seem to have been the issue with bringing dasd online, as that works fine now. Once I cranked the MTU down to the lowest allowable (576 bytes) everything is working. But... gross. Several arbitrary intermediate steps between 1500 and 576 solved nothing; why so low? Once the install completes I shall have to see about experimentally finding the actual limit. ok bear. -- until further notice -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: IUCV 2WAY missing from AF_IUCV in zLinux?
All IUCV socket functions in VM TCP/IP are 2WAY (SEND with REPLY). Regards, Alan Altmark IBM > On Aug 17, 2020, at 10:06 PM, Neale Ferguson wrote: > > What type of service are you calling? > > Neale Ferguson > > On 8/18/20, 02:57, "Linux on 390 Port on behalf of Christian Svensson" wrote: > >[+linux-390 mailing list] > >>On Mon, Aug 17, 2020 at 6:55 PM Christian Svensson wrote: >> >> Hi, >> >> I am trying to call TCPIP service using IUCV. >> I found AF_IUCV which seemed to do what I want, but reading >> more into it it looks like AF_IUCV only ever implemented one-way >> SEND operations. > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: vmrelocate and quiescence time
On Mon, Aug 17, 2020 at 12:26 PM Bill Bitner wrote: > I take a few days off and a fun topic comes up that I mostly miss. :-) > > We did a Live Virtual Class on this back when SSI first came out. A few > things have changed, but you may find value in it: > http://www.vm.ibm.com/education/lvc/zvmlvc.html > The charts for the presentation are > http://www.vm.ibm.com/education/lvc/LVC0227.pdf > > This is great! Thank you. Although this brings a few more questions, it was definitely very helpful. - chart on page 24 idle case (0GB change) had a quiesce time 8s - I wonder why. That VM in this test was probably >100GB so more or less close to my case. But I thought that if there are close to 0 changes, then the last pass should be just a "formality"? I was relocating my VM with DB2 being stopped! There were just few idle processes left and yet it took 20-30s of freeze time. Of course I am doing sync and not immediate. Seems like I should be below <10s even with just 2CTCs (although I am hoping to get 2 more) by looking at these charts. - document says that I/O device count matters as well. We have 4 FCP channels with quite a big number of luns (>20), would that make a big difference? I will look into anything related in perfsvm thanks again. Gregory -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: ancient history - MP3000 CTC network on SLES9
On Aug 17, 2020, at 5:43 AM, Alan Altmark wrote: > My long-suffering draft work on CTCs can be found at > http://www.vm.ibm.com/devpages/altmarka/ctc.html. Maybe it can help you. > The UAs must match. By default the UAs match the last two digits of the > device number. Your device numbering convention may require you to change > it. Ugh, I solved it. The IOCP and devices were all fine. I was trying to start the link, rather than the device, in my PROFILE TCPIP. ok bear. -- until further notice -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: IUCV 2WAY missing from AF_IUCV in zLinux?
What type of service are you calling? Neale Ferguson On 8/18/20, 02:57, "Linux on 390 Port on behalf of Christian Svensson" wrote: [+linux-390 mailing list] On Mon, Aug 17, 2020 at 6:55 PM Christian Svensson wrote: > > Hi, > > I am trying to call TCPIP service using IUCV. > I found AF_IUCV which seemed to do what I want, but reading > more into it it looks like AF_IUCV only ever implemented one-way > SEND operations. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: IUCV 2WAY missing from AF_IUCV in zLinux?
[+linux-390 mailing list] On Mon, Aug 17, 2020 at 6:55 PM Christian Svensson wrote: > > Hi, > > I am trying to call TCPIP service using IUCV. > I found AF_IUCV which seemed to do what I want, but reading > more into it it looks like AF_IUCV only ever implemented one-way > SEND operations. > > Is that correct? > > There appears to exist a message_send and a message_send2way in > the Linux IUCV interface, however only message_send appears to be used > by AF_IUCV. > > If my reading is correct, is there any way I can work around this > without writing a kernel module? > > Thanks -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: vmrelocate and quiescence time
I take a few days off and a fun topic comes up that I mostly miss. :-) We did a Live Virtual Class on this back when SSI first came out. A few things have changed, but you may find value in it: http://www.vm.ibm.com/education/lvc/zvmlvc.html The charts for the presentation are http://www.vm.ibm.com/education/lvc/LVC0227.pdf It goes through the various factors that influence overall relocation time and quiesce time. What we find with databases is often they are large virtual machines in terms of memory. This can can have a non-trivial effect on quiesce time as the process involves traversing the DAT structures to validate changed pages. This traversal is done twice for various reasons. So chart 23 of the presentation deck illustrates that effect. This has to be done regardless of whether pages change or there is activity because this is the mechanism used to determine that. Since that LVC there were updates to Performance Toolkit that can show some of the statistics on LGR (or in other z/VM Performance products). ___ Bill Bitner - z/VM Client Focus and Care - 607-429-3286 bitn...@us.ibm.com "Making systems practical and profitable for customers through virtualization and its exploitation." - z/VM -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: vmrelocate and quiescence time
On Mon, Aug 17, 2020 at 8:52 AM Alan Altmark wrote: > > You are equating things that should not be equated. If you have set up 4 > CTCs between each pair of members as recommended in the books, you have > done all you can to make it go faster, given the CPUs that you have. (I > would probably look at the diagnostics on the HMC and see if you're > getting any frame errors on the CTCs.) > Ok, this might be it. We have only 2 CTC per each! I've reached out to our hardware team to see if we can increase the number of CTC. We might "steal" some from the non prod. Somehow I thought that these are just defined in the iodf nowadays and don't use real adapters and cables if we are not leaving the box. In the meantime I am trying to do some simple math and approximation ..more like guessing for fun. I wonder how much data is there to push during the last pass in the LGR process on average. 10% of total VM's memory at most? So if one CTC has 10Gbps (I have no clue but that number seems reasonable) then 10% of 128GB should take just ~10 seconds using just one CTC. I am sure I am off but trying to find a simple explanation of my 20-30s. I even tested it with DB2 completely stopped. No noticeable improvement. I wonder if that has something to do with the fact that 90% of my linux memory is used by file cache at the moment (of course this will change when it goes to prod) But as I mentioned, the database was stopped so even file cache should be pretty much "stable", unless there is something special about memory used by cache and vmrelocate always moves it in the last pass? I will try to drop cache the next time I try this. Thank you very much for your help! Gregory -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: vmrelocate and quiescence time
On Sunday, 08/16/2020 at 09:45 GMT, Grzegorz Powiedziuk wrote: > What is a very large guest nowadays? Is 128G considered to be very large? > Would 30s quiesce time be expected for a 128G VM or rather for a 512G > guest. You are equating things that should not be equated. If you have set up 4 CTCs between each pair of members as recommended in the books, you have done all you can to make it go faster, given the CPUs that you have. (I would probably look at the diagnostics on the HMC and see if you're getting any frame errors on the CTCs.) A guest is too large when it's memory alteration behavior is such that errors start occurring because the quiesce time is too long. A very large guest with very few changes to memory will relocate without a problem. It might take several minutes to for VMRELOCATE to complete, but the quiesce time will be very short. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: ancient history - MP3000 CTC network on SLES9
On Sunday, 08/16/2020 at 09:58 GMT, "r.stricklin" wrote: > I believe (this is the part of the EMIF CTC section in the IOCP User's Guide I > think I understand pretty clearly) the CUADD and third digit of the real device > number (23x0) indicates the LPAR number of the other end. My (less clear) > understanding is that IOCP generates pseudo control units based on this, which > perform the role of the 'CP COUPLE' command. I have assumed, but am not yet > confident, that the last digits are what tie both ends together. e.g. in LPAR > 3, 2310 would connect to 2330 in LPAR 1, and 2320 to 2330 in LPAR 2. -- "A > corresponding pair of CTC devices can have different device numbers, but they > must use the same unit address." My long-suffering draft work on CTCs can be found at http://www.vm.ibm.com/devpages/altmarka/ctc.html. Maybe it can help you. The UAs must match. By default the UAs match the last two digits of the device number. Your device numbering convention may require you to change it. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
