Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!shlump.nac.dec.com!dave.enet.dec.com
From: mitton@dave.enet.dec.com (Dave Mitton)
Newsgroups: comp.dcom.lans
Subject: Re: Performance problem DECs PCSA and 3C503 Etherlink
Keywords: PCLAN, PCSA, 3COM etherlink, performance problem
Message-ID: <20630@shlump.nac.dec.com>
Date: 1 Mar 91 01:47:40 GMT
References: <1575@philtis.cft.philips.nl>
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: mitton@dave.enet.dec.com (Dave Mitton)
Organization: Digital Equipment Corporation, Littleton MA
Lines: 67

>From: veneman@cft.philips.nl (jaap veneman corp com)
>Newsgroups: comp.dcom.lans
>Subject: Performance problem DECs PCSA and 3C503 Etherlink
>Date: 28 Feb 91 11:35:42 GMT


>We have serious performance problems with 3COMs 3C503 and
>DEC's PCSA. Simple file DOS file copy on the fileserver 
>varies from a few seconds to 15 seconds (100KB, unloaded server.

>NCP on the PC shows high numbers for receiver overruns.
>We have tried several suggestions for PCSA driver parameters

>Has any one suggestions for us to solve this problem. 
>(drivers of PCSA, relnrs parameters, on the PC. settings
>in PCSA servers or VMS) We use PCSA 3.1.

I suggest that you consult the Client Release Notes or Supplemental Information
for the section on Tuning.

If you are having these kind of problems it suggests that you either have
a severe performance mismatch between the VAX (you didn't say what kind)
and the PC,  or you have a heavily loaded ethernet.  (or some mixture of
the two)
Putting an analyzer on the line might help confirm the latter.

- You didn't indicate whether the problem was with disk services or file
  services.  If it's the former: Adjust the transaction counts on the
  LAD command line.  eg: LAD /R:2   lower the size till it works, or
  raise until it doesn't. (16 max)
  If it's file services only then does DECnet tuning apply.
  (I assume you did not mean NFT file transfers)

- As mentioned in another posting, boosting the LINE RECEIVE BUFFERS can
  help some.  (Hopefully, someone didn't do something stupid like lower
  EXEC MAX BUFFERS below 24?)

- If you have a LOT of multicast MOP or Routing traffic, make sure you have 
  CIRCUIT SERVICE  DISABLED.   You could disable all multicast, but a 503 can 
  filter in hardware, so this should not be an issue.

- Personally, I would improve the VAX's DECnet response timeout first.
  SET and DEFINE
	EXECUTOR DELAY FACTOR to 32 from the default 80.
   then boost EXECUTOR RETRANSMIT FACTOR to cover the link time out difference.
   I suggest about 12.  See the Release notes for technical background.
   You will see a jump in the VAX's RESPONSE TIMER counter because of this.

- Your next step is to tweak the client transport on the PC;
1) Try setting/defining EXEC NAK QUOTA to 6 (the default receive pipeline)
  This will kick out a NAK on out-of-order arrival to speed up retransmit.

2) Turn on Segment Flow control for NETBIOS connections:
	eg: find the DNN command line in STARTNET and change /FC:0 to 1
	(reboot or reload for this to take affect)

3) Given step 2, start reducing the receive pipe quota
	eg: SET/DEFINE EXEC RECEIVE PIPE to lower values

Experiment with each step before you move on to the next.

Failing all this, look for an interrupt conflict or other problem in your PC.
Or some marginal problem in your ethernet wiring.
3C503s run fairly well for us in-house on the defaults.
And we do have some real busy ethernets.

	Dave Mitton, DECnet for PCs.