From:	SMTP%"Leonard@Arizona.EDU" 23-JUN-1994 10:58:46.05
To:	EVERHART
CC:	
Subj:	Re: DECnet performance? Bursty?

From: leonard@telcom.arizona.edu (Aaron Leonard)
X-Newsgroups: comp.os.vms
Subject: Re: DECnet performance? Bursty?
Date: 23 Jun 1994 13:29:15 GMT
Organization: University of Arizona Telecommunications
Lines: 52
Sender: leonard@Rena.Telcom.Arizona.EDU (Aaron Leonard)
Distribution: world
Message-ID: <2uc2nb$dl8@news.CCIT.Arizona.EDU>
Reply-To: Leonard@Arizona.EDU
NNTP-Posting-Host: rena.telcom.arizona.edu
X-Newsreader: mxrn 6.18-6
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET


In article <1994Jun20.094254.1@vogon.invermay.cri.nz>, 
kruinigerj@vogon.invermay.cri.nz (John Kruiniger, Mailing from 
AgResearch Invermay) writes:
|In article <CrJq4M.7x7@ncifcrf.gov>, welchl@ncifcrf.gov (Lester Welch) writes:
|> [picture omitted]
|> W1 is a OpenVMS (AXP) workstation located 30 miles away and connected
|> via two cisco routers and a T1 link.  W2 is a OpenVMS (AXP) work
|> station located 20 feet away.  I attempt a DECnet copy of a large
|> file from W1 and observe (via a sniffer) that the T1 traffic is very
|> bursty - peaks of (near) 100% usage of ~1 second activity separated 
|> by about 12 seconds (!!!) of inactivity.  When I do the same with W2 it is
|> NOT bursty and completes over the ethernet quickly.
|
|You might like to try reducing the NCP parameter PIPELINE QUOTA to 4032 on
|the Alpha box W1.  It's just a shot,  but the Alpha, with its ethernet all on 
|the board,  puts packets on the wire very quickly and extremely close together.
|It might be spitting them out too fast,  and with insufficient inter-packet
|gaps for the CISCO to handle.  In which case some packets don't get across the
|link,  and you have to wait for the receiving system to come back and say "Hey
|I didn't get all of the packets I was expecting".  Reducing the pipeline quota
|will reduce the maximum amouunt of data the Alpha will send before awaiting an
|acknowledgement.

I second this recommendation.  The "correct" setting of PIPELINE QUOTA
has been the subject of spirited debate, but my experimentation found
that 4032 worked best across a wide variety of network links and
node types.  (The exception would presumably be if you had a 
long/fat pipeline such as a T1 over satellite.)

Now, it may well be that the packets are not getting lost due to
someone's input buffers being overrun, but due to drops on a 
congested line.  In either case, the bursty performance can be
attributed to DECnet's retransmission approach:

|> What can explain the 12 seconds of inactivity when using DECnet?
|
|The recovery algorithm when all expected packets are not received.

NSP's retransmission algorithm is much more conservative than TCP's.
It is, however, tunable.  (See the discussion in the 
_MultiNet Administrator's Guide_, V3.3, sec. 17.1.)  With NCP's default
DELAY FACTOR of 80, DECnet will wait the maximum of (5 seconds,
5*estimated RTT) before retransmitting a lost packet.  If you shrink
DELAY FACTOR to, say, 32, then DECnet will retranmit after 
max(2 seconds, 2*est RTT).

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /