phil%amdcad@amdcad.UUCP (04/25/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@portal.UUCP (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@vortex.UUCP (04/26/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--
romkey%mit-vax@mit-vax.UUCP (04/27/86)
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 >> 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. 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. John Romkey FTP Software, Inc. (617) 868-4878 PO Box 150 UUCP: romkey@mit-vax.UUCP Kendall Square Branch ARPA: romkey@borax.lcs.mit.edu Boston, MA, 02142
Unknown@hplabs.UUCP (04/29/86)
This message is empty.
tankus%hsi@hsi.UUCP (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@cbosgd.UUCP (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@portal.UUCP (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@down.UUCP (05/01/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
phil%portal@portal.UUCP (05/02/86)
In article <4000001@ti-csl>, lindahl@ti-csl writes: > Another source for 9600 baud: MICROCOM, whose 300/1200/2400 baud modems > I recently selected for a moderately-sized dialup application (about 150 > dialin users) also makes a 300/1200/2400/9600/19.2 modem for ~ $1800 > (retail). Advantage to me is that I can upgrade my 2400 baud modems > up to the 9600 baud variety for the difference in price between the > two modems (or so I am told). They run in either sync or async mode, > but ARE NOT true V.32 (rather , they are V.22 with MICROCOM's MNP > error-correction protocol). > > Charlie Lindahl > Texas Instruments (CRL/CSL) > I have seen ads for these products and even seen a demo of MNP at a Microcom seminar but have no real data on how they actually perform in real situations. Have you measured the actual throughput you are getting from the modem? I understand the Microcom modems all use a 2.4 kbps link but to get the higher throughput rates employ various forms of compression. This being the case I find it quite difficult to believe they could reliably produce a 4:1 compression or better to do 9.6 or 19.2 kbps. On the other hand I have heard of people getting well in excess of 10 kbps using the Telebit modems and NO compression. If you have some experience with the Microcom products it would be interesting to hear it. Which modems to use is going to be an ongoing interest here.