benseb@grumpy.sdsc.edu (Booker Bense) (06/17/91)
- 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. - A back of the envelope calculation reveals: (19200 / 8 ) = 2400 bytes/sec * (2/3 data/tcp packet length ) = 1.6 Kbytes /sec ftp transfer rate. Or in other words , I shoud expect an optimal ftp rate of about 1.5 Kb/sec. - When I first started I was seeing about a 0.4 kb/sec coming in and 0.6 going out. Since I am on a 8mb next I played around with renicing the diald deamon and have acheived rates of 0.6-0.7 coming in 0.9-1.5 going out - 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. ) - The line is not the greatest , the pep connection has to retrain about every hour or so. Varying the modem settings does not seem to have much effect. I'm not really concerned with interactivity, fast ftp is much more important!! (I use ange-ftp with emacs to do remote editing on my local machine and reccomend it highly!! (available from tut.cis.ohio-state.edu )). - 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 - I don't think you want to set the priority any higher than this, the swapper runs at -12 (16) . I don't think it would be a good idea to run anything at a higher priority than this. Note:( ps -agl returns a proirity that is based on the scale (0-19) (0 least cpu 19 most cpu ) , nice works on a scale of ( -20 20) ( -20 most cpu 20 least cpu). -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. - Booker C. Bense prefered: benseb@grumpy.sdsc.edu "I think it's GOOD that everyone NeXT Mail: benseb@next.sdsc.edu becomes food " - Hobbes
louie@sayshell.umd.edu (Louis A. Mamakos) (06/17/91)
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
eps@toaster.SFSU.EDU (Eric P. Scott) (06/17/91)
In article <1991Jun16.184117.26803@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >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. Unless the acknowledgements are small enough to fit into "micro packets"--SLIP's don't. CSLIP's *do* (usually). >Try a pair of V.32 modems if you can, and see if that makes a difference. 2500s support V.32 as well. >> ( I know I shoud be using cslip or PPP but it's not an >>option at this point. ) > >I'm working on it! :-) That's what we wanted to hear! :-) Please, please, please contribute your work back to BBN/CREN. Many people will be much appreciative (and you won't have to work so hard tracking releases). -=EPS=-
louie@sayshell.umd.edu (Louis A. Mamakos) (06/17/91)
In article <1742@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >Please, please, please contribute your work back to BBN/CREN. >Many people will be much appreciative (and you won't have to >work so hard tracking releases). Actually, the compressed slip code just drops right in. Specifically, slcompress.h and slcompress.c drop in with two lines of changes to accomodate the NeXT's idea of 'netbufs' rather than the mbuf structures that it expects. Then you make another 10 or 20 lines of changes in the main line SLIP code, pretty much just stealing the sample code from the TCP header compression RFC. I'm surpised that no one has done this yet; or perhaps, since its not too hard they just haven't made much of a fuss about it. The hard part on the NeXT is that the SLIP driver (if_du.c in DailUpIP or generically, if_sl.c) has been worked over to accomodate the NeXT's network API which provides an "opaque" interface to the mbufs and netifs that we all know and love. That's what make it difficult to generalize the work that I've done as far as the compressed SLIP goes. The changes for compressed SLIP are not that extensive, I'm just starting from something a bit different from the normal SLIP driver. Of course, I still haven't got it to work quite yet, something weird going on with IP fragments... louie
bob@MorningStar.Com (Bob Sutterfield) (06/18/91)
In article <456@nic.cerf.net> benseb@grumpy.sdsc.edu (Booker Bense) writes:
...The connection is t2500 to t2500 and I generally run it in pep
mode... This is running regular slip ( I know I shoud be using
cslip or PPP but it's not an option at this point. )
Without TCP header compression (whether SLIP or PPP), you can expect
pathologically slow IP throughput over PEP. Try using the T2500s in
V.32/V.42/V.42bis mode, if they're able to maintain the carrier. If
your line is really grungy, you may need to compare whether you lose
more throughput to V.32's frequent and unpredictable retrains, or to
PEP's turnarounds. My choice? implement RFC-1144...