lauren@rand-unix.arpa (05/03/86)
The message from ames!jaw pretty clearly hits the nail on the head. To get decent performance from these modems is complicated-- just picking gigantic packet sizes and large windows doesn't do the job. The problems of system loading, flow control, dropped input characters, and other similar problems require very careful analysis to choose an "optimum" solution that will be generally useful. An earlier version of the following message was sent to net.dcom a few days ago. Below is an updated verson: ---- It would be best to wait for some time before drawing any final conclusions one way or the other on the Trailblazer. I've done (and continue to do) various testing with a pair of these, and there are a number of firmware problems in the unit that I've pointed out to them and that they are working on fixing. There have already been significant variations between previous firmware revisions. The "half-duplex" nature of the modem is actually less important than one would think, since the modems buffer data in both directions and perform a variety of other tricks. However, a more serious problem relates to flow control. While the modems do error correct (between the modems) in 9600 bps mode, data overflow errors and other errors can frequently appear between the modems and the computers. This is especially serious with many Unix systems, which may have problems accepting longish streams of input even at moderately low speeds on serial lines. Since most standard Unix systems have no serial line hardware flow control, and since ^S/^Q flow controls may be unreliable and introduce other problems, the flow control issues become quite sticky. To get good performance, you end up needing to keep normal per-packet checking in programs like xmodem, uucp, kermit, etc., otherwise computer<->modem and flow control error rates get very high very fast. Protocols (like for running above real X.25/TCP links) designed to run on top of "conventional" error-free links generally perform badly in these sorts of situations, both due to modem characteristics and flow control problems. That is, when the underlying communications path isn't already totally error-corrected and flow-controlled from computer to computer, not just from modem to modem, there's trouble with those sorts of protocols. In other words, protocols designed to run over X.25 or TCP links will not perform well when they're not actually being run over X.25/TCP-type computer to computer error corrected and flow-controlled links. Factors such as system loading, type of serial port hardware, and a variety of other issues all enter the picture. I'm in communication with the manufacturer about the issues involved, and have been discussing possible solutions with their engineers. Experiments are also being conducted involving minimal changes to software to help avoid such problems, the most promising of which currently would seem to include continuing to use normal per-packet checking and correcting but bumping software packet sizes to higher values as but one step among a number of other changes that will be needed. As I implied above, however, this is not as simple as it might sound, due to flow control and other issues. In any case, it's being worked on. Since the Telebit engineers have been quite responsive, I expect to see future firmware revisions give increasingly good performance, and other changes may also help solve some of the more general issues associated with this sort of technology. Whether or not all of this effort is worthwhile, in the light of 9600 bps full-duplex modems, is not clear. I have yet to have any hands-on experience with V.32 (Trellis coding) full-duplex modems, so I don't have any personal data on their performance characteristics in various environments. Presumably the pricing of V.32 modems will fall, but the exact timing of such price changes is unclear at this moment. There are indeed rumors that these V.32 modems may have problems on some sorts of telephone circuits. This whole area of Telebit vs. V.32, etc. is so volatile right now that I personally feel the best solution is to just sit back and wait a while to see what happens and take a good look after the dust settles. --Lauren--
jerry@oliveb.UUCP (05/06/86)
If the Telebit modems are able to divide the bandwidth into many
channels, all at different frequencies, why can't they allocate some of
the channels for one direction and some for another?
If this were possible then it could dynamically adjust the bandwidth for
traffic in each direction. The typical connection, both UUCP and
interactive, uses a lot of bandwidth in one direction, and relatively
little in the other. Less than 50 baud can handle typing and less than
1200 could handle the ACKs on a 9600 baud UUCP connection.
Any body know the technical reason this can't be done?
Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!jerryhlh@awsum.UUCP (Henry L. Hall) (05/10/86)
In article <510@brl-smoke.ARPA>, lauren@rand-unix.arpa writes: > ..... Protocols (like for running above real X.25/TCP links) designed > to run on top of "conventional" error-free links generally perform badly > in these sorts of situations, both due to modem characteristics and flow > control problems. That is, when the underlying communications path > isn't already totally error-corrected and flow-controlled from computer > to computer, not just from modem to modem, there's trouble with those > sorts of protocols. In other words, protocols designed to run over > X.25 or TCP links will not perform well when they're not actually being > run over X.25/TCP-type computer to computer error corrected and > flow-controlled links. Factors such as system loading, type of > serial port hardware, and a variety of other issues all enter the picture. A comment I'd like to make would be, why not use an intelligent controller which can ease the load on a computer by quite a considerable amount. There are several intelligent controller manufacturers which do have a TCP / X.25 interface which can handle a high speed RS-232 interface on the modem side, and which interface directly to a computer system's bus. System loading and system bus loading can possibly be a factor (a system can't get the data off the card quickly enough) but might be solved by having a large enough packet buffer memory. Helpful commentary welcomed. Thanks. -- Henry L. Hall Communication Machinery Corp., East Coast {allegra, cbosgd, decvax, gatech, ihnp4, ll-xn, philabs, utzoo} !linus!awsum!hlh