brian@sdcsvax.UUCP (04/23/86)
I recently had a pair of Telebit Trailblazer modems here for evaluation. These are the multiple-carrier devices that claim 9600 bits/sec or better on a normal dial-up phone line. The price seemed to be around $2000-$2500 or so, but was clearly adjustable. They apparently to work by packetising your input, spreading the bits out over a bunch of low-baud-rate carriers, reassembling that at the far end, and unpacketising it. There is some sort of error checking and correction (retransmission??) as part of the packeting/unpacketing. Or at least, that is how the salescritter explained it to me - the manual was kinda thin on that point. These things are sophisticated - they have enough circuitry in them that the wall-mount power supply is larger than most, and there is a (thankfully quiet) cooling fan. I'm told it has a 68000 in it. I tested them both in interactive dial-up service (vi, rn, and other typical things you'd do in a normal Unix session) and in file transfer (uucp, kermit, xmodem) applications. In interactive use, they are FAST! It's lovely to see your screen paint in just a second or so. Its really GREAT for paging through a file or reading news. BUT: These modems aren't full-duplex in the FAST mode. They apparently simulate full-duplex by turning the line around quickly, but there is a very noticeable echo delay when using them with a terminal. This is especially true when using 'vi', which often generates a burst of cursor positioning commands in response to a single keystroke. It looks jumpy. In the several days that I had the modems hooked up, I found the 1-3 second delay quite disconcerting and annoying. Note that in 300, 1200, or 2400 bits/sec mode, there is no delay - it works just like my USR Courier - perhaps better. In microcomputer file transfer use (kermit and xmodem) it works pretty well. Unfortunately, it doesn't seem to run all that fast! Apparently the packetising and turnaround delay are enough that the protocol doesn't run at anywhere near full speed because its waiting for the acknowledgement of the previous packet. Undoubtably a protocol that allows for more than one packet to be in flight would work much better. Telebit has a version of Crosstalk for the IBM PC that they claim makes very fast file transfers - I guess its tuned for use with their modem's time delays and error correction characteristics. I didn't test it. With uucp, these modems work really well. However, the uucp transfers weren't much faster than those at 480 char/sec. I've seen (somewhere in the dark past of the net) a note that showed that normal uucp gained very little speed running above 4800 baud. It is probably that effect that I'm seeing here, rather than anything the modem is doing. Thus there is some question in my mind as to whether it would be worth having this fast a modem for uucp use. The error correction seems to work very well. I can't recall having seen even one garbled or spurious character in the 3 or 4 days I was using the modem. We're on a NT DMS-100 telephone switch, and its real unusual to see that low an error rate. Also, the modem maintains a couple of statistics, including the average bit rate being achieved. It seemed to run around 17Kbit for my usage, and slightly lower for another person who tried them from a bit farther away (presumably a slightly different quality of the phone connection). Conclusions: for windowed protocols that don't falter on line turnaround delays, and for interactive use where you either can use local echo or tolerate long echo delays, these will work well. I'm not going to buy any of them now, because the price/performance ratio for our applications just doesn't seem to make it worthwhile. (Especially since 9600 baud modems are supposed to be just around the June corner at about $700 each, or so the salescritters would have me believe.) decvax\ brian@sdcsvax.ucsd.edu Brian Kantor ihnp4 >--- sdcsvax --- brian ucbvax/ Kantor@Nosc "There is more harmony in films than in life." - Francois Truffaut
phil@amdcad.UUCP (Phil Ngai) (04/24/86)
In article <1703@sdcsvax.UUCP> brian@sdcsvax.UUCP (Brian Kantor) writes: >It looks jumpy. In the several days that I had the >modems hooked up, I found the 1-3 second delay quite disconcerting and >annoying. I was expecting this to be the case. >With uucp, these modems work really well. However, the uucp transfers >weren't much faster than those at 480 char/sec. I've seen (somewhere >in the dark past of the net) a note that showed that normal uucp gained >very little speed running above 4800 baud. 4.3 BSD uucp has a couple of alternatives to the normal "g" protocol which may be worth trying. The "f" protocol is intended for use over an X.25 network and may be better able to deal with delays. The "t" protocol is intended to let you run uucp over a TCP network. We use it here as a kludge for transferring news and it runs really fast. It would be interesting to find out if either of these protocols worked better with the Telebit. >since 9600 baud modems are supposed to be just around the June corner >at about $700 each, or so the salescritters would have me believe.) I've seen the CDS V.32 full duplex 9600 over dialup modems but they are about $3500. Also, they are sync only, although you can get converters I assume. phil -- Cats are alien beings sent here to sit on our cars. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
phil@portal.UUcp (Phil Sih) (04/25/86)
In article <1703@sdcsvax.UUCP>, brian@sdcsvax.UUCP (Brian Kantor) writes: > I recently had a pair of Telebit Trailblazer modems here for > evaluation. These are the multiple-carrier devices that claim 9600 ... > These things are sophisticated - they have enough circuitry in them > that the wall-mount power supply is larger than most, and there is a > (thankfully quiet) cooling fan. I'm told it has a 68000 in it. I was quite surprised to find out the Trailblazer has more CPU power in it than just about any PC out there today. Specifically it has a 68K and a TI 320 signal processing CPU. I'm even more surprised to hear it has a fan in a wall-mount power supply! (Never seen that yet.) ... > file or reading news. BUT: These modems aren't full-duplex in the > FAST mode. They apparently simulate full-duplex by turning the line > around quickly, but there is a very noticeable echo delay when using ... > modems hooked up, I found the 1-3 second delay quite disconcerting and > annoying. > Telebit is supposed to be working on or have completed a new rev of their modem which I was told significantly reduces this problem. You should make sure you don't have old product. Lower bit rates are FDX. > In microcomputer file transfer use (kermit and xmodem) it works pretty > well. Unfortunately, it doesn't seem to run all that fast! Apparently > the packetising and turnaround delay are enough that the protocol > doesn't run at anywhere near full speed because its waiting for the > acknowledgement of the previous packet. Undoubtably a protocol that > allows for more than one packet to be in flight would work much > better. Telebit has a version of Crosstalk for the IBM PC that they > claim makes very fast file transfers - I guess its tuned for use with > their modem's time delays and error correction characteristics. I > didn't test it. The limit on file xfers in this case may not be the modem/comm line. I heard Telebit needed the special version of Crosstalk because the PC could not keep up with the data rate from the modem. Also, since the Trailblazer protocol is reliable, there is no need for host level packet acks. You just dump the data and it comes out correct on the other end. That's what their "Packetized Enesmble Protocol" is supposed to do for you. This makes me think they just cut out the file level packet acks all together in their Xtalk. > > With uucp, these modems work really well. However, the uucp transfers > weren't much faster than those at 480 char/sec. I've seen (somewhere > in the dark past of the net) a note that showed that normal uucp gained > very little speed running above 4800 baud. It is probably that effect > that I'm seeing here, rather than anything the modem is doing. Thus > there is some question in my mind as to whether it would be worth > having this fast a modem for uucp use. > If anyone has any information on this I would very much like to hear about it. > Also, the modem maintains a couple of statistics, including the average > bit rate being achieved. It seemed to run around 17Kbit for my usage, > and slightly lower for another person who tried them from a bit farther > away (presumably a slightly different quality of the phone > connection). I heard a president from one very well know Scotts Valley micro software company took one to Europe, hooked the sucker up and got 8-9kbps throughput. Variable performance is to be expected with this product. It adjusts the rate at which it can send information over the line based on the channel characteristics and noise. There have been some good articles in mags like Datacommunications covering this and Telebit has some reasonable lit. > > Conclusions: for windowed protocols that don't falter on line > turnaround delays, and for interactive use where you either can use > local echo or tolerate long echo delays, these will work well. I'm not > going to buy any of them now, because the price/performance ratio for > our applications just doesn't seem to make it worthwhile. (Especially > since 9600 baud modems are supposed to be just around the June corner > at about $700 each, or so the salescritters would have me believe.) > They could sell it for a lot less, but part of the problem is there are not enough applications out there yet that can adequately exploit a >10kbps dialup connection that is reliable. I would like to see more myself. Thanks for your report, this is the first one I have seen from a real end user. PS I don't work for Telebit. - Phil
lauren@vortex.UUCP (Lauren Weinstein) (04/25/86)
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 X.25/TCP links) designed for "conventional" error-free links generally perform badly in these sorts of situations, both due to modem characteristics and flow control problems. 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 be continuing to use normal per-packet checking and correcting but bumping software packet sizes to high values. This is not as simple as it might sound, however, due to flow control 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. I guess the best solution is to just sit back and wait a while to see what happens. --Lauren--
tankus@hsi.UUCP (Ed Tankus) (04/29/86)
> In article <1703@sdcsvax.UUCP> brian@sdcsvax.UUCP (Brian Kantor) writes: > >It looks jumpy. In the several days that I had the > >modems hooked up, I found the 1-3 second delay quite disconcerting and > >annoying. > > I was expecting this to be the case. > > >With uucp, these modems work really well. However, the uucp transfers > >weren't much faster than those at 480 char/sec. I've seen (somewhere > >in the dark past of the net) a note that showed that normal uucp gained > >very little speed running above 4800 baud. > > 4.3 BSD uucp has a couple of alternatives to the normal "g" protocol > which may be worth trying. The "f" protocol is intended for use over > an X.25 network and may be better able to deal with delays. The "t" > protocol is intended to let you run uucp over a TCP network. We use > it here as a kludge for transferring news and it runs really fast. It > would be interesting to find out if either of these protocols worked > better with the Telebit. > > >since 9600 baud modems are supposed to be just around the June corner > >at about $700 each, or so the salescritters would have me believe.) > > I've seen the CDS V.32 full duplex 9600 over dialup modems but they > are about $3500. Also, they are sync only, although you can get > converters I assume. > > phil > -- > Cats are alien beings sent here to sit on our cars. > > Phil Ngai +1 408 749 5720 > UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil > ARPA: amdcad!phil@decwrl.dec.com Does anyone know how well the modem works (if at all) with XEN*X (any flavor) or MS-D*S? -- -- Ed. Net : {noao!ihnp4!yale!}!hsi!tankus Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511 Bell : (203) 562-2101
mark@cbosgd.UUCP (Mark Horton) (04/30/86)
I haven't used the Telebit modem, but I have used the UDS 9600 A/B, and this review sounds remarkably similar to my experience. When I first got the UDS, I had a pair of them talking over a dialup line. Since the modems are sync/half duplex, you put a box called an EC100 on each end - that box converts to async, full duplex, and does an error correcting protocol as well. (Total cost: about $2000 for each modem plus $500 for the EC100, or about $5000 for a pair.) The error correction works well - it's quite nice for terminal use, as the noisy phone line }i type problems go away. But this does not mean you don't need a higher level checksum, since you can still get errors in the RS232 link between the modem and the computer. For file transfer, disabling the checksum is akin to using cu and ~%put at 9600 baud over a hardwired RS232 link - ill advised. But the half duplex nature of the connection is VERY important if you are using it for interactive UNIX type terminal uses. In particular, echoing of characters is slow because, for each character you type, it has to send the character, turn around the line, echo the character, and turn the line around again. This can take about 1/2 second per character (you didn't say how fast the Telebit does turnaround) and is quite annoying for interactive users. It feels as if the system you are using is heavily loaded, and the user gets mentally fatigued pretty fast when using a system like this. For applications where you don't need echo (UUCP, reading news) it's great. One thing I tried that I didn't see mentioned was to run TCP/IP/SLIP over such a connection. This worked quite well, but again, if you telnet or rlogin over the link, the same echo problem occurs, and it feels sluggish. Another problem with the UDS is that it really wants to be used over a leased line, with a given pair of modems configured for each other. Using it as a dialup replacement for general purpose UUCP would never work, since there are several jumpers that must match the modem on the other end, and you must tune these jumpers for your telephone connection. (For example, the line turnaround time could be adjusted to 30, 50, or 150ms, the baud rate and fallback baud rate must match, carrier detect level, training methods must all match.) UDS was very helpful in configuring it over the phone, but this isn't really intended as a dialup modem. Eventually I got a 4 wire leased line (cheap since it's within one central office) and reused the same modems in 4 wire mode. Now it's essentially a 6 mile 9600 baud RS232 cable, missing most of the control signals. I'm very interested to see how the V.32 technology works out. Is it true that the only one out now (from Concord) runs $2500, but the prices should be down to $700 "Real Soon Now?" Mark
phil@portal.UUcp (Phil Sih) (04/30/86)
In article <280@mit-vax.UUCP>, romkey@mit-vax.UUCP (John Romkey) writes: > In article <137@portal.UUcp> phil@portal.UUcp (Phil Sih) writes: > >In article <1703@sdcsvax.UUCP>, brian@sdcsvax.UUCP (Brian Kantor) writes: > >> In microcomputer file transfer use (kermit and xmodem) it works pretty > >> well. Unfortunately, it doesn't seem to run all that fast! Apparently > >> the packetising and turnaround delay are enough that the protocol > >> doesn't run at anywhere near full speed because its waiting for the > >> acknowledgement of the previous packet. Undoubtably a protocol that ... > >> their modem's time delays and error correction characteristics. I > >> didn't test it. > > > >The limit on file xfers in this case may not be the modem/comm line. I heard > >Telebit needed the special version of Crosstalk because the PC could not > >keep up with the data rate from the modem. Also, since the Trailblazer > >protocol is reliable, there is no need for host level packet acks. You > > Must be something to do with the way Crosstalk handles interrupts, then, > because I've run a (normal) PC's serial line at 19.2kbps without much problem > ARPA: romkey@borax.lcs.mit.edu Boston, MA, 02142 I talked to someone from Telebit recently and depending on the PC involved the throughput limit can be PC system/software related, but in any case will be related to the higher level acknowledgements for protocols such as xmodem. The problems of protocol interaction can I was told be solved by chaging the high level protocol to avoid the unnecessary acks. Some of the PC throughput limits can be avoided by writing software that does not use some of the more CPU expensive system facilities such as a BDOS call or Macintosh 'resources' for doing things like updating the screen. If anyone is considering trying to use V.32 modems I would recommend you try them first. I have heard from users there are big difficulties getting the things to work over the switched network and they may become unusable when the interoffice (CO) links start using lower bandwidth (32k) adaptive PCM. Anyone got any experience or info on this?
honey@down.FUN (Peter Honeyman) (04/30/86)
rick adams and i have been experimenting with the telebit trailblazer and uucp. we found that piet's 'f' protocol gives good performance. but. when the receiving host is loaded, dz overruns are a high probability event. similarly, when line noise forces modem retransmissions (yes, it retransmits on corrupt checksum), the sender overruns the modem. we found this to be a critical problem at 9600, and a moderate one at 4800. the modem wants hardware flow control, but unix drivers tend not to support it. (i am told there is a vax hardware problem here.) i considered hacking an 'F' protocol that runs 'f' in cbreak mode with dc1/dc3 flow control, but am unmotivated. and there's no guarantee that even this would suffice at 19200. peter
lauren@vortex.UUCP (Lauren Weinstein) (05/03/86)
The Telebit modem definitely wants robust flow control. Without it, the system loading and noise overrun errors rapidly become very significant and bring throughput way down. The most recent version of the modem firmware also has some apparent problems in internal buffer management that can result in incorrect data being sent to the host computer under conditions that are fairly easy to hit in normal use. This latter problem has been reported to them and hopefully will be fixed in a future firmware release. There is also a possibility that a "reverse channel" could be added to the modem which would simplify use of the device with existing, unmodified software, this would help by providing a "true" full-duplex circuit. The modem firmware is in a state of flux right now--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--