[comp.os.vms] DECnet listen timer problem

sqkeith@csvax.liv.ac.uk (03/03/88)

Why doesn't the NCP command:

    SET CIRCUIT circ-name LISTEN TIMER value

work? NML always responds with an 'unrecogised parameter type, Listen timer'
error.

Our DECnet circuits are exclusively X25 DLMs and we wish to cut down the
hello packet traffic from 1 per 15sec to something like 1 per 120sec. The
fact that the listen timer value is resistant to change prevents us from
doing that.

Does anybody out there suffer in the same way? Solutions would be gratefully
received. It's killing our PAD.

Keith Halewood
Janet: SQKEITH@UK.AC.LIV.CSVAX
UUCP:  {backbone}!mcvax!ukc!mupsy!liv-cs!sqkeith
Arpa:  SQKEITH%CSVAX.LIV.AC.UK@NSS.CS.UCL.AC.UK
"Boring, see Civil Engineering" - entry from BT Yellow Pages.

pete@tsc.dec.com (Pete Schmitt) (03/06/88)

>Why doesn't the NCP command:
>    SET CIRCUIT circ-name LISTEN TIMER value
>work? NML always responds with an 'unrecogised parameter type, Listen timer'
>error.
> 
>Does anybody out there suffer in the same way? Solutions would be gratefully
>received. It's killing our PAD.
 
ANSWER::

	The listen timer is a multiple of the partners hello timer.  To
	change the listen timer simply increase the value of the hello
	timer for the remote, and restart the circuit..

klb@philabs.Philips.Com (Ken Bourque) (03/07/88)

In article <448@csvax.liv.ac.uk> sqkeith@csvax.liv.ac.uk writes:
>Why doesn't the NCP command:
>
>    SET CIRCUIT circ-name LISTEN TIMER value
>
>work? NML always responds with an 'unrecogised parameter type, Listen timer'
>error.

Each node has a hello timer and a listen timer.  The hello timer governs the
interval between hello messages sent by that node, and the listen timer
indicates how long the node will wait for a hello message from the node at the
other end before deciding that the other node has died.  The listen timer is
automatically set to 2x the hello timer value of the node on the other end of
the circuit.  So, in order to change your listen timer you have to set the
hello timer on the other end.  If your purpose is to reduce hello message
overhead (a good idea) you will want to set the hello timers at both ends.
Even if you can't change the hello timer at the remote node it's still
worthwhile to change the one at your node (which automatically sets the
listen timer on the remote node).


-- 
Ken Bourque    klb@philabs.philips.com    ...!{uunet,ihnp4,decvax}!philabs!klb