Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: Tuning slip on a T2500/NextStation
Message-ID: <1991Jun16.184117.26803@ni.umd.edu>
Date: 16 Jun 91 18:41:17 GMT
References: <456@nic.cerf.net>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 44
Nntp-Posting-Host: sayshell.umd.edu

In article <456@nic.cerf.net> benseb@grumpy.sdsc.edu (Booker Bense) writes:
>- Well, I've been banging on a version of slip for the NeXT for about
>a month. The connection is t2500 to t2500 and I generally run it in 
>pep mode. 

This [pep] is probably the problem.  A PEP is not a full duplex; it
has to turn the line around and this takes time.  When I run SLIP
(with a V.32 modem) and am moving a large file, the RD (receive data)
light stays on continuously, with periodic flashes of TX (transmit
data) as the TCP acks are transmitted.

Try a pair of V.32 modems if you can, and see if that makes a difference.

>- I have seen some short outgoing transfers achieve the 1.6 kb/sec rate, so
>I know it's possible, at least for a short while. This is running
>regular slip ( I know I shoud be using cslip or PPP but it's not an
>option at this point. ) 

I'm working on it! :-)

>- The only thing so far that I have found that really effects speed is
>niceing the diald deamon. In my rc.slip I have 
>( Note: this is the sh nice , not the csh one !!!)
>nice --10 /usr/dialupip/diald -d 4

Now this is truly bizzare!  diald does not actively participate in any
of the packet transmission or reception.  Mostly it just dials the modem
and waits for it to drop.  I can't possibly see how this could make a 
difference since all of the transmission and reception is taking place
deep in the guts of the kernal driver at interrupt time.

>-So , what kind of ftp speeds have you got and on what kind of setup?
>Would getting more memory help the suitation? ( I'm probably going to
>do this anyway, getting a definitive yes answer would merely speed up
>the process. ) It's probably a swapping problem as there are
>definitely times during a long transfer when neither the read or send
>lites are blinking.

The SLIP code in the kernel is wired down and cannot be swapped.  Diald can
be swapped out with no effect on data transmission.  That's not to say that
rcp or ftp isn't being swapped, but this seems unlikely.  Of course, having
more memory is always a good thing.

louie