Conference azur::mcc

756.0. "Wildcard and table data display problems" by LEVERS::LEVENSON () Wed Feb 27 1991 13:22

Hi, 
    	We, at TAY2, are integrating into MCC the management of FDDI LAN 
        products, using the current Bridge AM as a base.
    
    	While working with the Bridge AM to expand it, we came across a few
    	PM level problems, most of them common both for IMPM and FCL. These
    	problems don't seem to be bugs, but rather 'design' problems, but
    	nevertheless they would be quite visible to LAN managers, and thus
    	need a fix before our new AMs get to the field.
    
    	I am listing the problems below.
	Most of these are associated with the display in MCC of the
	table oriented data, especially, the display of large tables, 
        which in the bridges may go and up to 64K entries.
    
        As a general comment, most of the problems stem from the fact
    	that all PM attribute display screens are auto-generated, based on
        the information given in MSL spec. for the corresponding entity. 
    	What seems to be lacking, is architectural capability for
        applications to define their own screen formats in a modular way,
        to be able to supercede the 'standard' PM formats, if necessary.
        The way it is now, applications would have to write their own PMs,
    	which would be a tremendous waste.
    	 

1. Performance problem with the wildcard display of the Forwarding
Database entries via, e.g., SHOW BRIDGE ... PHYSICAL ENTRY *.

	Although Bridge AM captures the entire database in a single invokation,
	it is obligated by the MCC architecture to return the partition 
	attributes to PM on an one-entry-per-pm_invokation basis. 

	Apparently, due to the absence of reuse of request information in PM, 
	the resulting total processing/display time for the 1700 entry long 
	database is by 3-4 orders of magnitude longer than in the existing LAN 
	management product (ELMS). 

	Redirecting the output to a file takes even longer
	(2 times), apparently, due to redundant file I/O operations in PM. 
	In both cases, the resulting total SHOW ... * times are of the order 
	of hour(s), i.e., not acceptable for LAN managers.

	Clearly, the performance must be enhanced, to make it comparable
	to the current product.

	Besides, the architecture could be enhanced, to allow an AM to return
	attributes for a RANGE of entities, for greater efficiency.

2. Header display for the wildcard SHOW. 

	For every displayed database entry, the PM displays almost the same 
	five lines of the header, a la

>BRIDGE <name> FORWARDING DATABASE PHYSICAL ENTRY <address>
><partition>
>AT 1-OCT-1990 16:12:02.11                
>	
>Examination of attributes shows:

	This is clearly redundant and very visible, if repeated for a few 
	thousand entries.

3. Attribute list display. 

	For every database entry, all attributes are displayed on a 
	line-per-attribute basis. Together with 2., this leads to a size of 
	the total display or display file exceeding by order of magnitude the 
	corresponding size in the existing LAN management product (ELMS), 
	which has a multi-column table display format (a column per 
	attribute). Data readability problem becomes, thus, 10 times worse.
	Besides, there is some unnecessary extra time being spent in X-Windows 
	display calls.

	I guess, a 'real' solution would be to have an automatic multi-column 
        display option for table (i.e., wildcard) entities and attribute
        sets, where applications can define their own table formats. Lacking 
        this, any other solution, allowing the AM to define its own screen text
        display lines, would do in a short term.


4. Display of table data, e.g., station internal connection tables, a la:
    
	------------------------------------------------------------
	Port/MAC	Connected_To		Configuration Status
	------------------------------------------------------------
	Ports:				Type	Remote	Port	Remote
						type	state	 MAC

	Port1  ->	Port3		A	B	Active	   Y
	Port2  ->	Port1		B	A	Active	   N
	Port3  ->  ....
	...
	Port10 ->	MAC1		M	Unknown	Connecting  N
	...

	This table is calculated by AM dynamically, from the response frame
        from the 'foreign' (non-DEC) station. 

	There is currently no way to display the table in MCC in the above
	format. To use an Attribute List format would be quite inconvenient
        (due to varying information context) and defeating the purpose of
        user friendly compact presentation.
    
5. Display of Hex dump for 'foreign' frames. 
	The dump is useful in detecting interoperability problems between 
	DEC and other vendor FDDI stations. Its format is a la:

	 0:	l1	l2	l3	l4	l5	l6	l7	l8
	32:	l9	l10	l11	l12	l13	l14	l15	l16

								etc.
       	where lxxx are hex longwords. 

	There does not seem to be a data type in MCC to display this 
	conveniently from AM.

