vixie@decwrl.dec.com (Paul A Vixie) (03/10/89)
(Moving this discussion from comp.mail.uucp to comp.protocols.tcp-ip.) [Rob Warnock] # Consider the following configuration: # 1. One end: PC/AT ... "KA9Q" TCP/IP ... SLIP over COM1 at 9600 baud. # 2. Other end: VAX 780 ... 4.3bsd ... SLIP driver ... 9600-baud DH-11 # 3. Telebit Trailblazer+ on both ends. # 4. KA9Q's "TCP Max Seg Size" set to 512, "TCP Window Size" set to 4096. # # ... measured large FTP file transfers (100K+) at 880 bytes/sec of user data # (that is, FileSize/ElapsedTime = 880). The best I have ever seen between Unix # systems, even using the TB+'s UUCP mode, was a little over 800 bytes/sec at # 9600 baud. Using two MicroVax II's, MTU 296, 19200, TB+ w/ S120=12, header compression that averages 11 bytes per ACK (including framing), I *also* get 880 B/sec. But in my case I have less time to wait for an echo if I'm trying to do interactive work at the same time I have a large file transfer -- with a 296-byte MTU, there is less data between my new packet and whatever is on its way into the modem when my new packet is ready. Van Jacobson does it better -- his compression averages 5 bytes per ACK, plus one or two for framing, so he runs S120=0. He also does TOS queuing, so if some FTP or RCP data packets have already been IF_ENQUEUE'd, the next slstart will get the interactive data and the big data packets will just have to wait. (This required some changes to the interactive-style TCP clients and servers since nobody ever set TOS to anything). A few additional notes: * you can't get Van's code yet; he's waiting on the PPP spec which is sort of dragging on forever. Bugging Van would not be productive for you or for him -- trust me, I know :-). * you can't get my code either, since it's a gross, bogus hack that I wrote in desperation since Van wouldn't give me his. If I ever get my 4.3bsd machine back up, I'll make my compression code work there and then let it out into the world. Right now it's full of Ultrix KM_ALLOC stuff. * S120=12 seems to disable microshort PEP packets in the Telebit. This means that my 11-byte ACKs are sent out in a frame capable of handling 25 or so bytes, and the next PEP frame coming the other way will have ~250 bytes in it. With S120=0, the telebit seems to send a full ~250-byte-capable frame just to handle my little 11-byte ACK; either that or it's sending the first 9 bytes in a microshort, waiting for ~250 bytes to come in the other direct- ion, then sending the last 2 bytes in another microshort. I'm still unclear about shorts, microshorts, and so on. I know that S120=12 works a lot better than S120=0 for my compression scheme. If I could find another two bytes to smash out, I'd use S120=0 and wouldn't life be grand... -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013