Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!cbosgd!ucbvax!telecom From: telecom@ucbvax.UUCP Newsgroups: mod.telecom Subject: Re: FASTLINK (tm) "10,000 bps or faster" modem Message-ID: Date: Thu, 21-Nov-85 13:25:05 EST Article-I.D.: SIMTEL20.KPETERSEN.12161705520.BABYL Posted: Thu Nov 21 13:25:05 1985 Date-Received: Wed, 18-Dec-85 02:57:06 EST Sender: serge@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: telecom@mit-xx.arpa I (and a couple of other sites with these modems on loan) are planning to conduct some experiments. It is very clear that conventional file transfer programs will not function properly "as-is" with a half duplex modem that "simulates" full duplex in this manner. There are also some issues regarding transparency. To operate at high speeds, the modem requires ^S^Q flow control to operate in a particular manner to/from the hosts, or to have full RTS/CTS functions built into the drivers. As has been reported previously, the modem is basically unusable for most interactive applications. True throughput over typical dialup lines has also yet to be determined. Large block sizes on suboptimal circuits could potentially result in massive amounts of time being spent on retries--this is one of the reasons that "smallish" block sizes are usually preferable on dialup circuits, but this modem won't function very well with smallish blocks. One problem that has been reported is that the modems may crash on power glitches and require manually power cycling to recover. Also, right now the modem does not do automatic speed hunting for command input, though that is promised in a future firmware release. More details later. Experiments are really only getting under way. --Lauren--