Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!vixie From: vixie@decwrl.dec.com (Paul A Vixie) Newsgroups: comp.dcom.modems Subject: Re: Telebit transfer rate problem Message-ID: Date: 21 Mar 89 11:59:57 GMT References: <640@island.uu.net> Sender: news@decwrl.dec.com Organization: DEC Western Research Lab Lines: 53 In-reply-to: brad@island.uu.net's message of 17 Mar 89 16:38:53 GMT There are a few things to consider when examining your performance on Telebit modems over UUCP. First, the Telebit has some buffering. Since it's spoofing the sender on ACK's, the sender thinks it's sent the last packet a long time (sometimes five to ten seconds) before the receiver actually receives the last packet. The buffering is not a bug; it's part of what lets the Telebit spoof the UUCP protocol. You can get a more accurate measurement of bytes-per-second if you send huge files, since the extra five or ten seconds will make very little difference in the (bytes/time) calculation. 1MB is a good round number. And as Erik Fair has pointed out in the past, 1MB is an excellent news batch size to use over Telebit modems, since the end-of-file process- ing causes five or ten seconds of idle time on the modem, so you want to minimize that by sending fewer files, which means sending bigger files. Second, most or all serial-port hardware (and their device drivers) are designed to send data very quickly (like: filling up your screen when you get into an editor) but receive it rather slowly (like: you typing at your editor). When a Telebit modem tries to dump data in at 1800 CPS, there's a good chance that your system will miss a lot of it. You're probably dealing with an interrupt per incoming character - on your Sun 2/120, you are definitely dealing with one interrupt per character. Some serial-port hardware has a FIFO for incoming data, which helps a little, but the system sometimes still ends up interrupting at its maximum rate since it's going to have another interrupt right after it gets back from emptying the FIFO. A high-water threshold that you can turn on when input data starts coming at you Real Fast is a good thing, and in fact there are serial boards on the market that have the feature, but the people who do the device drivers for these boards don't want to deal with interesting questions like: how do you know data is coming in Real Fast? How do you know when it slows down? What happens to the rest of the ports on the board when you turn on the high-water interrupt block? I keep asking Mike @Telebit to put a thinwire ethernet port on the next Telebit modem product, since the ethernet hardware on most systems will do intelligent things like DMA with big blocks of data. But then Telebit would have to deal with high-water thresholds, plus telnet or whatever protocol was to be used on the ethernet. I have a feeling that serial hardware isn't going to get any better, either. Summary: (1) send big files if you want an accurate bytes/sec number, 1MB is enough and is a good idea for news batches for other reasons. (2) expect someone's serial-receive performance to be the limiting factor in a PEP-UUCP transfer; if you can max out the modem, you have not one but two very unusual systems. -- 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