Conference noted::decnis

>	On Vax side, we have in the X25 Access a limit of 64 maximum active
>	port.
>
>	On Decnis side we have 4 DTE each with 8 SVC 

So why configure the VAX that way given that you *know* it's wrong? Actually,
given the nature of the question, a previous IPMT we both remember and 3535.* I
think I can guess who the customer might be!

>	When they run the second activity, after a while the decnis dies.
>
>	At this point, under X25 Access in the Vax, I see 64 active ports, 
>	but their status is Calling and doesn't seem there is any progres 
>	in the work
>	I don't see any port in a Running state

Following through Andrew's explanation in 3535.11, I guess that NSP is chewing
up all the time setting up and tearing down connections, such that L3CS (the
X.25 call-setup component) never gets much of a chance to make progress.

>	I only see LES$ACP_V30 using 15 to 20% of the cpu, perhaps it is
>	managing the call from the application, calls that fail becouse we 
>	hit the the limit of 64 MAX Active Port in the Access Module in the Vax.

If the program simply tries to make its calls one after the other (to however
many devices are out there - 3000 springs to mind from my past dealings with
this customer) then the VAX will be wasting a great deal of its time making
calls that are thrown away by the VAX locally (i.e. they never make it out onto
the network).

>	At this point from Customer point of view the DEMSA seems to react
>	in a better way when overloaded.
>	Also it seems able to manage a bigger load than NIS. This consideration
>	is based on what they see in the producion environment

Again referring to 3535.11, the DEMSA is apparently far more aggressive here: it
throws away the call before it reaches NSP! The NIS is actually trying to help
and would make better progress were it not for the way your customer seems to
want to set things up.

>	I've noticed that the more the Vax is busy to make other tasks, the
>	worse the DECNIS does its job  

This is unsurprising: the harder the VAX pushes packets at the NIS, the harder
the NIS has to work to tell the VAX to go away and annoy somebody else.

>  A)	Is NIS really overloaded ?
>	I know it can manage up to 512 SVC with MPC-III
>	It's managing 32 active SVCs,(it has 32 SVC) plus on overhead of 
>	other 32 call that will anyway fail becouse no free line available
>	in the NIS itself

If the LED is snaking around slowly then it looks overloaded to me. Plug a
terminal into the console and use the console commands to check the stats.

>  B)	How can en external event, like for example, overloading the vax
>	be so dangerous for the activity of the NIS ?

What is happening is that once all the available SVCs are gone the NIS has to
process all future incoming NSP connects and get them as far as L3CS in the NIS.
L3CS will bounce them and then NSP will have to go through its cycle of
disconnecting the DECnet link. As soon as an NSP port is closed down, the VAX
promptly opens another one! NSP has no way of knowing that it is wasting time
even accepting the incoming connect - it has to pass it on to the target (X25)
for processing.

>  C)	Am I missing something ?  
	
Nope.

>  D)	What tool can I use to understand what's going on ?

The console stats should help. You could trace the network activity (trace NSP
on the VAX) and you'll see a flurry of requests, most of which will be
connect-disconnect, connect-disconnect in rapid succession.


There are a few things I can think of:

1. Set the VAX to allow 32 calls at most - this should stop it overloading the 
   NIS. 

2. As a more drastic measure, set NSP on the NIS to only accept 32 maximum 
   transport connections. This has the disadvantage that you will not be able
   to talk to the NIS with NCL over NSP once it gets loaded. You can still talk
   to it via the console and you may still be able to talk to it from a Digital
   Unix box using NCL over IP (but I'm not 100% sure the NIS supports this -
   I'll get someone to confirm or deny).

3. Call the customer and explain why what they are trying to do does
   not make a great deal of sense. Enlist the help of the rest of the office
   and have them all ring the customer at the same time ... perhaps if you 
   overload them the message might get through :-)

Antonio

Re:.1

