Conference azur::mcc

3628.0. "Sizing - the high side" by SKIBUM::GASSMAN () Wed Aug 26 1992 07:28

    This note from Chris Bond in the UK (forwarded by Carlos Baradello) 
    gives a good picture of the 'high end' of mcc, showing it can be 
    used by multiple operators using multiple maps.
    
From:	TOOK::BARADELLO "25-Aug-1992 1007" 25-AUG-1992 10:15:54.90
Subj:	BT happy. Performing and quick turn aroun....Well done team!

From:	NAME: Chris Bond                    
	FUNC: SWAS                            
	TEL: 7845 2233                        
        
        Thankyou for your assurances that engineering are available to 
        support us with the DECmcc project in British Telecom.
        
        Our benchmark testing last week was reasonably successful with 
        the patched iconic map.
        
        On a DECsystem 5000/240 with 288MB memory, we successfully 
        started up 25 map windows with notification enabled before the 
        system started to page, but we got 32 in ok.  With the windows 
        quiescent, the background cpu being used was 30%.
        
        We then used the data collector to fire events at the system 1 
        every 6 seconds with each map and notifications window receiving 
        the event.  This used about 90% of the cpu.  We then used 2 
        operator positions, moving around the maps with the event load.  
        It wasn't over responsive but it was acceptable.  It gave 
        confidence that under high event load, the system does cope.
        
        We have advised the customer to begin his live operations using 
        up to 10 active operator positions.  Then as we find how the 
        system performs in a normal environment (events arriving at an 
        average of 1 every few minutes) but with more active users, we 
        can then advise him to increase operators if the system can 
        handle it.  Our feeling at this stage is that we will not manage 
        32 positions (the customer's goal) from the DECsystem 5000/240.  
        Our guess is 15 or 20.   It is also likely that we will use the 
        Alarm Handling FM of TeMIP so that operators can decide who will 
        handle a given problem.  This will also add to the demands on the 
        cpu.
        
        The above reasons are why we are anxious to receive some early 
        indication of the availability of DECmcc on Alpha (either VMS or 
        OSF).
        
        Thanks for your speedy resolution to the 'iconic map eats cpu 
        problem' - it has certainly rescued DECmcc from the MIRe at BT.
        
        chris