6. When displaying information from 'foreign' stations, it is desirable to
    to supress the standard MCC partition name display in the menus and
    output screens - there is no way currently to keep them 'hidden'
    
    
7. Display of device configuration tables.

        This is similar to 4.
	The device configuration of a LAN 'box' is conveniently represented
	by a multi-column table:

	_____________________________________________________________________
	FRU Type	FRU State	FRU id		FRU Revision
	---------------------------------------------------------------------

	<board_name>	working/broken	Slot#		Revision#
	.....................................................................

    
  This is impossible to achieve in the current PM.
    

The first problem, I already reported in this file (somewhere).  You can see
exactly  the  same  problem  comparing  SHOW  NODE  xxx  ROUTING CIRCUIT yyy
ADJACENCY  * ALL ATTRIBUTES in MCC and NCL.  It takes *many* times longer in
MCC despite producing (almost) identical output.

The other  problems  all  seem  to boil down to you wanting some way to have
tabular  output  which  MCC  does  not  have.   It looks to me like you need
someone to write a tabular PM.

Graham

> The other  problems  all  seem  to boil down to you wanting some way to have
> tabular  output  which  MCC  does  not  have.   It looks to me like you need
> someone to write a tabular PM.

The need for a tabular output has been QARed by a couple of sources during
the early going of field test. The users perception of MCC outputs is sure
to be weak because of this still. It seems it never got on a list of things
to do with a priority. It is a shame because these are the sort of things
which are very visable to your customers.

brad...

    I'm going to stick up for the command line PM here.  This module is
    already zillions of megabytes big and slow because we've tried to
    display totally a priori unknown data in an acceptable format for every
    mcc datatype and class combination.   Having worked on datatrieve I can
    tell you that support for columnar data would probably also come out
    wrong about 50% of the time.
    
    Writing a PM is pretty easy if you know in advance what entity class
    you are going to be processing.  We should be encouraging the use of
    special-purpose PMs where the generic display is inadequate.   I agree
    we can make this easier if we provide some sort of exit capability
    from some existing user interface.
    
    

RE; the base note (RE: performance)

> 1. Performance problem with the wildcard display of the Forwarding
> Database entries via, e.g., SHOW BRIDGE ... PHYSICAL ENTRY *.>
>
>       Apparently, due to the absence of reuse of request information in PM, 
>	the resulting total processing/display time for the 1700 entry long 
>	database is by 3-4 orders of magnitude longer than in the existing LAN 
>	management product (ELMS)

 This problem has been known about for more than a year (it came up early in
 the first V1.0 EFT: MCC_INT QAR#31 dated 1/26/90). Some prototype work done
 with FCL PM code achieved something like a 3X improvement by simply caching
 dictionary information on wildcarded requests. Adding this code to the FCL PM
 was viewed as lower priority than adding required functions (i.e., performance
 improvements for the FCL PM have had a lower priority than new functionality
 and correctness - which makes sense to me).

 Not sure whether this will be addressed in DECmcc V1.2.

>       Redirecting the output to a file takes even longer
>	(2 times), apparently, due to redundant file I/O operations in PM. 
>	In both cases, the resulting total SHOW ... * times are of the order 
>	of hour(s), i.e., not acceptable for LAN managers.

 This performance problem was found late in the development cycle and was
 viewed as too high risk to address in the V1.1 kit. I have been told that
 the fix for this one is relatively simple/stratightforward and should be
 in the DECmcc V1.2.

						Chris Brienen

    RE most of the notes: as many of you stated there are a significant
    number of qars that we had to deffer until after V1.1 (40 to be
    exact) due to all the normal reasons. We are currently reviewing
    this list to determine which of them are to be completed for the
    next kit. Unluckily it is doubtful that we will be able to do all
    of them (if we did you wouldn't get any new funtions...). 
    
    If you have strong preferrences now might be a good time to drop
    me a note and I will take your input (statements of requirements
    would make it easier to justify changes) into account in prioritizing
    the list.
    
    jill
    

As for the DECnet phase iv world a couple of priorities come to mind. One
would be:   

	show node4 ....... circuit syn-* all status    

This is a very common command when troubleshooting or looking for a connection
and you're not sure of the source.

Also the AREA entity would benefit greatly from a new format because it
typically has 60-64 areas set and creates a lengthy string with todays
ouput.

	show node4 ....... area * all status

brad...