>   to talk to the NIS with NCL over NSP once it gets loaded. You can still talk
>   to it via the console and you may still be able to talk to it from a Digital
>   Unix box using NCL over IP (but I'm not 100% sure the NIS supports this -
>   I'll get someone to confirm or deny).

I've had it confirmed that DECnis does support NCL over an IP transport
(although OpenVMS' NCL implementation does not).

Antonio

    If you can not manage the DECNIS with NCL running over DECnet you could
    use Telnet to connect to console.
    
    Andrew.

	Antonio,

	I did some progess, here some results:

			==================
!>	On Vax side, we have in the X25 Access a limit of 64 maximum active
!>	port.
!>
!>	On Decnis side we have 4 DTE each with 8 SVC 

!So why configure the VAX that way given that you *know* it's wrong? Actually,
!given the nature of the question, a previous IPMT we both remember and 3535.* I
!think I can guess who the customer might be!


I configured the VAX this way because we have many DECNIS connecting to the
X25 network. I wanted to understand in wich way the NIS reacts when it has
to carry on the work for the SVC defined plus the overhead to manage some 
nsp connections in excess.
			==========================
!Following through Andrew's explanation in 3535.11, I guess that NSP is chewing
!up all the time setting up and tearing down connections, such that L3CS (the
!X.25 call-setup component) never gets much of a chance to make progress.

We are speaking about 32 SVC plus 32 ports in nsp not getting connected
It isn't so much to my ayes, also becouse we support up to 512 SVC.

			=============================

!If the LED is snaking around slowly then it looks overloaded to me. Plug a
!terminal into the console and use the console commands to check the stats.

I don't receive any attention at the console from the NIS when it is busy.

			============================

!1. Set the VAX to allow 32 calls at most - this should stop it overloading the 
!   NIS. 

I cannot do that, we don't have a ono-to-one relationship between the vax 
and the NIS

			===========================

!2. As a more drastic measure, set NSP on the NIS to only accept 32 maximum 
!   transport connections. This has the disadvantage that you will not be able
!   to talk to the NIS with NCL over NSP once it gets loaded. You can still talk
!   to it via the console and you may still be able to talk to it from a Digital
!   Unix box using NCL over IP (but I'm not 100% sure the NIS supports this -
!   I'll get someone to confirm or deny).

This is what I actually did. First I tried to limit in the X25 client of the
NIS the number of the maximum active port.
It worked pretty well, but we had to keep the value of x25 access max active
port in both vax and nis to the following value:
	vax x25 cli max act port 128
	nis x25 cli max act port 64 
	application polling 256 remote devices

Based on trace and counter analisys, I also modified some dte and lapb 
characteristic like:
	- Max clear attempted 1
	- call timer 10
	- clear timer 8
	- akn timer 200 (lapb)

When we increased the number of remote devices polled, to 480, also with the
above setting we had the nis again stuck. I see all the x25 access port going
to calling but never going to running.

Later what I did was to put the limit inside decnet and not inside the x25.
I set the nis to accept only as many connections as many SVC we have defined.

This worked very  well, on all the conditions we tested.

It seems that, inside decnet there is less overhead to refuse the connection
than we have inside x25 access.

Thanks very much for your time and suggestions
Roberto

>>> We are speaking about 32 SVC plus 32 ports in nsp not getting connected
>>> It isn't so much to my ayes, also becouse we support up to 512 SVC.

The dump I saw had 900+ NSP logical links either being set up or cleared down.
The problem is the trying to set new calls before the current calls have been
completely cleared.


>>> Based on trace and counter analisys, I also modified some dte and lapb
>>> characteristic like:
>>>        - Max clear attempted 1
>>>        - call timer 10
>>>        - clear timer 8
>>>        - akn timer 200 (lapb)

Setting the call timer down is almost certainly making this problem worse as it
will increase the number of call set ups that fail when the system is
overloaded, which in turn will make the overload worse.

As pervious stated if this is a real problem then a IPMT case should be raised. 
If you raise a IPMT case then include a pointer to a dump taken when console is
hung.

Andrew.

!The dump I saw had 900+ NSP logical links either being set up or cleared down.
!The problem is the trying to set new calls before the current calls have been
!completely cleared.

 The dump you saw was taken when my colleague for the first time tried
 to use the NIS, and there were no  limit either in the vax or in  the nis.

 In this situation the application does a huge number al x5 calls, and we
 can' keep up with these numbers.
 Also because they tryied to reach 2700 dtes, and they had only 32 svc available
 for outgoing calls.


!Setting the call timer down is almost certainly making this problem worse as it
!will increase the number of call set ups that fail when the system is
!overloaded, which in turn will make the overload worse.

 I reduced the call timer becouse there were many calls that stayed in calling
 state under the dte, becouse of no answer from the receiving dte.
 So instead to wait for the default timeot of 200 seconds before to clear the 
 call itself, we only wait 10 seconds, than we clear it and we have the svc
 available sooner.


!As pervious stated if this is a real problem then a IPMT case should be raised. 
!If you raise a IPMT case then include a pointer to a dump taken when console is
!hung.

  Now with the setup we implemented, the nis manage the load and don't go 
  in hang anymore.
  The nis also answers at the console port

 The setup is the following:
	Vax side :
		- x25 acce max act port 256
		- Application working with 2700 devices
            
	Nis side:
		- 4 DTE each with 16 SVC
		- nsp max sess conn 64 
		- x25 acc max act ports 64
		- Max clear attempted 1
		- call timer 15
		- clear timer 12
		- akn timer 200 (lapb)
           

 This is the lab in wich we have only two nis, in the production we'll have
 six or sevn nis , so we can better load balance the calls between the nis.

roberto