veneman@cft.philips.nl (jaap veneman corp com) (02/28/91)
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. Jaap Veneman Philips Consumer Electronics Building SK4, Eindhoven, The Netherlands tel +31 40 732129 email: veneman@philtis.cft.philips.nl :wq :wq
oberman@rogue.llnl.gov (03/01/91)
In article <1575@philtis.cft.philips.nl>, veneman@cft.philips.nl (jaap veneman corp com) writes: I tried to reply to this, but the address bounced. I think someone out there at Philips has a bug in news. > ----- Transcript of session follows ----- >554 veneman@cft.philips.nl... only a domain cft . philips . nl was the error returned. Anyway, here is waht I tried to send: I have not looked at the documentation, so you may have already tried this. If not, increase the number of RECEIVE BUFFERS for the Ether-1 line. This is done in NCP. I believe the default is about 6. It need to be at least 15 and 20 might be even better. A clue as to what is happening is long periods of inactivity in the middle of a transfer. This indicates a packet was dropped and the system is waiting for a timeout before retransmitting. Another possibility is to lower the EXEC parameter DELAY FACTOR. This will reduce the time the system waits for the lost packet before retransmitting. But that is just making the problem more livable, not fixing it. N.B. If you have slow lines on your network you might get into trouble if the DELAY FACTOR is too low. It may result in retransmission of packets that simply have not made it to their destination. So don't get carried away with this parameter! And, if you can set up enough buffering on the PC and VAX, it really shouldn't be needed. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955
mitton@dave.enet.dec.com (Dave Mitton) (03/01/91)
>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.