Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!cbosgd!ihnp4!chinet!beirne From: beirne@chinet.UUCP (Michael G. Beirne) Newsgroups: comp.dcom.modems Subject: Re: 9600 bps dialups Message-ID: <1142@chinet.UUCP> Date: Fri, 5-Jun-87 16:00:40 EDT Article-I.D.: chinet.1142 Posted: Fri Jun 5 16:00:40 1987 Date-Received: Wed, 10-Jun-87 05:41:54 EDT References: <521@alliant.UUCP> Reply-To: beirne@chinet.UUCP (Michael G. Beirne) Distribution: world Organization: Chinet - Public Access Unix Lines: 27 Keywords: fast modems V.32 Summary: systems may not be able to receive 9600 without dropping chars Sender:beirne@chinet.UUCP (Michael G. Beirne) In article <521@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes: >My question - has anyone actually used a pair of these units over real >dialup phone lines, and what happened? If they work, they could pay for >themselves in about 3 months for a big UUCP site - even if the big site >bought both ends of the connection! > geoff steckel (steckel@alliant.com, gwes@wjh12.harvard.edu) The last company I worked for used the Telebit modems, which are pseudo 9600. The problem with these is that the kernal interrupts on each character received and a lot of systems cannot receive 9600 bps continously without dropping characters. When I had connected two machines together with a cable and transmitted several hundred thousand bytes overnight the throughput was ~2400 bps. The telebit modems only worked at all when we switched the interface speed down to 2400 bps. The modems packetize the data and then transmit it to the receiving modem very fast!, then check the packet on the receiving end for errors, and then spit out the data in a continous stream, then wait for the next packet. These types of modems were the only ones that we could have used, due to the time delay and line conditions between here and Japan. Any others would have caused uucp to abort due to errors. If your system can handle 1K of 9600 bps data incoming then you may have better luck than we did. Michael G. Beirne ihnp4!chinet!beirne