Conference noted::decnis

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

    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

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

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.

    I have copied the dump.
    
    Can you get the NCL scripts for this DECNIS.
    
    Andrew.

    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.

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 

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

Hello,

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

Tano

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.