TPF is in its own LPARs supporting its own IP stacks. The 24 CMS users are using the VSWITCH. That said, the bulk of our testing has TPF virtual machines connected via VSWITCH; however, TPF is VSWITCH unaware, so far as it knows, it has an OSA.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Quay, Jonathan (IHG) > Sent: Friday, August 08, 2008 10:44 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: DTCVSWn Storage > > When did TPF start supporting VSWITCH attachment? I must > have missed that because the first thing I thought about when > vswitch came out was using vswitch to do comms unit test, as > the apps boys were moving a lot of things from lu 6.2 to > sockets. Apparently what VM emulated and what TPF expected > were two different things and it never got off the ground. > > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard > Sent: Friday, August 08, 2008 1:35 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: DTCVSWn Storage > > Inactivity is not a likely problem - we are driving well over > 10K messages per second through the VSWITCH when the problem > occurs. The symptom we see is that TPF is dropping sockets > due to "excessive retransmits". My first thought was that the > DTCVSW machines might be a choke-point. I have, I think, > found the answer to the question about virtual storage. I > doubled the size of the machines to no avail - exactly same > symptom at the same message rate. Following the test runs, Q > VSWITCH ALL DETAILS shows no discarded packets and no errors > for any of the IP stack machines. > > As for the monitor, don't ask. Apparently the person who > created the VM system had a problem with getting it to > function. Unfortunately, the running of the benchmark > conflicted with a hospital visit for the other person; the > hospital trumped work. I did not know about the monitor > problem until after I was called. I do not have any good > monitor data to show. Another problem is that the benchmark > is located 3000 miles from where I am and 1500 from the > datacenter where the systems, both TPF and VM were built. The > timing and logistics make reinstalling the monitor s/w > somewhat problematic, especially since this is the last day > of the tests. > > > Regards, > Richard Schuh > > > > > -----Original Message----- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > > Sent: Thursday, August 07, 2008 7:09 PM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: DTCVSWn Storage > > > > On Thursday, 08/07/2008 at 03:47 EDT, "Schuh, Richard" > > <[EMAIL PROTECTED]> > > wrote: > > > Is there a way to tell, in real-time, whether the DTCVSW > > machines are > > storage > > > constrained? > > > > I would suppose your performance monitor will tell you if CP is > > storage constrained and guests are awaiting page frames. > > DTCVSWx just sits there sleeping, waiting for a Sign. If the OSA > > hiccups, DTCVSWx will awaken, trigger error recovery, then > turn over > > and go back to sleep. > > > > Is DTCVSWx showing signs of sluggishness that makes you > suspect memory > > contention? (He will probably be paged out due to inactivity.) > > > > Alan Altmark > > z/VM Development > > IBM Endicott > > >
