Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!rogue.llnl.gov!oberman From: oberman@rogue.llnl.gov Newsgroups: comp.dcom.lans Subject: Re: Performance problem DECs PCSA and 3C503 Etherlink Message-ID: <1991Feb28.095412.1@rogue.llnl.gov> Date: 28 Feb 91 16:54:12 GMT References: <1575@philtis.cft.philips.nl> Sender: usenet@lll-winken.LLNL.GOV Lines: 35 Nntp-Posting-Host: rogue.llnl.gov 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