telecom@ucbvax.UUCP (11/18/85)
In article <720@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes: > > I got the glossy 4 page brochure from Digital Communications Associates, >Inc. (the IRMA people) about their FASTLINK (tm) 10,000 bps modem. It >also has 300 and 1200 compatibility, but I thought people might be >interested in some of the "fast" features. > > "Data transmission at 10,000 bps or faster." N1 > "Asynchronous dial-up connection." > "Automatic error detection and correction." N2 > >N1- inside it says "Poor quality lines may result in lower transmisssion > speeds." Latest Mini-Micro Systems (Nov 85) has an item on it. Article has test being performed with 'Telebit Trailblazer' (Telebit being the actual developer, DCA is a marketeer licensing it as Fastlink). Test had PC-card version in a Compaq in Washington DC talking to a stand-alone version at Telebit's office in California. "Telephone circuits were established through three long-distance carriers, AT&T, GTE Sprint, and Western Union. The TrailBlazer modem in Washington transmitted files through each carrier, respectively, at 14,819, 11,023 and 9198 bps." -- Stephen J. Shaw, Mini-Micro Systems, Nov 85, p.45 As stated in previous follow-up, they don't intend it for use as an interactive modem, but chiefly for bulk-transfer applications. Seems to me some of the high-volume net sites ought to look into these beasties. Bob Halloran Sr MTS, CONCURRENT Computer Corp (Formerly Perkin-Elmer DSG) ============================================================================= UUCP: {decvax, ucbvax, most Action Central}!vax135\ {pesnta, topaz, princeton}!petsd!pedsgd!bobh USPS: 106 Apple St M/S 305, Tinton Falls NJ 07724 DDD: (201) 758-7000
telecom@ucbvax.UUCP (11/20/85)
> As stated in previous follow-up, they don't intend it for use as an > interactive modem, but chiefly for bulk-transfer applications. Seems > to me some of the high-volume net sites ought to look into these beasties. uucp "g" protocol wouldn't work too well, since the packets are 64 bytes apiece. I remember a few horror stories about the uucp in 2.9 bsd: there is a one second-per-packet sleep in the 2.9 uucp code that everyone comments out. The packet timeout on Fastlink would have a similar effect. Just think of telling your boss that your $2000 modems are putting out 22 bytes per second... However, pyramid!csg has pointed out that one could use a different protocol; also, 'g' is supposed to support 4096-byte packets, though I've never heard of anyone actually using packets larger than 64 bytes. Then again, maybe this is our big chance to break away from uucp altogether... -- Romain Kang, Pyramid Technology Corporation US Mail: 900 Route 9, Woodbridge, NJ 07095 Ma Bell: (201) 750-2626 UUCPnet: {allegra,cmcl2,pyramid,topaz}!pyrnj!romain
chris@MIMSY.UMD.EDU (Chris Torek) (11/20/85)
If I understand correctly, FASTLINK has error correction built in; if that is so, one would not want to use the `g' protocol. I think either the `f' protocol (for X.25) or a new `h'ardwired protocol would be in order. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
telecom@ucbvax.UUCP (11/21/85)
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--
telecom@ucbvax.UUCP (11/21/85)
Unfortunately, the fact that the modems have error correction built in does not mean you don't need end to end error correction. Loss of data, particularly on busy Unix systems, is very common at even moderate speeds on serial input lines. So the fact that the data got between the modems intact does NOT mean that the data got from the modem to the computer, or from the computer to the modem without loss (particularly if the modems are busy doing retries and are unable to accept new data at full speed). Early indications are that these sorts of flow problems are so common that per packet error checking is still the most efficient way to go, with the issue of packet size being a yet to be determined variable. Overall flow control issues are also still not fully worked out. Right now, we're planning to work with standard file transfer programs and test different flow control techniques and block sizes to see how the modems perform in real life. However, we've all agreed that per block error checking should be maintained over dialup lines, just as it is at lower speeds. These modems may have some uses, but they are definitely not the ultimate. Their lack of true full duplex capability is a very significant factor. --Lauren--