[comp.unix.i386] ISC 2.2 SL/IP throughput?

src@scuzzy.mbx.sub.org (Heiko Blume) (08/23/90)

can someone tell me what throughput i can expect with sl/ip over
a modem connection with HST modems (14400bps)? we talk to the modems
at 19200 and use hardware flow control (FAS with 16550 chips). we did
a ftp and the throughput was ~0.2 KB/s on a 600KB file, which is unacceptable.
did we do something wrong? (of course we did sldialup/attach 19200 ttyF01).
-- 
Heiko Blume c/o Diakite   blume@scuzzy.mbx.sub.org    FAX   (+49 30) 882 50 65
Kottbusser Damm 28        blume@netmbx.UUCP           VOICE (+49 30) 691 88 93
D-1000 Berlin 61          blume@netmbx.de             TELEX 184174 intro d
scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp

larry@nstar.uucp (Larry Snyder) (08/28/90)

src@scuzzy.mbx.sub.org (Heiko Blume) writes:

>can someone tell me what throughput i can expect with sl/ip over
>a modem connection with HST modems (14400bps)? we talk to the modems
>at 19200 and use hardware flow control (FAS with 16550 chips). we did
>a ftp and the throughput was ~0.2 KB/s on a 600KB file, which is unacceptable.
>did we do something wrong? (of course we did sldialup/attach 19200 ttyF01).

SlIP requires the use of duplex modems for best throughput, and the HST
is limited by the baud rate of the "back channel"
-- 
      Larry Snyder, Northern Star Communications, Notre Dame, IN USA 
            uucp: iuvax!ndmath!nstar!larry  -or-  larry@nstar
     Public Access Unix Site (219) 289-0282 (5 lines/PEP/HST/Hayes-V)

cpcahil@virtech.uucp (Conor P. Cahill) (08/29/90)

In article <1990Aug23.160013.1199@scuzzy.mbx.sub.org> src@scuzzy.mbx.sub.org (Heiko Blume) writes:
>
>can someone tell me what throughput i can expect with sl/ip over
>a modem connection with HST modems (14400bps)? we talk to the modems
>at 19200 and use hardware flow control (FAS with 16550 chips). we did
>a ftp and the throughput was ~0.2 KB/s on a 600KB file, which is unacceptable.
>did we do something wrong? (of course we did sldialup/attach 19200 ttyF01).

Your problem is probably caused by the fact that the HST modems running at 
14.4kbs are not truely full duplex.  They (in a similar vain to the t2500) have
a high speed channel in one direction and a low speed reverse channel 
(switching the directions as necessary).  

This is a really bad scenario for packetized protocols that require
acknowledgment packets (unless the modem "spoofs" the protocol, like what
the Telebits do to UUCP).

Your best bet would be to get a v.32 modem (if you require the HST 14.4 
compatibility for other purposes, use an HST dual-standard).

Full duplex 9600 baud modems (i.e. v.32) should get around 800 bytes/sec
throughput on clear lines.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

ewv@craycos.com (Eric Varsanyi) (08/30/90)

In article <1990Aug23.160013.1199@scuzzy.mbx.sub.org> src@scuzzy.mbx.sub.org (Heiko Blume) writes:
>can someone tell me what throughput i can expect with sl/ip over
>a modem connection with HST modems (14400bps)?

This does not directly relate to HST's, but it might be interesting anyway.

Configuration:
--------------
	SCO Unix (3.2.2) with the vanilla driver on a vanilla serial board
	Connection between 2 Telebit T2500's.
	Cisco terminal server providing slip bridge onto ethernet 
	Transfer of 100 Kb file (binary, Unix kernel from a Sparc)
	19200 hardware flow control on both sides

Numbers:
--------
		Kb/s (reported by ftp)	Roundtrip (reported by ping)
V.32 mode	.795			370
(s50=6)

Pep		.799			1420

Pep/compressed	.823			1551	
(s110=1)

Watching the lights on the modem it looked like Pep's reverse channel was
not wide enough to avoid turning the line around every few packets to
send back the ACK's.

Interactive was virtually useless at 1.4 seconds/echo, but using V.32
even editing with vi is tolerable. Compressed mode isn't worth the trouble
unless you are sending BIG files.

Does anyone know when/if Telebit is going to put IP header prediction into
the modems (so they don't have to turn around for the ACK's)?

-Eric Varsanyi
 Cray Computer Corporation
 ewv@craycos.com
-- 
-Eric Varsanyi (ewv@craycos.com)        Cray Computer Corporation

bob@MorningStar.Com (Bob Sutterfield) (09/01/90)

In article <1990Aug29.233628.2595@craycos.com> ewv@craycos.com (Eric Varsanyi) writes:
   SCO Unix (3.2.2) with the vanilla driver on a vanilla serial board

SunOS 4.0.3 on a 4/60 and a 4/110, on console serial ports

   Connection between 2 Telebit T2500's.

Connection between a TB+ and a TB2500, using PEP

   19200 hardware flow control on both sides

Same here

	        	Kb/s (reported by ftp)
   Pep			.799
   Pep/compressed	.823
   (s110=1)

We saw those sorts of numbers with vanilla SLIP.  Things improved to
around 1.0Kb/s with header-compressed SLIP.  We saw numbers like
1.3-1.5Kb/s FTP throughput when using PPP.

   Does anyone know when/if Telebit is going to put IP header
   prediction into the modems (so they don't have to turn around for
   the ACK's)?

Try using a smarter protocol, and the modems will do just fine.
Header compression helps a *lot*.

vjs@calcite.UUCP (Vernon Schryver) (09/02/90)

> SlIP requires the use of duplex modems for best throughput, and the HST
> is limited by the baud rate of the "back channel"

It has been widely reported that you can get some less than 960 Bytes/sec
through FTP over SLIP over a v.32 line (e.g. any of several v.32 modems or
a Telebit T2500), and somewhat more than 1,100 Bytes/sec through FTP over
SLIP over Telebit PEP (e.g. Telebit T2500 or TB+).  Among other places, I
have heard these reports in the BARRNet community from developers running
386 clones.

9600 b/s V.32 is prefered for most SLIP uses, because the 40 byte TCP/IP
headers are painful on half-duplex modem protocols like PEP (there is no
reverse channel in PEP).  You can (since I have) compress and predict the
TCP/IP headers to less than a PEP micro packet to make SLIP not
significantly more painful over PEP than cu.

In sum, if you are transfering files, use PEP.   If you are typing to
rlogin, use v.32.  (This may not apply if you have 14.4 bps V.32.)

Van Jacobson header compression code has been published in an RFC.  I'm
told it is also in 4.3BSD Reno.


Vernon Schryver,   vjs@calcite.uucp