avg@hq.demos.su (Vadim G. Antonov) (08/29/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). > Try to vary IP packet sizes - if your serial port or serial driver can not accept big packets on 19200, it may me be reasonable to reduce it even to 128 bytes. It's a matter of experimenting.
raymond@ele.tue.nl (Raymond Nijssen) (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)? 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. The bottleneck causing such low performance is not your system, but your modem. HST modems are '14400' bps modems, 'but not as we know it'; in fact these modems are just half-duplex 9600 baud modems, and they are not V32 compatible at all, although many vendors 'forget' to mention this subtlety, just like IBM 'forgot' to tell potential customers that the PS/2 model 30 cannot run OS/2. (Excuse me for referring to it in this newsgroup) SLIP _needs_ a full-duplex connection, and since the line-turnaround times of HST modems are very slow, the throughput will be very disappointing. To make things even worse, turning the line around at a high rate virtually eliminates the effect of the data-compression performed by the modem, so the effective connection-throughput might be even lower than 500 cps (ca. 9600/2 baud). Any ordinary MNP-5 class modem would perform about the same, which explains, if you take SL/IP overhead into account, your 200 cps rate. >did we do something wrong? (of course we did sldialup/attach 19200 ttyF01). I'm afraid you made the wrong choice when you bought the HST modem. But maybe your vendor didn't know himself that it isn't V32 compatible. ______________________________________________________________________________ Raymond X.T. Nijssen / Don't speak if you / Oh VMS, please forgive me all raymond@ele.tue.nl / speak for yourself / unfriendly things I said about you
gavron@alpha.sunquest.com (Ehud Gavron) (08/30/90)
In article <1990Aug29.233628.2595@craycos.com>, ewv@craycos.com (Eric Varsanyi) writes... #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 Our configuration: Two Telebit T2500s over an analog leased line between two serial ports on MicroVAXen. # 19200 hardware flow control on both sides Same here # #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) My comparison is *extremely* similar. # #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. PEP is worth it if you intend to do any FTP, or if you intend to use more than one average tcp link at a time. In other words, if a majority of the time this limited line will support two connections, we have found that PEP-19200 is much more responsive than V.32-9600 on the same line. Note that for single-channel interactive use, I concur that V.32 is better for latency. # #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)? I'd like to find out myself :-) #-- #-Eric Varsanyi (ewv@craycos.com) Cray Computer Corporation Ehud /----------------------------------------------------------------------------\ | Ehud Gavron, Systems analyst | gavron@vesta.sunquest.com (Internet) | | Sunquest Information Systems | uunet!sunquest!gavron (UUCP) | | 930 N. Finance Center Drive | gavron@lampf (BITNET) | | Tucson, Arizona, 85710 | (602)722-7546/885-7700 x.2546 (AT&Tnet) | |----------------------------------------------------------------------------| | your cute quote here | \----------------------------------------------------------------------------/