[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::decnis

Title: DEC Network Integration Server (DECNIS)
Notice:Please read note 1 to use this conference effectively
Moderator:MARVIN::WELCH
Created:Wed Sep 18 1991
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3660
Total number of notes:15082

3535.0. "How can I have a DECNIS dump analyzed?" by CANOVA::CALDONI () Fri Feb 07 1997 16:40

Hello, my customer got a problem with a DECNIS 500 HPX upgraded to MPC-III and with
4.0 running. The application does lots of X25 calls and after dealing with up to 270
active ports the DECNIS hangs and does not respond to any command (such as "SHOW NODE
decnis X25 ACCESS ALL). I produced a dump file and I would like to have it analyzed.
The customer (TELECOM ITALY) is willing to upgrade its DEMSAS' to DECNIS but at the
moment the DEMSA perform much better.

Thanks, Tano
T.RTitleUserPersonal
Name
DateLines
3535.1tell us where it isMARVIN::HIGGINSONPeter Higginson DTN 830 6293, Reading UKFri Feb 07 1997 17:5110
Tano,

Put the dump somewhere world readable and post a pointer here.

As well you should log an IPMT case (this is the official fault reporting
channel).

Peter

3535.2MARVIN::CARLINIFri Feb 07 1997 18:507
    Having been involved in some of the MPC-III X.25 perrformance
    characterisation, I for one would be very interested in seeing
    what they have done to make it perform worse than a DEMSA!
    
    And you'll definitely need an IPMT case for much to get done.
    
    Antonio
3535.3Dump locationCANOVA::CALDONIMon Feb 10 1997 08:1010
The dump file can be retrieved from:

ROMCMP::DSA7:[TEMPO]NIS_NIS02.DMP  (75000 Blocks)
or 
ROMCMP::DSA7:[TEMPO]NIS_NIS02.ZIP  (8000 blocks)

ROMCMP = 46.128

In the meanwhile i'll gather data to raise an IPMT. Thanks
Tano
3535.4MARVIN::SIMSAndrew Sims, IPEG Reading.Mon Feb 10 1997 09:3813
Can you fix the protection on the dumps.

Andrew.


$ dir ROMCMP::DSA7:[TEMPO]NIS_NIS02.*

Directory ROMCMP::DSA7:[TEMPO]

NIS_NIS02.DMP;2    insufficient privilege or object protection violation
NIS_NIS02.ZIP;1    insufficient privilege or object protection violation

Total of 2 files, 0/0 blocks.
3535.5Protections fixed!ROM01::CALDONIMon Feb 10 1997 12:541
    
3535.6MARVIN::SIMSAndrew Sims, IPEG Reading.Mon Feb 10 1997 15:035
    I have copied the dump.
    
    Can you get the NCL scripts for this DECNIS.
    
    Andrew.
3535.7More information required.MARVIN::SIMSAndrew Sims, IPEG Reading.Mon Feb 10 1997 15:516
    Can you find out if the X.25 calls are incoming or outgoing, or a
    mixture.

    Also do you know the rate the calls are being set up.

    Andrew.
3535.8More info.CANOVA::CALDONITue Feb 11 1997 06:2617
You need the ncl scripts to configure the DECNIS? OK, I'll post them
in the same place of dumps. 
The X.25 calls are both incoming and outgoing and the rate the calls
are beeing set up is about 30 per second.
The application controls some 2000 telecom devices, and it constantly polls 
their status. If the application detects something wrong with some devices, 
it sends a burst of command messages to riconfigure the net of devices, such as
bypassing a faulty device or riconfiguring paths or such. I don't know
very much how this application works, but it works with six DEMSAs. The DEMSA
receive all that burst of calls but they don't hang, they continue to work
until the have digested all the calls. 

This issue is very important because we are going to propose an upgrade or to
buy six new DECNIS with FDDI, this as part of a selling of a disaster tollerant
cluster over GIGASWITCH.

Tano 
3535.9Info updateROM01::CALDONIWed Feb 12 1997 15:0816
I placed the NCL script under ROMCMP::DSA7:[TEMPO]NIS_NIS02.NCL. I also put
PSI$CONFIGURE.NCL and PSI$ENABLE_DECNET_CLIENTS.NCL of the host running the appl
ication.

The decnis is just in the middle of the communication path between the VAX and
the TELECOM devices (FMUX, flexible multiplexers I suppose), so it handles a
mixture of incoming and outgoing calls. But the rate at which the calls are set
up is even more than 30 a second, may double and more. If the application
polling the devices detects some of them not resonding (some can be equal to
100) it sends a call to each of all at once. We have the feeling that the decnis
can't copewith all those calls and responds with a clear or abort. Lowering the
number of calls that the VAX sends to the decnis showed that decnis processed
only 9 calls out of 100. Do you think that a trace at the GAP level would be
useful to analyze this issue?

Tano
3535.10Waiting for answersCANOVA::CALDONIMon Feb 17 1997 08:155
Hello,

any news about my problem? I'd appreciate some info. Thanks,

Tano
3535.11MARVIN::SIMSAndrew Sims, IPEG Reading.Mon Feb 24 1997 09:3745
Re: -1

If this is real customer problem then a IPMT case should be raised, as stated
in previous notes.  If there is a IPMT case then please can you post the
reference number.

The dump shows that the DECNIS is in the process of setting up or clearing down
over 900 NSP links.  There are no X.25 calls in progress, although there about
200 X.25 calls being set up or cleared down.

In the past I have seen this sort of problem when a application has decided a
call set up has failed and retries the call before the first call has
completely gone away.  If this is the case then the application needs fixing.

I suspect that reason the DEMSA appeared to work better in this environment is
because a large number of call set ups where probably being discarded in the
ethernet driver.  The X25router has a very crude overload mechanism, basically
if it detects a overload then it will discard all non-multicast traffic in the
ethernet driver.

The way the DECNIS work is very different and it will try and make progress
will the workload it is given, if that workload is setting up a several hundred
NSP links it will try and do that, however it will take sometime to do this.

The following actions would be the best way to progress with this problem -

1) If a IPMT case has not been raised then raise a IPMT case.

2) Find out more about how the application works, and fix it if necessary.

3) Try reducing NSP 'Maximum Transport Connections' to a number just above the
   number of simultaneous X.25 calls.  For example if you want to support 200
   X.25 calls then set it to 210, at the moment it is 1024.  This will limit
   the number of the NSP links and therefore the number of simultaneous call
   set ups.

4) Use X.25 relay instead of GAP and configure the number of channels on LLC2
   DTE's to equal the number of simultaneous calls you want to be able to
   support.  There are a couple of advantages to this approach.  First, the
   call set up overhead on the DECNIS is slightly less.  Second, if the
   application is trying to set up more calls than the DECNIS can handle then
   they will fail on the access system because all the LLC2 channels will be
   used up.

Andrew.