Conference azur::mcc

Your FCL getevent test is slightly flawed:  you want to
specify a FOR DURATION instead of an AT EVERY.

GETEVENT NODE4 node
     REMOTE node COUNTERS ZEROED, for duration 24:00:00

Try that and see what happens.

Also, try running the same notification requests 
(not getevents) from the same number of FCL processes 
and direct the output to the null device.

notify domain blah blah blah , to file nl:

This will take the notif PM out of the loop but still 
test the FM.

Another thing to try is to close (File->Close Window not
just iconify) the Notif PM window(s) and just let the 
notifications arrive at the map (and beep).

A question: in your test of running 5 IMPMs, how many 
of your IMPMs are pumping their displays to other
workstations?  If all 5 IMPM sessions are running
with their displays on that single workstation, try
sending the displays elsewhere.

Would it also help to increase the size of the Event Manager pool ?

Is it possible on VMS (i.e. Does the MCC_EVENT_POOL_SIZE has an effect ? ) ?

My 2 �.

Pierre.

Re .1

>>> Your FCL getevent test is slightly flawed:  you want to
>>> specify a FOR DURATION instead of an AT EVERY.
>>>
>>>   GETEVENT NODE4 node
>>>     REMOTE node COUNTERS ZEROED, for duration 24:00:00
>>>
>>> Try that and see what happens.

I guess that this wouldn't affect the performance.

Does NOTIF-FM do a 'GETEVENT xxx, FOR DURATION yyy' when you 
issue a notification request or does it issue the GETEVENT 
without any scheduling after processing a received event?
I thought it was the latter, so I specified AT EVERY to try to
do as NOTIF-FM.

>>> Also, try running the same notification requests 
>>> (not getevents) from the same number of FCL processes 
>>>> and direct the output to the null device.
>>>
>>> notify domain blah blah blah , to file nl:
>>>
>>> This will take the notif PM out of the loop but still 
>>> test the FM.

I'll do it.


>>> Another thing to try is to close (File->Close Window not
>>> just iconify) the Notif PM window(s) and just let the 
>>> notifications arrive at the map (and beep).

guess that this is like the above test:
    'notify domain blah blah blah , to file nl:'

>>> A question: in your test of running 5 IMPMs, how many 
>>> of your IMPMs are pumping their displays to other
>>> workstations?  If all 5 IMPM sessions are running
>>> with their displays on that single workstation, try
>>> sending the displays elsewhere.

We're not displayin on the workstation itself.  They have 5 
VXT2000 with 14 Mb of memory each on which we're displaying 
the IMPM:s.

We've tried everything from 5 IMPM:s on 5 VXT:s to 5 IMPM:s on 
1 VXT and we get hangings in every case.  

Memory on the VXT:s are not a bottleneck, there's 2-3 Mb of 
free memory when we have __lots__ of windows on the screen.

       /Nils

>I guess that this wouldn't affect the performance.

It may not.

>Does NOTIF-FM do a 'GETEVENT xxx, FOR DURATION yyy' when you 
>issue a notification request or does it issue the GETEVENT 
>without any scheduling after processing a received event?
>I thought it was the latter, so I specified AT EVERY to try to
>do as NOTIF-FM.

It's the former.  The scope of interest (FOR) gets passed
through by the AM to the event manager (via a parameter to 
mcc_event_get), which forces it to hang onto events that arrive 
between calls.  The scheduling time (AT) only effects the scheduling 
of the mcc_call to the AM.  It's possible (though I'm not sure how 
likely) that using AT would allow the event manager to drop events 
that would otherwise get stuck in the pool.

>>>> Another thing to try is to close (File->Close Window not
>>>> just iconify) the Notif PM window(s) and just let the 
>>>> notifications arrive at the map (and beep).
>
>guess that this is like the above test:
>    'notify domain blah blah blah , to file nl:'

Kinda, but not quite.  There's still a fair amount of processing that
the IMPM does with each notification... just far less X calls.

>We're not displayin on the workstation itself.  They have 5 

Hmmmm....  Same behavior if all 5 IMPMs pump their displays to 
the workstation?  (not that this is a scenario that a customer
would use...)

