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
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...root@zswamp.uucp (Geoffrey Welsh) (06/18/91)
In a letter to All, Booker Bense (benseb@grumpy.sdsc.edu ) wrote: >- 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. Lesson #1: don't use half-duplex or asymmetrical channels for SLIP. Use V.32 mode in stead of PEP. Lesson #2: when manufacturers say that the modem is capable of "up to" 19200 bps, they mean it has done this on cooked files which don't even faintly resemble real world data. V.32 "back of the envelope calculation": 9600 bps / 8 = 1200 bytes/sec (neglect MNP or LAP-M overhead) * 2/3 TCP data/packet = 800 CPS. That's theory; I'm sure that Larry will have realistic figures for us. >- 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. This may indeed pose a problem; perhaps you'd best stick with PEP and your best configuration so far. >I'm not really concerned with interactivity, fast >ftp is much more important!! TCP/IP is an interactive protocol, so to speak (it has a limited window size and must receive ACKs before it continues transmitting); you can't separate the issues. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
gandrews@netcom.COM (Greg Andrews) (06/19/91)
In article <231.285ED74C@zswamp.uucp> root@zswamp.uucp (Geoffrey Welsh) writes: >In a letter to All, Booker Bense (benseb@grumpy.sdsc.edu ) wrote: > > >- 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. > > V.32 "back of the envelope calculation": 9600 bps / 8 = 1200 bytes/sec >(neglect MNP or LAP-M overhead) * 2/3 TCP data/packet = 800 CPS. > Sorry guys, but you can't divide by eight. Async data has TEN bits per byte. A start bit, eight data bits, and a stop bit. It makes no difference whether the modems strip start bits and stop bits across the phone line. When the data is exchanged between the modem and computer, it has all the start and stop bits reattached. PEP's data throughput on a clean line is 14400 bps, rendering 1440 cps throughput without data compression. V.32 without error correction will give you 960 cps throughput max. V.32 with error correction will give you around 1100 cps throughput without data compression. V.32bis without error correction will give you 1440 cps max. V.32bis with error correction should give you 1650 cps without data compression. (I've seen figures of 1700-1750 cps given, but I don't know if that was without compression) > >Lesson #2: when manufacturers say that the modem is capable of "up to" 19200 >bps, they mean it has done this on cooked files which don't even faintly >resemble real world data. > Not true for PEP and V.32bis, I'm afraid. It only takes a 1.3:1 compression to boost PEP's 1440 cps up to 1920, and V.32bis with error correction would need a bit less than 1.2:1. Those ratios may not be achievable with pre- compressed data, but most other types can easily be compressed by that much. V.32 has a harder time of it, requiring that the data be compressible by about 1.75:1. >Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) >root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'