Conference azur::mcc

	Hi Livia.  I work in the group (NSTG) which did the performance
	testing and developed the sizing tool for DECmcc V1.2, so I guess I'm
	best qualified to answer your questions.  Sorry I missed your
	note in the MCC-TOOLS conference, but I only monitor it occasionally.

	The tool, as I see it, is only a first cut of what can be done.  I'll
	agree that not all areas are covered, but the hopes were that if 
	the tool proved to be useful, further work would be done to improve
	the tool for future DECmcc releases.  Now to answer your questions.

>        Some questions/notes about MCC System planner tool:
>    
>            1) Iconic map section: I've understood that I have
>               to multiply the results for the number of DECmcc station using
>               the iconic map (of course, if you have more than one mcc users
>               working at the same time). Is my assumption right ?

	Yes.
    
>            2) I've not found any disk usage for the event logging file.

	You're right, it's not in there.  In general, I look at log files
	as requiring temporary storage only.  These type files require
	maintenance by the user.  If log files are not maintained, they
	will fill up any size disk.

>            3) Iconic map section: I've not understood the note about
>               "0.11 Meg of memory will be required per hour ...". Which means
>               per hour ? Is the time function of the notification activity
>               increment ?

	Yes, it is directly related to the rate of notifications handled by
	Iconic Map.  Performance testing showed that additional memory is
	required to support the notification process.

>            4) Historian section: "Each addition background process will
>               require another 1.15 Meg of memory". Is it still true if a
>               domain contains just very few entities (two or three).

	Yes, it is true.  This number simply reflects the overhead of the
	background process itself.
    
	Regards,
	Joe G.    
    

    Hi Joe, thanks for your answer.
    
    The System Sizer Tool is very useful, making it was a great job.
    I think network management specialist really need it.
    
    In these days I've to tell to the customer which VAX configuration he
    needs to manage his network using MCC, and I'm using your tool.
    
    >      3) Iconic map section: I've not understood the note about
    >         "0.11 Meg of memory will be required per hour ...". Which means
    >         per hour ? Is the time function of the notification activity
    >         increment ?
    >
    >     Yes, it is directly related to the rate of notifications
    >     handled by Iconic Map ...
    
    	At the customer site we thought to leave the Iconic map receiving
        notification all time running (24 hours). Considering what you say
        it seems that solution is not so good, very memory expensive. It seems
    	to me we have to avoid to keep the Iconic map opened for so much
        time. Have I understood right what you said ?
    
    >     4) Historian section: "Each addition background process will
    >        require another 1.1memory". Is it still true if a
    >        domain contains just very few entities (two or three).
    >
    >     Yes, it is true.  This number simply reflects the overhead of the
    >     background process itself.
    
       It's not so good answer ... I really didn't know that domains was
       so memory expensive. It seems to me that this thing is not reported
       on release notes, if that's true I think it would be.
       Anyway, do you know if we can expect less memory consuming for
       historian background processes in next releases ?
    
    Ciao,
    Livia (from another VMS account)

    >         "0.11 Meg of memory will be required per hour ...". Which means

Joe-

  Is this virtual or physical memory?  That is, does it require more
swap space?

    
    re: .2 & .3
    
    In regards to the additional memory overhead of processing
    notifications by the Iconic Map interface, test results and
    specifically on the Ultrix platform, indicate an increase in
    the data portion of the IMPM process.  An estimate of usage
    due to the notification process was intentionally included in
    the tool since notifications appears to be one of the main
    areas of functionality that a customer will utilize.  Periods
    of only 24 hours don't appear to me to be of a great concern.
    
    To answer Erik's question, I guess bottom line, we're really talking
    required additional swap space to accomodate this situation.  Let
    me also add here that similar problems exist with use of the PA FM and
    DNA5 AM.  Since the incremental memory usage of these modules was
    not quantified during our testing, no data was included in the tool.
    
    Regarding historical data recording and exporting for that matter,
    I don't see the domains in themselves a problem.  I believe there
    has probably been discussions around this in this conference with
    suggestions like specifically creating a domain populated with the
    desired network entities for the sole purpose of recording historical
    data.  Performing recordings per domain or exporting to separate
    databases costs you additional memory requirements per required
    background process, as well as, some increase in CPU utilization.
    
    Joe

It turns out that the memory increase in the iconic map over time 
is due to some leaks in the underlying X routines (not under the
control of the DECmcc developers).  The rate of memory loss will
be somewhat related to the number of windows brought up and down
durint the period of activity measured.

This is indeed a virtual memory requirement (that is, more swap space
helps (to a point).  No need for more physical memory).