I do remember, in one test scenario, we saw a kind of "reverse traffic 
jam" behavior where the IMPM/Notif PM kind of slowed way down and then, 
by starting another PM, things sped back up again.  During that
testing, we found a major memory leak.  When we fixed the 
memory leak, the weird "traffic jam" behavior went away.  I never 
really understood what could have caused performance to improve when
two processes were running as opposed to one, but I had this vague
feeling that the code being executed was more likely to be in physical 
memory when two processes were using it than when one was.  That coupled
with the fact that the virtual address usage of the processes were
growing rapidly, I guess.  Or, it could be that the event manager was
unable to handle the throughput when the consumers were "slow".

>     The test-setup is as follows:
>     
>     1.  A process blocking 32 MB ( SYS$LCKPAG(32Mb) and
>     SYS$HIBER ).  Working-set set up to hold it without paging.

I'm not sure I understand the point of this.  Is it effectively taking
32Mb of physical (and virtual) memory away from the rest of the system?

re .4

>>> I'm not sure I understand the point of this.  Is it effectively taking
>>> 32Mb of physical (and virtual) memory away from the rest of the system?

The blocking of 32 Mb is just to prove that 128 Mb is enough, and that they 
have some room for expansion regarding memory usage.

It is taking 32 Mb out of memory.  The System Services manual says:

 "The Lock Pages in Memory service locks a page or range
  of pages in memory. The specified virtual pages are forced
  into the working set and then locked in memory. A locked
  page is not swapped out of memory if the working set of the
  process is swapped out. These pages are not candidates for
  page replacement and in this sense are locked in the working
  set as well."

We tried FCL with 'NOTIFY ..., TO FILE NL:' and it did hang for 30-60 seconds.
The first time I tested, it worked ok with 400+ events, but the second time it 
failed...

We also tried IMPM with the notification window closed with no success.

I guess that this takes X-traffic overhead as the problem away.


Anyone tried to reproduce the problem?   We get the hangings every time
running 1 event/sec for more than 2 minutes and 4 or more operators. 
We even had hangings with two operators, but that is not reproducable.


      /Nils

Are the LOG-logicals (MCC_EVENT_LOG and MCC_EVENT_TRACE) still supported?
If yes, what are the proper values to set?  Is it still 1 and 180 respectively?

Is the logical MCC_NOTIFICATION_FM_LOG the right name for NOTIFICATION-FM and
what values should be used?

Does it make any sence to use them to figure out when and where it is 
hanging, and what's going on?

Any other hints on what to do to figure out what's going on (or rather what is
*NOT* going on...)

   
    /Nils

    The event logicals MCC_EVENT_LOG and MCC_EVENT_TRACE are still usable,
    values 1 and 180 (hex) respectively.  These will cause the dumping of
    event puts and gets.  This may be a LARGE amount of output.  Make sure
    that all processes using the event pool use these logicals to get the
    whole picture.
    
    The event logical MCC_EVENT_POOL_SIZE can be used to set the size of
    the event pool in bytes (evenly divisible by 1024).  Minimum is 262144,
    default is 524288, max is 8192000.
    
    Ted

    A member of our test team is noticing that an operator's notification
    window can start to miss events if it has been up for a long time.
    Is this a normal occurrence? Should the notifications window not be
    left up for long periods?
    			Thanks,
    				Jim B.
    
    Tester's message follows:
    
    > When MCC has been up for hours on end, the notification window can slow
    > down.  This is indicated when there are gaps between the alarm ids
    > shown in the notification window.
    >
    > (Note: all alarms are logged to the mcc_notification.log file.)
    >
    > To fix the problem,
    > you can clear out all of the alarms in the notification window
    > periodically, or restart MCC.

    > Note 5117.9 by NEWVAX::BUCHMAN "UNIX refugee in a VMS world" >>>
    >               -< Notification window missing events >-
    
    Can anyone give us an opinion here? We have increased the pool size,
    and that helps a bit; but can we do anything else? BTW, all of our
    events come in via SNMP traps.
    				Thanks,
    					Jim B.