eli@spdcc.COM (Steve Elias) (04/06/88)
sorry if this is a re-hash... i'm hoping someone can mail or post what they believe to be the pros & cons of the hayes 9600 modem compared to the telebit trailblazer. i understand that the telebit has uucp protocols and others built in... and that the telebit is possibly much cheaper, especially with the special usenet deal... i've been told that the hayes 9600 standard is 'more standard'... i will be buying someone's 9600 baud modem sometime soon -- any opinions appreciated... thanks... steve elias harvard!spdcc!eli
david@ms.uky.edu (David Herron -- One of the vertebrae) (04/07/88)
In article <791@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes: [asking for a comparison of the hayes 9600 baud modem and a trailblazer ... I have direct experience with the trailblazer and no other high speed modems (other than that 9600 baud short haul modem we use for bitnet) ] >i understand that the telebit has uucp protocols and others built in... >and that the telebit is possibly much cheaper, especially with the >special usenet deal... Yes it does have lots of protocols built in. A cute feature ... I'm not sure that it's truly needed, that they couldn't solve the same problem by making it more "two way" in how it works. I'm not sure about prices. The trailblazer lists at $1300 or so ($650 with the special deal). I seem to remember seeing prices for other 9600 baud modems around $1000 (list) but don't remember who from. Also, the Hayes ad in Data Communications doesn't give a price -- and calling 1-800-635-1225 didn't give me a price but they did promise to send some literature... Remember though when comparing these modems that the trailblazer is in a different class from these 9600 baud modems. The trailblazer will get up to 18Kbaud (on VERY good phone lines) and will vary it's speed down to whatever it can do depending on conditions. (Rick reported 8kbaud throughput with Chile (I think)). The other companies are claiming 19Kbaud throughput with their 9600 baud modems but they're using MNP class 5 to do this. The trailblazer does this class of throughput (I personally only ever saw 15Kbaud from my phone at home) as a natural consequence, and can use Lempel Ziv compression for a little bit more throughput. >i've been told that the hayes 9600 standard is 'more standard'... >i will be buying someone's 9600 baud modem sometime soon -- any >opinions appreciated... yeah, their modems do follow the "V" standards. The ad is also talking about being able to interoperate with some of the big name network standards like X.25 or SNA. I don't know 'bout you but I don't have X.25 access in my appartment, nor do I have an IBM mainframe there. For work purposes X.25 is potentially useful but SNA is not -- while our computing center is IBM oriented, they aren't going to be putting up SNA. Granted those protocols may become more important in the future ... Also I'm sure that Telebit would be able to put those protocols into their modem as well. In exactly the way that they've put some of these other protocols into the modem. Also Telebit is working on having their protocol accepted as a standard. Being accepted as a standard will either mean that they make the protocol public domain, or they have a lenient liscensing policy. They have 2-5 other companies liscensing the protocol from them. And they are showing great capability at improving the modem as they put new firmware versions into the field and get customer response. >thanks... Anytime -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- I don't have a Blue bone in my body!
brad@looking.UUCP (Brad Templeton) (04/08/88)
I am told the V32 protocol actually uses the same carriers to go both directions, and that the modems are capable of detecting and removing the echo of their own transmissions from the lines so that they don't get confused. This is more than just dealing with echo suppressors. Telebit says they're going to support this in software someday, unless they become the only real high speed standard, but it seems to me that this would take a bit of special hardware. After all, if they could do this, they could make each of their 512 carriers bi-directional for 1500 bytes/second in each direction. Not that one really needs that, in most applications. But I don't understand why the trailblazer doesn't permanently dedicate a couple of channels to the answer modem and a couple to the originate modem, and use the rest adaptively. Then there would no no turnaround delay for ACK packets and character echo, or so it would seem. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
david@ms.uky.edu (David Herron -- One of the vertebrae) (04/11/88)
As I recall part of the improvements in (probably) the v4 firmware
was the addition of some reverse channels. So that ack's and the
like could come back.
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- I don't have a Blue bone in my body!RAF@NIHCU.BITNET ("Roger Fajman") (04/11/88)
Why restrict your choice to the Hayes 9600 and the Trailblazer? You might want to consider V.32 modems. They are truly 9600 bps full duplex, rather than pseudo full duplex like the Hayes 9600 and the Trailblazer or asymetric like the USR Courier 9600. V.32 is already a standard and the prices are now coming down towards reasonable amounts (currently bottoming out at around $1200 to $1300).
dave@onfcanim.UUCP (Dave Martindale) (04/12/88)
In article <8804110136.AA16978@ucbvax.Berkeley.EDU> RAF@NIHCU.BITNET ("Roger Fajman") writes: >Why restrict your choice to the Hayes 9600 and the Trailblazer? You >might want to consider V.32 modems. They are truly 9600 bps full >duplex, rather than pseudo full duplex like the Hayes 9600 and the >Trailblazer or asymetric like the USR Courier 9600. But remember, the Trailblazer is 18000 bps half-duplex, with about 14000 bps left over after protocol overhead. The V.32 modems are presumably capable of 19200 bps total throughput, but you must take some out of that for error-checking protocol in any real file-transfer application. In an environment where most of the data is travelling in one direction, the Trailblazer will approach 14000 bps throughput, while a V.32 or any of the other modems are restricted to 9600 maximum. (I know that some modems, including the Trailblazer, can get higher effective throughput by compression. But news is usually already compressed (it actually saves host CPU time to do the compression on the host) and doing compression in the modem is counterproductive). A V.32 modem could get equal or better total throughput than a Trailblazer only if the amount of traffic in each direction is roughly balanced AND you have a communications protocol that sends data in both directions at once (uucico doesn't, SLIP does). The Trailblazer seems to extract about the same data bandwidth from a telephone line that the V.32 modems do, but does a better job of allocating it depending on need. Thus, it should do about as well as V.32 in the worst case, and considerably better in the best case. Also, all of the above assumes that the phone line is good enough to get full data rate. When the line is noisy or its frequency response is poor, the Trailblazer uses as much bandwidth and S/N as it finds, with the effect that the data rate throttles back in increments of perhaps 16 bps as the line gets worse. The V.32 fallback steps are much larger. The Trailblazer seems like the better choice unless the V.32 modem is substantially cheaper, even if you don't need protocol spoofing.
donegan@stanton.TCC.COM (Steven P. Donegan) (04/12/88)
In article <8804110136.AA16978@ucbvax.Berkeley.EDU>, RAF@NIHCU.BITNET ("Roger Fajman") writes: > might want to consider V.32 modems. They are truly 9600 bps full V.32 modems are normally used for synchronous devices, such as IBM protocols and X.25 protocols. To use a V.32 modem with a terminal or pc will require a sync to async converter in most cases. The cost for a quality V.32 modem is still prohibitive when compared to a Trailblazer or Hayes 9600 ($500 to several $k more expensive). -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
roberts@edsews.EDS.COM (Ted Roberts) (04/12/88)
In article <15612@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes: > > (I know that some modems, including the Trailblazer, can get higher > effective throughput by compression. But news is usually already > compressed (it actually saves host CPU time to do the compression > on the host) and doing compression in the modem is counterproductive). > I realize that news is normally compressed by the system before transmission partly due to the modems that don't do data compression in the hardware. However, I'm curious if in a this is actually the best method for the Trailblazer. Is the modified Lempel-Ziv data compression algorithm used by the news better than the type used by the Trailblazer? What algorithm is used by the TB? If the data compression used by the news is better, though, there are still other types of data to send that are not compressed. For this type of data (mail comes to mind) I would disagree that doing compression in the modem is counterproductive. This is by no means a flame, I personally don't know much about the data compression techniques used and would like to learn a bit more. -- Ted Roberts | My opinions are not necessarily those EDS Technical Services Division | of my employer. Does that mean I'm UUCP: roberts@edsews.EDS.COM | wrong?
rkh@mtune.ATT.COM (964[jak]-Robert Halloran) (04/13/88)
In article <494@edsews.EDS.COM> roberts@edsews.EDS.COM (Ted Roberts) writes: >I realize that news is normally compressed by the system before transmission >partly due to the modems that don't do data compression in the hardware. >However, I'm curious if in a this is actually the best method for the >Trailblazer. Is the modified Lempel-Ziv data compression algorithm used >by the news better than the type used by the Trailblazer? What algorithm >is used by the TB? It is my understanding that the Telebit uses L-Z compress. If you run a file through it that has already been compressed, though, the modem will expend needless cycles trying to improve the compression. >If the data compression used by the news is better, though, there are still >other types of data to send that are not compressed. For this type of data >(mail comes to mind) I would disagree that doing compression in the modem >is counterproductive. This is by no means a flame, I personally don't know >much about the data compression techniques used and would like to learn a >bit more. Agreed about compression of non-news data. It remains to be seen whether throughput is better when the host does the compress vs. the modem. You would have to sum host-time-to-compress with transmission-of-compressed-file with modem's compress disabled against transmission-of-uncompressed-file with modem's compress on. > >-- >Ted Roberts | My opinions are not necessarily those >EDS Technical Services Division | of my employer. Does that mean I'm >UUCP: roberts@edsews.EDS.COM | wrong? Bob Halloran ========================================================================= UUCP: {ATT-ACC, rutgers}!mtune!rkh Internet: rkh@mtune.ATT.COM Disclaimer: People have opinions. Companies have policies. Don't confuse MY opinions with THEIR policies. Quote: "There were incidents & accidents, there were hints & allegations" -- Paul Simon =========================================================================
rls@telebit.UUCP ( Sr. Systems Engineer) (04/13/88)
In article <494@edsews.EDS.COM>, roberts@edsews.EDS.COM (Ted Roberts) writes: > I realize that news is normally compressed by the system before transmission > partly due to the modems that don't do data compression in the hardware. > However, I'm curious if in a this is actually the best method for the > Trailblazer. Is the modified Lempel-Ziv data compression algorithm used > by the news better than the type used by the Trailblazer? What algorithm > is used by the TB? Just to set the record straight, here's a brief summary about compression. 1. The Telebit TrailBlazer uses Lempel-Ziv data compression, when the S110 register is set appropriately. It is an option that can (and should) be disabled in certain cases. 2. With compression algorithms in general, there are a couple of rules that should be considered to determine when compression is desired, and when it should be turned off. 2a. If you have data that is regular, non-random structure, then there is a chance that it will be compressible to some degree. Most compression algorithms search for some form of pattern in the data, and use various methods to reduce the amount of data sent. 2b. When a compression algorithm tries to operate on a random (such as binary, or executable) file, it will lose in two ways: first, there will be a TIME penalty involved with the actual time required to execute the compression algorithm. Second, there will be a SIZE penalty, because when uncompressible data is run through a compression algorithm, it will GROW in size from 10 to 30 percent (variable depending on data and the algorithm used). 2c. With compressible data, different data has different levels of compressiblilty. Obviously, data with very regular patterns, or lots of white space is much more compressible than random text, etc. The point is, the compression ratio can vary quite widely. A common number that we at Telebit use is about 1.5:1. This means that you can transmit 15K worth of data using only 10K of actual transmitted information. Thus it would take only 2/3rds the time to send the compressed version relative to the time it would take to send the original 15K. 3. With regard to compressing data in the modem versus in the computer, let's think about a hypothetical example. Suppose you have a modem link that runs at 19.2K (perhaps using a Telebit TrailBlazer). So the maximum speed that the link could run would be limited by the RS-232 connection between the modems and the computers. OK? Now, if we compress in the computer, we can send the COMPRESSED output out at 19.2K. This means the ACTUAL THROUGHPUT would be the 19.2K link speed times the compression ratio. If we use a compression ratio of 1.5:1, then the actual throughput would be 28.6K. But if we did compression in the modem, we'd always be limited by the link speed to 19.2K. OK? You can achieve throughput rates above the link speed by pre-compressing the data in the computer. You are limited by link speeds if you compress in the modem. 4. So the general rule of thumb is, only compress ONCE in the data stream, either in the hardware (modem) or in the software (computer). Usually, it will be desireable to compress in the computer, unless the computer cycles are scarce or expensive. I hope that this helps clear up some of the confusion about compression. Let me know if there are any other questions/comments about modem technology. Regards, ================================================================================ Richard Siegel Phone: (415) 969-3800 Senior Systems Engineer UUCP: {uunet,ames,hoptoad}!telebit!rls Telebit Corporation ARPA: telebit!rls@ames.ARPA "When the going gets tough, the weird turn pro"...HST ================================================================================
dvac@drutx.ATT.COM (VachonD) (04/14/88)
In article <8804110136.AA16978@ucbvax.Berkeley.EDU>, RAF@NIHCU.BITNET ("Roger Fajman") writes: > Why restrict your choice to the Hayes 9600 and the Trailblazer? You > might want to consider V.32 modems. They are truly 9600 bps full > duplex, rather than pseudo full duplex like the Hayes 9600 and the > Trailblazer or asymetric like the USR Courier 9600. V.32 is already > a standard and the prices are now coming down towards reasonable > amounts (currently bottoming out at around $1200 to $1300). Well, it really depends what you want to use the modem for. I use my USR9600HST for running a BBS and also to call BBS's as a hobby. If this is what you will be using the modem for, I see no reason to shell out twice as much for the 9600 baud in the other direction... If you are gonna be calling mainframes, v.32 is probably your better bet. But when you consider, your best price on a v.32 modem is around $1200 as stated above, the US Robotics looks a lot more appetizing when it is only $650. ][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][ ][ !rutgers!moss \ ][ ][ Later Days -=> Daniel Vachon <=- !ucbvax!ihnp4 > !drutx!dvac ][ ][ !mtune!ihnp4 / ][ ][ "This project is so secret, even ][ ][ I don't know what I'm doing!" Apple ][ Forever ][ ][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][-][
RAF@NIHCU.BITNET ("Roger Fajman") (04/14/88)
> But remember, the Trailblazer is 18000 bps half-duplex, with about 14000 bps > left over after protocol overhead. The V.32 modems are presumably capable > of 19200 bps total throughput, but you must take some out of that for > error-checking protocol in any real file-transfer application. > > In an environment where most of the data is travelling in one direction, > the Trailblazer will approach 14000 bps throughput, while a V.32 or any > of the other modems are restricted to 9600 maximum. MNP class 3 or above on a V.32 modem would offer more than 9600 bps because the start and stop bits are not transmitted. Some of that is used for error detection and correction, but not all. "One direction" is a key point. Any time the direction of transmission has to be reversed the Trailblazer incurs a delay that a V.32 modem does not. The Trailblazer attempts to deal with this by spoofing some of the more common protocols, but this depends on it knowing the protocol you are using and is another possible source of incompatibility. V.32 modems don't need protocol spoofing. What one needs to consider is what the actual throughput will be for the application, not the theoretical maximum throughput of the modem. Also, even if the throughput of a V.32 modem is somewhat less for a given application, it still might be worthwhile to use because V.32 is an international standard supported by many manufacturers. > A V.32 modem could get equal or better total throughput than a Trailblazer > only if the amount of traffic in each direction is roughly balanced AND > you have a communications protocol that sends data in both directions > at once (uucico doesn't, SLIP does). Traffic doesn't have to be balanced in both directions, it depends on how often the direction of transmission must be turned around. A V.32 modem can send quite a bit of data while a Trailblazer is turning around. > The Trailblazer seems to extract about the same data bandwidth from a > telephone line that the V.32 modems do, but does a better job of allocating > it depending on need. Thus, it should do about as well as V.32 in the > worst case, and considerably better in the best case. The worst case is a half duplex protocol with short blocks that the Trailblazer doesn't know how to spoof. A V.32 modem should do much better than a Trailblazer in such a situation. > Also, all of the above assumes that the phone line is good enough to > get full data rate. When the line is noisy or its frequency response > is poor, the Trailblazer uses as much bandwidth and S/N as it finds, > with the effect that the data rate throttles back in increments of > perhaps 16 bps as the line gets worse. The V.32 fallback steps are > much larger. V.32 uses a forward error correction technique to correct some errors without retransmission, so it isn't as simple to compare them as you suggest. > The Trailblazer seems like the better choice unless the V.32 modem is > substantially cheaper, even if you don't need protocol spoofing. One major consideration is who else you might need to talk to with your modem. If the modem is dedicated to one application, modems that use proprietary technology are easier to justify than if your application requires communicating with a number of other modems, not of of which belong to you. > ------------------------------ > V.32 modems are normally used for synchronous devices, such as IBM protocols > and X.25 protocols. To use a V.32 modem with a terminal or pc will require a > sync to async converter in most cases. The cost for a quality V.32 modem is > still prohibitive when compared to a Trailblazer or Hayes 9600 ($500 to > several > $k more expensive). Asynchronous V.32 modems are made by several manufacturers, such as AT&T, UDS, and Cermetek. The price is still higher than modems using proprietary technology, but has been dropping rapidly lately.
jerry@oliveb.olivetti.com (Jerry Aguirre) (04/14/88)
In article <280@telebit.UUCP> rls@telebit.UUCP ( Sr. Systems Engineer) writes: > Now, if we compress in the computer, we can send the COMPRESSED output out > at 19.2K. This means the ACTUAL THROUGHPUT would be the 19.2K link speed > times the compression ratio. If we use a compression ratio of 1.5:1, then > the actual throughput would be 28.6K. But if we did compression in the > modem, we'd always be limited by the link speed to 19.2K. OK? That is an excelent point and I didn't think of it when reading the article with the question. However I think that the original statement about it being more efficient to compress in the host was talking about cpu overhead, not thruput. Compressing the data reduces the quantity of data to be handled by subsequent queueing and IO. This reduction in IO overhead (fewer interupts) more than makes up for the overhead used in compression. (I actually ran tests to measure this.) So, you win three ways, lower CPU overhead, less disk space for the queue, and faster transfers. >4. So the general rule of thumb is, only compress ONCE in the data stream, > either in the hardware (modem) or in the software (computer). Usually, it > will be desireable to compress in the computer, unless the computer cycles > are scarce or expensive. The problem is that the typical UUCP user doesn't have real control over this. The queue for a remote site will typically contain a mix of jobs, news already compressed, file copies possibly compressed, and mail not compressed. There is no provision either for indicating which jobs should be compressed or having uucico switch modem options based on each call much less each job. Actually I am curious about what the compression really buys the typical UUCP user. The "usable" data rate is 14k which allowing for the sync to async conversion is pretty close to the 19.2K rate of the interface. With those parameters compression doesn't seem to have any advantage. Of course of the connection is poor then the data rate will drop below the 19.2K interface rate and then compression will be an advantage. Also a protocol requiring sending data in both directions would also see an advantage. Me? I talk UUCP to the modem at 9600 and all my connections are "perfect". Compression in the modem isn't going to help me any. Jerry Aguirre
paul@vixie.UUCP (Paul Vixie Esq) (04/14/88)
In article <494@edsews.EDS.COM> roberts@edsews.EDS.COM (Ted Roberts) writes: >I realize that news is normally compressed by the system before transmission >partly due to the modems that don't do data compression in the hardware. >However, I'm curious if in a this is actually the best method for the >Trailblazer. It depends. On a Vax 750 with DZ-11's, an interrupt is generated for almost every incoming character ("almost" because BSD4.3's driver, at least, can go into a polling mode of sorts when it detects high-speed input). On the 750, I get 6000 baud maximum on incoming, and the Pyramid 98x on the other end is twiddling its metaphorical thumbs waiting for a clear output buffer. *Many* machines and/or serial ports and/or device drivers fail in this way --- they were optimized for high-speed OUTPUT, and the designers just didn't have the Trailblazer in mind when they were thinking about input. In such a situation (i.e., PEP isn't saturated), you want to cut down on the amount of data passing between the CPU and the modem. Compressing it is one very good way to do this. In the ideal configuration, the receiving host would eat data up as fast as it came in, and the sending host would send so fast that the modem would be the slowest part of the link. In *that* sitation, it would make excellent sense to have the modem do the compression -- it's like an extremely conven- ient (transparent, even) data-compression co-processor. Most hosts around these days just can't get the data in (or out) of the "co-processor" fast enough for it to be useful. I wonder if a host CPU quick enough to saturate a PEP channel would automat- ically be exempt from even _needing_ help from a modem-based compression scheme? :-), sort of. -- Paul A Vixie Esq paul%vixie@uunet.uu.net {uunet,ptsfa,hoptoad}!vixie!paul San Francisco, (415) 647-7023
lmb@vsi1.UUCP (Larry Blair) (04/15/88)
In article <19963@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: | |In article <280@telebit.UUCP> rls@telebit.UUCP ( Sr. Systems Engineer) writes: |>4. So the general rule of thumb is, only compress ONCE in the data stream, |> either in the hardware (modem) or in the software (computer). Usually, it |> will be desireable to compress in the computer, unless the computer cycles |> are scarce or expensive. | |The problem is that the typical UUCP user doesn't have real control over |this. The queue for a remote site will typically contain a mix of jobs, |news already compressed, file copies possibly compressed, and mail not |compressed. There is no provision either for indicating which jobs |should be compressed or having uucico switch modem options based on each |call much less each job. | I have had compression turned on on my blazers, to make sure I compress mail transfers. Since this represents less than 5% of the traffic, it won't be a win if throughput of already-compressed news is affected negatively. Is there a definitive statement on this? --- * * O Larry Blair * * O VICOM Systems Inc. sun!pyramid----\ * * O 2520 Junction Ave. uunet!ubvax----->!vsi1!lmb * * O San Jose, CA 95134 ucbvax!tolerant/ * * O +1-408-432-8660
dave@onfcanim.UUCP (Dave Martindale) (04/15/88)
>In article <15612@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes: >> >> (I know that some modems, including the Trailblazer, can get higher >> effective throughput by compression. But news is usually already >> compressed (it actually saves host CPU time to do the compression >> on the host) and doing compression in the modem is counterproductive). which elicited several questions. Let me clarify: The UNIX compress program is pretty efficient about its data handling. It doesn't perform many instructions for each byte of input data. Uucico is somewhat expensive - it builds a packet header and computes a CRC for every 64 bytes of data. Someone did some studies a few years ago and found that, for your average VAX USENET host and average load of USENET traffic (mostly ASCII text), it was cheaper in terms of total CPU cycles to compress the news and then send the smaller files than it was to let uucico send the uncompressed data. So, even if you don't care about the increased transmission bandwidth you get, or the reduction in uucp spool space, you still want to compress news on the host purely to save host CPU cycles. Given that your news is compressed, compression in the modem actually slows things down. So, I turn off compression (via a chat script in L-devices) for hosts that send me news, on the assumption that news is most of the volume of traffic on that link. For non-news links, the traffic will be all mail, and compression is on. You pick whichever you think is better (on average) on a link-by-link basis. Not that it matters much on clean phone lines - the raw throughput of 14000 bps is enough to keep most machines busy servicing their serial input queues. Note that for the unfortunate people with Intel-architecture machines, compress uses a kludge that slows down array addressing considerably, making compress as a whole much more expensive. For these people, compression in the host may not be worthwhile.
ashok@softart.UUCP (Ashok C. Patel) (04/16/88)
> 3. With regard to compressing data in the modem versus in the computer, let's > think about a hypothetical example. Suppose you have a modem link that > runs at 19.2K (perhaps using a Telebit TrailBlazer). So the maximum speed > that the link could run would be limited by the RS-232 connection between > the modems and the computers. OK? > > Now, if we compress in the computer, we can send the COMPRESSED output out > at 19.2K. This means the ACTUAL THROUGHPUT would be the 19.2K link speed > times the compression ratio. If we use a compression ratio of 1.5:1, then > the actual throughput would be 28.6K. But if we did compression in the > modem, we'd always be limited by the link speed to 19.2K. OK? > > You can achieve throughput rates above the link speed by pre-compressing > the data in the computer. You are limited by link speeds if you compress > in the modem. > This is only true if your DTE (computer) and DCE (telephone line) data rates are equal. That is, the DTE is running at 19.2K and the DCE is running at 19.2K. But if you could break the DTE data rate free from the DCE data rate (say 38.4K) then you would get the 28.6K throughput by doing compression in the modem. But then, you will have to worry about flow control between the modem and the computer. Sometimes a nasty thing to fret over... > Regards, > >=============================================================================== >Richard Siegel Phone: (415) 969-3800 >Senior Systems Engineer UUCP: {uunet,ames,hoptoad}!telebit!rls >Telebit Corporation ARPA: telebit!rls@ames.ARPA > > "When the going gets tough, the weird turn pro"...HST >=============================================================================== likewise, ------------------------- Ashok C. Patel Softart Microsystems Inc.
donegan@stanton.TCC.COM (Steven P. Donegan) (04/16/88)
In article <8804132344.AA25064@ucbvax.Berkeley.EDU>, RAF@NIHCU.BITNET ("Roger Fajman") writes: > > > ------------------------------ > > > V.32 modems are normally used for synchronous devices, such as IBM protocols > > and X.25 protocols. To use a V.32 modem with a terminal or pc will require a > > sync to async converter in most cases. The cost for a quality V.32 modem is > > still prohibitive when compared to a Trailblazer or Hayes 9600 ($500 to > > several > > $k more expensive). > > Asynchronous V.32 modems are made by several manufacturers, such as > AT&T, UDS, and Cermetek. The price is still higher than modems using > proprietary technology, but has been dropping rapidly lately. When being quoted, I would appreciate a note regarding the origin. On another note; QUALITY V.32 modems, in my experience, denotes modems manufactured by RACAL MILGO, CODEX, ANDERSON JACOBSON and other equally HIGH QUALITY manufacturers. I will probably get flamed for this, but UDS (Motorola) and Cermatek are not (again real-life experience with MANY modems) as well built, reliable (as in MTBF) or robust (as in line noise handling capability) as the above mentioned modems. ALL OF THESE MODEMS cost at least 2000$ each. I have yet to see/use an AT&T modem that is V.32 (rather surprising in that my employer is deeply in bed with AT&T). My total experience with AT&T modems has been with the older 4096 rack mounts etc. I do not believe these to be V.32. In the V.32 and other high speed modes, you get what you pay for. NEC FUJITSU and others are also high quality, reliable manufacturers. My company at my suggestion has used Trailblazers to support immediate need, error free async communications to nasty areas...such as dial-up to Singapore, Puerto Rico, Malaysia and other really bad (line noise environments) locations. I am the primary network architect for Western Digital and take matters such as these very seriously. If any/all of you have positive experiences with more cost effective solutions to remote site up-time and support, please pass them along. My disclaimer: My opinions are my own, my company pays me for them, but they don't own them or neccessarily support them. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
gnu@hoptoad.uucp (John Gilmore) (04/16/88)
rls@telebit.UUCP (Sr. Systems Engineer) wrote: > 1. The Telebit TrailBlazer uses Lempel-Ziv data compression, when the S110 > register is set appropriately. Note that it does 12-bit compression, which is 5-10% worse than the 16 bit compression common on machines with lots of RAM. > 2b. When a compression algorithm tries to operate on a random (such as binary, > or executable) file, it will lose... LZ compression actually works pretty well on the average machine language file. Certainly ARC and Unix "compress" get a good compression, though not as good as text. Stripping /vmunix and compressing it on my Sun-3/160 resulted in a 38.44% compression savings (on a 500K file, or 188K saved). Compressing it with 12 bits, like the modem would, gives 28.44%. > Now, if we compress in the computer, we can send the COMPRESSED output out > at 19.2K... But if we did compression in the > modem, we'd always be limited by the link speed to 19.2K. OK? It's sad but true that the bottleneck in sending ASCII data between systems through a Telebit modem is getting to be the 19200 max speed on the serial cable. Telebit really should support 38,400 baud. Jerry Aguirre mentioned that compressing data on the host burns less CPU cycles too; this would be because running "compress" over say 500K of data is cheaper than squirting 188K (the data saved) out the serial port. The inner loop of compress must be a *lot* smaller than the inner loop of the serial drivers on his system, though this might not be true on all systems.
kaufman@polya.STANFORD.EDU (Marc T. Kaufman) (04/18/88)
In article <17@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes:
-When being quoted, I would appreciate a note regarding the origin. On another
-note; QUALITY V.32 modems, in my experience, denotes modems manufactured by
-RACAL MILGO, CODEX, ANDERSON JACOBSON and other equally HIGH QUALITY
-manufacturers. I will probably get flamed for this, but UDS (Motorola) and
-Cermatek are not (again real-life experience with MANY modems) as well
-built, reliable (as in MTBF) or robust (as in line noise handling capability)
-as the above mentioned modems.
Well, I have to tell you that CODEX and UDS are BOTH owned by Motorola, and
share the same internal circuits.
I was not aware that either Anderson Jacobson or Cermetek built V.32 modems.
There are several others that use the Rockwell chip set, under various names.
Marc Kaufman (kaufman@polya.stanford.edu)work@dragos.UUCP (Dragos Ruiu) (04/18/88)
In article <15617@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes: > > The UNIX compress program is pretty efficient about its data handling. > It doesn't perform many instructions for each byte of input data. > Uucico is somewhat expensive - it builds a packet header and computes > a CRC for every 64 bytes of data. [deletion] > Note that for the unfortunate people with Intel-architecture machines, > compress uses a kludge that slows down array addressing considerably, > making compress as a whole much more expensive. For these people, > compression in the host may not be worthwhile. To achieve good compression on 'small' :-( architectures like the 286 build a special version of compress that only uses 12 bit compression and use that for news. With a bit of twiddling you can even manage a 12 bit compressor that works in the small memory model. My experience is that the drop from 16 bit LZW to 12 decreases compression ~10-15% but that the cpu load it removes is significant (orders of magnitude in performance differential). You could manage 14 bit decompression and still stay within the small memory model for performance. You might also take a look at the 'stripped' down 16-bit decompressor-only recently posted to one of the sources groups. But this is getting somewhat far afield of modems... -- Dragos Ruiu ruiu@dragos.UUCP ...alberta!dragos!ruiu "cat ansi.c | grep -v noalias >proper.c"
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (04/18/88)
In article <4435@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >rls@telebit.UUCP (Sr. Systems Engineer) wrote: >> 1. The Telebit TrailBlazer uses Lempel-Ziv data compression, when the S110 >> register is set appropriately. >> Now, if we compress in the computer, we can send the COMPRESSED output out >> at 19.2K... But if we did compression in the >> modem, we'd always be limited by the link speed to 19.2K. OK? > >It's sad but true that the bottleneck in sending ASCII data between >systems through a Telebit modem is getting to be the 19200 max speed on >the serial cable. Telebit really should support 38,400 baud. > >Jerry Aguirre mentioned that compressing data on the host burns less >CPU cycles too; this would be because running "compress" over say 500K >of data is cheaper than squirting 188K (the data saved) out the serial >port. The inner loop of compress must be a *lot* smaller than the >inner loop of the serial drivers on his system, though this might not >be true on all systems. A back of the envelope calculation shows this to be true for low end cpu's such as the 68010 I'm running on (10Mhz). For transmitting a file at 9600bps, my machine can sustain the character flow at full speed, consuming something on the order of 50% of the cpu cycles available. This indicates that my effective output bandwidth is on the order of 2kb per second. Compress will quite happily consume on the order of 12kb of data per second when compressing. If we average a 30% reduction overall in a file by compression we have a net cost of: cpu cycles = cost of transmission + cost of compression = COT*.7 + COT / 6 = COT*.7 + COT*.166 = COT*.866 Giving us a net savings of about 13% (pun intended). -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
qeds@mtuxo.UUCP (01226-E.SCHULZ) (04/18/88)
In article <17@stanton.TCC.COM>, donegan@stanton.TCC.COM (Steven P. Donegan) writes: > I have yet to see/use an AT&T modem that is V.32 (rather surprising in that > my employer is deeply in bed with AT&T). The AT&T 2296A is a V.32 compatible modem, and has been available for some time. 1-800-247-7000 is the official way to find sales info. I wasn't personally involved in the development of the 2296A, but my friends down the hall were. Call or email me and I can put you in touch with them if you have technical questions. -- Ed Schulz, AT&T, Middletown, NJ (201)957-3899 mtdcb!eds
RAF@NIHCU.BITNET ("Roger Fajman") (04/19/88)
The AT&T 9600 bps V.32 modem is called the 2296. They also have a 4800 bps model called the 2248. Both the 2296 and 2248 support asynchronous and synchronous. I have tried the 2296, but don't have extensive experience with it yet. It does cost in the vicinity of $2000 and is quite large. I don't have any personal experience with the UDS or Cermetek V.32 modems. An important consideration for those of us who evaluate and recommend modems for our employers is what will be the marketplace standard for 9600 bps modems. My bets are on V.32, regardless of whether it is or is not technically superior to the Trailblazer or any other proprietary protocol. It has the great advantage of already being a CCITT standard. It's also full duplex. None of the others are either. The new chip sets that are coming out should result in prices for V.32 modems dropping further. I want 9600 bps modems from different manufacturers to be able to talk to each other. V.32 is the only hope that I see for that.
donegan@stanton.TCC.COM (Steven P. Donegan) (04/20/88)
The UDS and CODEX modems I have tested did not have the same internal hardware even though I do believe they are both owned by Motorolla. The Anderson Jacobson V.32 modems we have standardized on for all V.32 modem requirements is modem model AJ9631-S V.32/Trellis and costs in the neighborhood of 2300$ ea in single quantities (we buy many at a time and the cost drops to the high 1900$ range). -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM