lauren@vortex.UUCP.UUCP (05/07/86)
To get decent performance from these modems is complicated. 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 (or unreliable) serial line hardware flow control, and since ^S/^Q flow controls may be unreliable and usually 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 modem 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 a variety of 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. One possibility is the addition of a true full duplex "reverse channel" to the modem, which would enable much more software to work without modification. Whether or not all of this effort is worthwhile, in the light of existing 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. The telebit modem firmware is in a state of flux currently--that's one of the reasons I recommend a "wait and see" philosophy for the time being. Minor changes in the firmware may make major differences in terms of improving or degrading performance with any given communications protocols, so putting too much effort into this area at this time, with the firmware being subject to change in some significant areas shortly, doesn't seem like a really good idea. In the meantime, my own experiments with a pair of these modems are continuing, and I've been promised alpha releases of all new firmware for the beasties. Once the firmware settles down and I have some solid results from my experiments, I should be able to make some more concise recommendations one way or another. --Lauren--