lauren@vortex.UUCP (Lauren Weinstein) (05/01/86)
To: UNIX-WIZARDS@BRL.ARPA 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--