Re: *SIGNAL Service Experience
In experiments conducted some years ago, I determined that the most efficient way to signal between two guests was to use alternating IUCV QUIESCE and RESUME signals. These signals cause the target to receive an IUCV external interruption, which is sufficient to let it know that something has changed. I can't say that this is still the case, but it se ems likely that avoiding the data transfer associated with SEND would make th is approach slightly more efficient. Romney White
Re: *SIGNAL Service Experience
On 4/22/09 10:38 AM, "Gary M. Dennis" wrote: > Only A to B as we have no broadcast requirement. You will. Efficient implementation of multicast will need a similar transport capability.
Re: *SIGNAL Service Experience
Only A to B as we have no broadcast requirement. --. .- .-. -.-- Gary Dennis Mantissa Corporation On 4/21/09 4:08 PM, "Alan Altmark" wrote: > On Tuesday, 04/21/2009 at 01:55 EDT, "Gary M. Dennis" > wrote: > >> > The IUCV tests seemed insensitive to transmission size. Whether we sent > 8 >> > bytes or 32,000, the 5 to 7 second window held. > > The savings of *SIGNAL would be the use of the broadcast function. Instead > of UserA sending to UserB, then UserC, then UserD, and so on, userA just > broadcasts the IUCV data, saving an IUCV SEND operation as well as the > logic to keep track of B, C, and D (which *SIGNAL can help with, too). For > two guests, the savings would be zero. > > What scenario did you compare? > > Alan Altmark > z/VM Development > IBM Endicott >
Re: *SIGNAL Service Experience
On Tuesday, 04/21/2009 at 01:55 EDT, "Gary M. Dennis" wrote: > The IUCV tests seemed insensitive to transmission size. Whether we sent 8 > bytes or 32,000, the 5 to 7 second window held. The savings of *SIGNAL would be the use of the broadcast function. Instead of UserA sending to UserB, then UserC, then UserD, and so on, userA just broadcasts the IUCV data, saving an IUCV SEND operation as well as the logic to keep track of B, C, and D (which *SIGNAL can help with, too). For two guests, the savings would be zero. What scenario did you compare? Alan Altmark z/VM Development IBM Endicott
Re: *SIGNAL Service Experience
Thanks. The following is from some tests we conducted to compare *SIGNAL to straight IUCV. 2097 Dallas Development, second level VM, under CMS. 100,000 signal / acknowledgement transmissions. The straight IUCV test sent only 8 bytes to try and put it on equal footing with *SIGNAL. 4 *SIGNAL tests - ran 5 seconds each over a 2 minute period. 4 IUCV tests - ran 5, 7, 7, 6, 7 seconds over a 2 minute period. The IUCV tests seemed insensitive to transmission size. Whether we sent 8 bytes or 32,000, the 5 to 7 second window held. --. .- .-. -.-- Gary Dennis Mantissa Corporation On 4/20/09 12:53 AM, "Alan Altmark" wrote: > On Friday, 04/17/2009 at 12:16 EDT, "Gary M. Dennis" > wrote: >> IF >> you have experience using *SIGNAL service for high volumes > > To my knowledge, the only exploiter of *SIGNAL is GCS, which has been used > since around 1986 to run VTAM, NetView, RSCS, AVS, PSF and VSCS > applications. The signalling GCS performs is primarily used to > - Signal the presence of data in shared memory (usually so that the target > of the signal can send it.) > - Run a named entry point in another group member (usually so target of > the signal can receive data placed in shared memory) > - Dump shared memory if a member of the group dies > - Join or remove a member of the group > > GCS has handled large workloads for decades without incident. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: *SIGNAL Service Experience
On Friday, 04/17/2009 at 12:16 EDT, "Gary M. Dennis" wrote: > IF > you have experience using *SIGNAL service for high volumes To my knowledge, the only exploiter of *SIGNAL is GCS, which has been used since around 1986 to run VTAM, NetView, RSCS, AVS, PSF and VSCS applications. The signalling GCS performs is primarily used to - Signal the presence of data in shared memory (usually so that the target of the signal can send it.) - Run a named entry point in another group member (usually so target of the signal can receive data placed in shared memory) - Dump shared memory if a member of the group dies - Join or remove a member of the group GCS has handled large workloads for decades without incident. Alan Altmark z/VM Development IBM Endicott
*SIGNAL Service Experience
IF you have experience using *SIGNAL service for high volumes THEN Could you provide information (or simply observation) relating to overhead, latency? ELSEIF You know compelling reasons this service should not be considered for very high signal volumes THEN This is an excellent opportunity to keep fellow primates out of harms way. ENDIF Thanks --. .- .-. -.-- Gary Dennis Mantissa 0 ... living between the zeroes... 0
