Path: utzoo!attcan!uunet!peregrine!ccicpg!turnkey!conexch!root
From: r...@conexch.UUCP (Larry Dighera)
Newsgroups: comp.dcom.modems
Subject: Which is best?
Message-ID: <9515@conexch.UUCP>
Date: 18 Oct 88 14:54:21 GMT
Reply-To: r...@conexch.UUCP (Larry Dighera)
Organization: The Consultants' Exchange, Orange County, CA. (714) 842-6348
Lines: 345
I came across the following article, and thought readers of this
news group might be interested in its content.
=============================================================================
The following is Bulletin 5 from Phoenix Techline 602-936-3058
Downloaded on 10/18/87
Not long ago, many data communicators thought that dial-up modem manufacturers
had pushed transmission speeds to the limit with the introduction of 2400 bit
per second (bps) modems. Recently, however, several manufacturers have
creatively combined relatively mature techniques of data transmission with
newer technology and have introduced 9600 bps modems.
Unfortunately, a widely accepted standard for full duplex 9600 bps
transmission as defined by the International Consultative Committee for
Telegraphy and Telephony (CCITT) does not yet exist (the CCITT is currently
considering proposals for a new 9600 bps dial-up standard). This means that
today's 9600 bps modems do not offer cross-manufacturer compatibility. The
CCITT HAS endorsed a half duplex and a full duplex 9600 bps standard, but to
date implementations of these relatively flexible standards have been
proprietary, i.e., even the "standardized" modems from different manufacturers
are not compatible.
All this means that modem users who want to enjoy the dream speed of 9600 bps
must weigh the pros and cons of each 9600 bps technique before committing to a
particular 9600 bps design. This paper was written in an effort to provide
typical modem users with enough technical information and insight that they
will be able to consider the new 9600 bps modems from the position of an
educated consumer and not have to rely on information gleaned from sales
brochures and advertisements. It should be noted that the author, Wes Cowell,
is an employee of USRobotics.
THE ROAD TO 9600
High speed data communications via the dial-up phone network is limited by the
available phone line bandwidth and by random channel impairments. Just as the
diameter of a pipe limits its liquid flow capacity, so does the telephone
channel bandwidth limit its data flow capacity.
The roughly 3000-Hz available in the telephone bandwidth poses few problems
for 300 bps modems, which only use about one fifth of the bandwidth. A full
duplex 1200 bps modem requires about half the available bandwidth,
transmitting simultaneously in both directions at 600 baud and using phase
modulation to signal two data bits per baud. "Baud rate" is actually a
measure of signals per second. Because each signal can represent more than
one bit, the baud rate and bps rate of a modem are not necessarilly the same.
In the case of 1200 bps modems, their baud rate is actually 600 (signals per
second) and each signal represents two data bits. By multiplying signals per
second with the number of bits represented by each signal one determines the
bps rate: 600 signals per second X 2 bits per signal = 1200 bps.
In moving up to 2400 bps, modem designers decided not to use more bandwidth,
but to increase speed through a new signalling scheme known as quadrature
amplitude modulation (QAM).
In QAM, each signal represents four data bits. Both 1200 bps and 2400 bps
modems use the same 600 baud rate, but each 1200 bps signal carries two data
bits, while each 2400 bps signal carries four data bits:
600 signals per second X 4 bits per signal = 2400 bps.
A technique known as adaptive equalization enables 2400 bps modems to adapt to
phone line impairments call-by-call. Essentially, if the modem is experiencing
problems with a noisy line, it looks for a "sweet spot" in the bandwidth and
attempts to avoid troublesome frequencies. This technique makes 2400 bps
modems more tolerant of line noise than their 1200 bps counterparts that use
compromise equalization (a one-size-fits-all approach).
While these advanced modulation and equalization techniques in 2400 bps modems
provide for double the data rate of 1200 bps modems, they also result in a
design at least four times more complex than 1200 bps modems.
Which brings us to the problem of designing a 9600 bps modem.
Jumping to 9600 from 2400 bps is several orders of magnitude more complicated
than going to 2400 from 1200 bps. Telephone network characteristics make it
highly unlikely that success will be had in extending the "data signal
alphabet" (number of bits represented by each signal) beyond four bits per
signal.
Instead, modem designers must increase the bandwidth that is to carry the
signal, and this presents a very big problem. In fact, at speeds of 4800 bps
(1200 signals per second), the transmit and receive channels must be expanded
to the point where they actually begin to overlap. A 9600 bps "band"
requires roughly 90 percent of the available bandwidth, making it impossible
to have two-way communication without the bands interfering with each other.
A helpful analogy to the problem might be to consider a two lane highway:
traffic must flow in both directions simultaneously, but to carry more cars
per unit of time, highway designers must either increase the number of lanes
in each direction or widen the two lanes to accommodate driver error with a
margin of safety. Unfortunately, these options are not available to modem
designers as the available bandwidth is of a fixed size.
With these considerations and limitations in mind, let's examine three basic
ways to accomplish full duplex (two-way) 9600 bps communications: echo
cancellation, virtual full duplex (achieved by half duplex systems), and
asymmetrical frequency division.
ECHO-CANCELLATION
This method solves the problem of overlapping transmit and receive channels.
Each modem's receiver must try to filter out the echo of its own transmitter
and concentrate on the other modem's transmit signal. This presents a
tremendous computational problem that significantly increases the complexity
-- and cost -- of the modem. But it offers what other schemes don't:
simultaneous two-way transmission of data at 9600 bps.
The CCITT "V.32" recommendation for 9600 bps modems includes echo-
cancellation. The transmit and receive bands overlap almost completely, each
occupying 90 percent of the available bandwidth. Measured by computations per
second and bits of resolution, a V.32 modem is roughly 64 times more complex
than a 2400 bps modem. This translates directly into added development and
production costs which means that it will be some time before V.32 modems can
compete in the high- volume modem market.
Despite the fact that V.32 is a recognized standard, it is uneconomical and
unnecessarily complex for personal computer datacomm applications that simply
don't require simultaneous two-way 9600 bps transmission.
HALF DUPLEX SYSTEMS
(Virtual Full Duplex)
Half duplex solutions devote the entire bandwidth to 9600 bps in one direction
at a time, and "ping-pong" the data flow back and forth to simulate full
duplex. This is potentially the simplest scheme. Its performance is
acceptable in data transfer applications that don't involve user interaction,
i.e. file transfers. Even so, advanced error-control protocols that require
ACKnowledgments to be sent in response to received data blocks generate a high
number of "line reversals" which greatly impair overall data throughput. In
short, the benefit of higher speed is so significantly compromised by line
reversals in half duplex sessions that the net gain in data throughput may be
marginal at best.
If users want to operate in an interactive mode, their data must be sent to
the remote computer, the data channel must be reversed, and then the data must
be echoed back. This process results in significant turn-around delays which
can be very frustrating to users.
Half duplex modems of this kind are most often based on CCITT recommendation
V.29 for half duplex 9600 bps transmission on the dial-up network. V.29 based
data pumps used in facsimile systems are available as LSI chip sets, providing
a short-cut to modem manufacturers, particularly to companies that don't
develop their own modem technologies. But the major problem is that the V.29
modulation scheme has been outdated by the fact that it operates in a half
duplex mode and doesn't provide good signal to noise performance. The V.32
recommendation, which operates in a full duplex mode and employs Trellis
Coding Modulation offers greater throughput and a greater immunity to channel
impairments.
To the best of my knowledge, modems employing V.29-based modulation include
products from Racal-Vadic, Comspec, Develcon, Gamma Technology, Microcomm, and
Electronic Vaults, Inc. (EVI). These modems, however, are NOT mutually
signal compatible -- cross-manufacturer compatibility does not exist.
Another modem in the half duplex category, but not based on V.29 modulation,
is the Telebit Trailblazer (R), which uses a proprietary modulation method.
Trailblazer is based on a multi-carrier technique. Conceptually, the
transmission channel is divided into many (512), independent, very narrow
channels (think of our two-lane highway and imagine it as having 512 very
narrow lanes (say, for bicycles) going in one direction and you've got a fair
idea of how Trailblazer divides the bandwidth). The main advantage is that no
receiver adaptive equalizer is needed because each channel is very narrow
compared to the overall channel bandwidth.
Further, in the Trailblazer modulation scheme, the modulation rate in each
narrow channel can be changed somewhat independently. Trailblazer is
different from many other modems in that the decision to fall back to lower
speeds is built into the modem protocol, rather than controlled by the user's
computer port. It is claimed that in the face of channel impairments,
throughput can be adapted gracefully to channel conditions. Traditional
modulation systems would have to fall back in larger steps. But there are
three inherent MAJOR problems:
1) The turn-around delay is very long compared to conventional modulation
techniques because data must be sent in large blocks. A typed character may
take several seconds to be echoed back to the system that sent it. As a
result, the system fails to achieve the illusion of full duplex and is not
really suited to interactive online sessions.
2) The Trailblazer receiver cannot "track" carrier "phase jitter" (phase
jitter can be thought of in terms of "phase shift": think of how the whine of
a race car goes from higher to lower as it passes the viewer -- the frequency
of the sound is said to be "shifted" or "jittered"). Instead of cancelling
out phase jitter (which is commonly encountered on long distance calls) the
Trailblazer can only respond by lowering throughput to gain more immunity to
phase jitter.
3) The ability to transmit at the maximum rate when subject to channel
impairment is considerably less than for conventional modems. There is one
notable exception: the multiple channel technique offers extremely good
immunity to impulse noise because the impulse energy is distributed over
narrow channels. While conventional modems can achieve similar results
through special coding or filtering techniques they rarely implement such
methods.
ASYMMETRICAL FREQUENCY DIVISION
When one considers the nature of most PC datacomm applications, it is realized
that most applications are interactive, involving manual (typed) data entry
from one end and data file transmission from the other end.
Few, if any, PC users can justify using an expensive 9600 bps channel to carry
their typed characters when they realize that 300 bps translates to 360 words
per minute. Assuming one could type 100 words per minute, even a 100 bps
transmission channel would be sufficient.
On the other hand, file transfer should take advantage of the tremendous speed
of the microprocessor. Serial ports are often set at data rates in excess of
19,000 bps.
Considering these inherent characteristics, a communications scheme that
incorporated a high speed and a low speed channel would be best suited for
most PC datacomm applications.
Remembering the highway analogy (higher speeds mean wider lanes), one can see
how such a method would grant modem designers a large portion of the
available bandwidth for a 9600 bps channel and still leave enough room to
accommodate a narrow 300 bps channel without any channel overlap.
By utilizing two discreet channels, such a modem would avoid costly, complex
echo-cancellation schemes. And, because the channels carry data in both
directions simultaneously, the communications link is a true full duplex
connection. This means that data entered at one system would be almost
instantaneously echoed back -- eliminating the frustrating turn-around delay
experienced in half duplex sessions.
USRobotics has developed just such a modem. It passes data in one direction
using the V.32 modulation technique (a very robust method that is very immune
to phone line impairments) but employs only a 300 bps channel in the opposite
direction so that the channels do not overlap and echo-cancellation is not
necessary.
The use of the high-speed channel by the two modems is based on data demand.
In most applications, however, "channel swapping" will not be required. For
interface elegance, the modems employ a 4K buffer that allow them to perform
data rate conversion: sending and receiving speeds remain constant between the
modem and the computer -- it is only in between the modems that transmitted
and received data run at different speeds.
For interactive sessions, users are assigned the low-speed channel while the
data sent to them (long mail messages, menus, files, etc.) in the 9600 bps
channel.
For file transfer sessions, the data blocks that make up a file are sent in
the 9600 bps channel while the corresponding ACKnowledgments are returned in
the 300 bps channel. An asymmetric frequency division scheme is ideal for
file transfer where large data blocks (usually several hundred bytes in
length) are transmitted in the high-speed channel and the ACKs (usually only
a few bytes in length) are carried in the low-speed channel.
If a user switches from an interactive mode to file transfer and then back to
interactive mode, the high speed channel is dynamically and automatically
assigned to the system with the greatest data demand.
A BRIEF COMPARISON
Three options exist for data communicators who desire to operate at 9600 bps:
1) V.32-type modems offer a full duplex connection but do so by virtue of
echo-cancellation. This technique is so complex, and has proven so difficult
to employ, that the cost for such modems will remain prohibitively high and
their implementation a delicate task for some time to come.
2) Half duplex modems (either V.29 or multi-carrier) offer 9600 bps but the
turn-around delay inherent in half duplex links severely compromise overall
throughput. This degradation of throughput, however, can be more than offset
by data compression techniques assuming the modems in question support
identical compression protocols and are operating on relatively "clean" phone
lines. Both half duplex methods suffer disproportionate degradation on
"noisy" lines: the V.29 modems must spend more and more time in line reversals
as detected data errors increase, and the multi-carrier modems must sacrifice
throughput to gain noise immunity.
3) Asymmetrical Frequency Division offers 9600 bps communications in a true
full duplex implementation. By efficiently utilizing the available bandwidth,
these modems provide users with high speed file transfer capabilities and fast
response in interactive sessions. Because the transmit and receive data
channels do not overlap, expensive echo-cancelling techniques are unnecessary
making these modems economically efficient.
IN CONCLUSION
Until a widely recognized standard is agreed upon by the standards community,
and implemented by several manufacturers, modem buyers must weigh the benefits
and detriments of each 9600 bps scheme.
V.32 would be best where symmetrical, full duplex, synchronous communication
is desired (for example, dial-up HDLC links between multiplexers) and where
the user can modify his software to accommodate non-"AT" command-driven
modems.
V.29 modems would be likely solutions where absolute lowest price is required
and conformance to an international standard (in a very limited sense) is
desired.
Multi-carrier transmission schemes are well-suited to applications that
require maximum one-way throughput and where circuit conditions are known to
be good. This transmission method is also ideally suited for circuits where
immunity to impulse noise is paramount.
Users who most often work with one-way file transfers (PC-to-PC) or with real-
time applications may opt for an Asymmetrical Frequency Division scheme, which
is suited equally well for either application. The elegant approach to the
frequency division (avoiding overlapping bandwidths) also allows these modems
to present a very economical ratio between dollars and bps.
Potential high-speed-modem buyers should also consider the aspects of ease-of-
use, ease-of-implementation, and downward compatibility with existing
implemented standards (the CCITT's V.22bis for 2400 bps, Bell 212A for 1200
bps, and Bell 103 for 200 bps).
POST SCRIPT
Many modem users have voiced confusion and consternation about the lack of
compatibility between modem manufacturers at speeds greater than 2400 bps.
Modem manufacturers have embraced the Bell 212A and 103 standards for 1200 and
300 bps. In these post-divestiture days, however, Bell no longer sets modem
standards in the U.S. and hence, U.S. modem manufacturers have turned to the
CCITT as a definitive source for standards. The industry-wide acceptance of
the CCITT's V.22bis standard for 2400 bps is the best example of this shift.
The CCITT recommendations V.29 and V.32 for 9600 bps have not resulted in
compatible implementations. It is important to remember that V.29 was
originally developed as a four-wire full duplex leased-line modem and has
since been adapted by various manufacturers to encompass half duplex dial up
applications. Other problems with V.29 are that it compromises transmission
speed and is poor for interactive sessions. V.32 is proving to be
prohibitively complex and exceptionally difficult to implement (driving
development and production costs up).
Recognizing the need for an alternative to the V.32 recommendation, the CCITT
has requested proposals from modem manufacturers.
Presently, two proposals are being considered by the CCITT. One is the multi-
carrier scheme developed and sponsored by Telebit. The other is an
Asymmetrical Frequency Division scheme developed and sponsored by USRobotics.
--
USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712
TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71)
UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp
UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!root
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!imagen!atari!portal!cup.portal.com!David
From: Da...@cup.portal.com (David Michael McCord)
Newsgroups: comp.dcom.modems
Subject: Re: Which is best?
Message-ID: <10711@cup.portal.com>
Date: 31 Oct 88 16:49:33 GMT
References: <9515@conexch.UUCP> <1125@vsi1.UUCP> <299@telebit.UUCP>
Distribution: na
Organization: The Portal System (TM)
Lines: 40
I don't know why this conference isn't named comp.dcom.telebit-lovers. It
ought to be.
To dredge up my old opinions on the topic, neither the USR or the Telebit is
worth a damn when it comes to global networking, or when supporting most
real-world communications applications (SNA/SDLC, X.25, etc.). The Telebit
product does not even support synchronous transmission, not to mention the
disadvantages of getting yourself locked into a modem vendor's proprietary
modulation technique.
I say this in this forum because perhaps there are some readers who will
appreciate exposure to points of view not so parochial. It would be easy for
someone not knowledgeable about telecommunications to believe, by reading
this conference, that the Telebit or USR or whatever is the cat's pajamas.
There are some very serious reasons why, if you invest in Telebit or USR, you
are throwing your money away.
Speaking as a data and voice telecommunications professional with many years
of experience and the salary to back it up, I say that V.32 modems are going
to smash the vendor-proprietary types in the marketplace within a year. Why?
Because any large corporation using modern networking (eg, SNA/SDLC, X.25,
etc.) is buying V.32, not Telebit or USR. And these are the customers
telecomm manufacturing vendors pay attention to. Consequently, if you invest
in V.32, you are still going to be able to use it five years from now; long
after the HST and Telebit schemes fade away and disappear due to lack of
market support.
The USENET community has done itself a disservice to let itself fall into the
trap it is now in. It should be fun to watch as you netadmin types have to
replace your equipment with new modems, be they V.32 or whatever PEP
variation is officially adopted by the CCITT (hint: it will not be compatible
with your current Trailblazers). I am glad I am not going to have to stand
up in front of my managers and ask for more money to redress my past bad
decisions.
It's your choice.
Da...@cup.portal.com
Path: utzoo!utgpu!attcan!uunet!portal!cup.portal.com!David
From: Da...@cup.portal.com (David Michael McCord)
Newsgroups: comp.dcom.modems
Subject: Re: Which is best?
Message-ID: <10805@cup.portal.com>
Date: 3 Nov 88 02:16:40 GMT
References: <9515@conexch.UUCP> <1125@vsi1.UUCP> <299@telebit.UUCP> <10711@
Distribution: na
Organization: The Portal System (TM)
Lines: 13
For those who responded to my previous posting, you may be interested to
know that Network World this week had an short blurb about a company that
will be offering a V.32 chip set in OEM quantities for $150/ea.
They went on to say that by this time next year, it was expected that modems
based on this design would be offered at retail for $750 or less.
I was gratified to see this confirmation of my statement that V.32 was going
to smash the telebit/hst/etceteras "within a year". And I thought I was going
out on a limb! Heh heh.
Da...@cup.portal.com
Path: utzoo!utgpu!attcan!uunet!seismo!rick
From: r...@seismo.CSS.GOV (Rick Adams)
Newsgroups: comp.dcom.modems
Subject: Re: Which is best?
Summary: v.32 doesnt necessarily smash telebits
Message-ID: <44434@beno.seismo.CSS.GOV>
Date: 3 Nov 88 17:27:50 GMT
References: <9515@conexch.UUCP> <1125@vsi1.UUCP> <299@telebit.UUCP> <10711@ <10805@cup.portal.com>
Distribution: na
Organization: Center for Seismic Studies, Arlington, VA
Lines: 9
Why do you presume that Telebit won't buy those chips and then run PEP on
top of V.32 allowing "twice" the speed of the current implementation.
The T3000.... 24kbps asymetrical PEP...
Why not? And it could be V.32 compatible as a fall back. Are they
still going out of business?
--rick
Path: utzoo!utgpu!watmath!looking!brad
From: b...@looking.UUCP (Brad Templeton)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <2261@looking.UUCP>
Date: 4 Nov 88 18:48:23 GMT
References: <9515@conexch.UUCP> <1125@vsi1.UUCP> <299@telebit.UUCP> <10711@cup.portal.com> <11136@conexch.UUCP>
Reply-To: b...@looking.UUCP (Brad Templeton)
Distribution: na
Organization: Looking Glass Software Ltd.
Lines: 13
I would rather a modem that is 1400 bytes/second one direction and 100
bytes/second in the reverse direction than one that is 960 bytes/second
in both directions. (Is V.32 error free at 9600 bps, or are the error
protocols layered on top of a 9600 bps base rate?)
I have never had an application that called for 9600 bps in both
directions. Many people are in the same boat. Rather than V.32
supplanting PEP, it might be the other way around. People will
eventually go to whatever is fastest.
And what about PEP with echo suppression? What could *that* do?
--
Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
Newsgroups: comp.dcom.modems
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Which is best?
Message-ID: <1988Nov4.190131.22234@utzoo.uucp>
Organization: U of Toronto Zoology
References: <9515@conexch.UUCP> <1125@vsi1.UUCP> <299@telebit.UUCP> <10711@ <10805@cup.portal.com>
Date: Fri, 4 Nov 88 19:01:31 GMT
In article <10...@cup.portal.com> Da...@cup.portal.com (David Michael McCord) writes:
>... Network World this week had an short blurb about a company that
>will be offering a V.32 chip set in OEM quantities for $150/ea.
Well, me lad, I've got this bridge that just might interest you... :-)
Talk is cheap. Let's see if they can actually do it. Some very big
companies have had to eat similar boasts in the past. (Look up Intel's
claims about how quickly Ethernet was going to become dirt cheap, for
example.)
--
The Earth is our mother. | Henry Spencer at U of Toronto Zoology
Our nine months are up. |uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: utzoo!utgpu!attcan!uunet!husc6!ogccse!blake!uw-beaver!mit-eddie!rutgers!bpa!cbmvax!vu-vlsi!dsinc!lgnp1!phile
From: ph...@lgnp1.MASA.COM (Phil Eschallier)
Newsgroups: comp.dcom.modems
Subject: Re: Which is best?
Summary: tb+ is a uucp standard, now!
Message-ID: <106@lgnp1.MASA.COM>
Date: 6 Nov 88 18:53:34 GMT
References: <9515@conexch.UUCP> <1125@vsi1.UUCP> <299@telebit.UUCP> <10711@ <10805@cup.portal.com>
Distribution: na
Organization: lagniappe systems (norristown pa)
Lines: 28
In article <10...@cup.portal.com>, Da...@cup.portal.com (David Michael McCord) writes:
[deleted ...]
>
> They went on to say that by this time next year, it was expected that modems
> based on this design would be offered at retail for $750 or less.
>
> I was gratified to see this confirmation of my statement that V.32 was going
> to smash the telebit/hst/etceteras "within a year". And I thought I was going
> out on a limb! Heh heh.
>
> Da...@cup.portal.com
after following this discussion on the tb+/hst vs. the v.32 modems, i am
reasonably sure that no one is doubting that the v.32 modems will eventually
replace the tb+. in fact, i am sure the v.32 will blow away the telebit!!
what you can not sell me on is the fact it was a bad decision to purchase
the tb+ ... the uucp sites lgnp1 is connected to primarily use the tb+. in
the 4 months that i have had the modem, it has easily paid for itself in
phone bill savings!! even it were obsolete now, i have still saved money
by buying it!!
in addition, come the time next year when these v.32 modems are "more
affordable", i doubt that every uucp site currently using the tb+ will rush
out and get the new modems, atleast not immediately!! look how long the
ibm-pc/xt has held on ...
phil eschallier
ph...@lgnp1.masa.com
Path: utzoo!attcan!uunet!portal!cup.portal.com!David
From: Da...@cup.portal.com (David Michael McCord)
Newsgroups: comp.dcom.modems
Subject: Re: PEP still wins over V.32 (was Re: V.32 will dominate the ma
Message-ID: <11079@cup.portal.com>
Date: 8 Nov 88 18:10:23 GMT
References: <9515@conexch.UUCP> <1125@vsi1.UUCP> <299@telebit.UUCP>
Distribution: na
Organization: The Portal System (TM)
Lines: 7
The points about uucp protocol spoofing are well made.
However, I wouldn't be all that suprised if Telebit was the first on the
market with a uucp-spoofing v.32 device.
Da...@cup.portal.com
Path: utzoo!attcan!uunet!seismo!esosun!ucsdhub!jack!nusdhub!rwhite
From: rwh...@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.modems
Subject: Re: PEP still wins over V.32 (was Re: V.32 will dominate the ma
Message-ID: <1247@nusdhub.UUCP>
Date: 11 Nov 88 00:51:41 GMT
References: <11079@cup.portal.com>
Distribution: na
Organization: National University, San Diego
Lines: 20
in article <11...@cup.portal.com>, Da...@cup.portal.com (David Michael McCord) says:
> However, I wouldn't be all that suprised if Telebit was the first on the
> market with a uucp-spoofing v.32 device.
Why bother? There would be no particular gain to spoofing using V.32
since the connection will not be impared by passing the protocol
directly. There is no dynamic or adaptave turnaround to slow the
connection durring the acknowlegement phases, and the ack phases slide
through an open window wide enough to allow streaming (e.g. ack is not
required before next packet is sent.)
What would the spoofing buy me?
Would that purchase be enough to justify getting back into a
dependance relationship with a modem producer/programmer?
How would I upgrade to some new uupc deritive (like larger windows
and simultaneous bidirectional file transfer) without tripping all
over the spoofing mode on some modems?
Sticking strictly to V.32, how would my modem know when to spoof?
Rob.
Path: utzoo!attcan!uunet!seismo!esosun!ucsdhub!jack!nusdhub!rwhite
From: rwh...@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <1248@nusdhub.UUCP>
Date: 11 Nov 88 01:21:22 GMT
References: <2261@looking.UUCP>
Distribution: na
Organization: National University, San Diego
Lines: 67
in article <2...@looking.UUCP>, b...@looking.UUCP (Brad Templeton) says:
> I would rather a modem that is 1400 bytes/second one direction and 100
> bytes/second in the reverse direction than one that is 960 bytes/second
> in both directions. (Is V.32 error free at 9600 bps, or are the error
> protocols layered on top of a 9600 bps base rate?)
The problem is that the 1400/100 must REVERSE on directive reversal of
base data. Any protocol not "spoofed" which "waits for ACK" will
trigger TWO FULL TURNAROUNDS PER PACKET. (what is that under PEP? 20
carriers? twice.) The turnaround delay (with retraining?) will
introduce more of a delay than the 960/960 standing rate.
The equation is aproximately:
( PACKETS / WINDOW SIZE) * 2
turnarounds per transfer, with accuracy of the above increasing
proportionally to the decrease in backet size.
Mind you, this is only for non-spoofed protocols.
> I have never had an application that called for 9600 bps in both
> directions. Many people are in the same boat. Rather than V.32
> supplanting PEP, it might be the other way around. People will
> eventually go to whatever is fastest.
Not so true as you might think; to whit: (non spoofed of course)
Any small packet protocol.
Any truely intelegent workstation.
(just picture yourself at home with a DMD/programable
terminal preforming emacs-style functions at home.
downloading huge files for editing while the ones
you just finished with are being uploaded back, etc.)
Any "open-channel" bridging.
Any environment server (X-windows? NeWS?).
Any "secure" connection.
Any real-time remote service. (remote lab monitors et. al.)
or any other high-density biderectional traffic you can care to think
of, which requires a protocol. True, uucp and usenet, as they exist
today (and most hobbiest-level bbs up- down-load type transactions) do
not take advantage of high-density bidirectional traffic to remote
sites (simply because it didn't exist). Having seen the future in
these areas, and knowing that someone will eventually decide that
dialup connections which move large data-groups should be made
concurent to reduce connect time.
Things like mikenet will become practical over X.25 international
links; and inter-backbone (not necessarily usenet!) transfers over
dialup lines (think insurance companies and auto clubs and ...)
I think you may be unpleasantly supprised in the not so distant
future.
> And what about PEP with echo suppression? What could *that* do?
What?? (I may be wrong about this one, but...) If I recall corectly
there are aproximately the same type of carrier matrx involve in both
PEP and V.32. (both are obviously echo-supressed, and the use about
the same number of carriers. V.32 simply has had the troublesome
turnaround whathaveyou excluded, and implements different carrier
frequencies so as to pass through international systems with less
friction. This may be a dreadful over-simplification, but it does
apply in essence.)
Rob.
Path: utzoo!attcan!uunet!husc6!uwvax!tank!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: PEP still wins over V.32 (was Re: V.32 will dominate the ma
Message-ID: <14513@mimsy.UUCP>
Date: 12 Nov 88 19:26:17 GMT
References: <11079@cup.portal.com> <1247@nusdhub.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 51
>In article <11...@cup.portal.com> Da...@cup.portal.com (David Michael McCord)
>suggests:
>>... I wouldn't be all that suprised if Telebit was the first on the
>>market with a uucp-spoofing v.32 device.
In article <1...@nusdhub.UUCP> rwh...@nusdhub.UUCP (Robert C. White Jr.) writes:
>Why bother? There would be no particular gain to spoofing using V.32
>since the connection will not be impared by passing the protocol
>directly. There is no dynamic or adaptave turnaround to slow the
>connection durring the acknowlegement phases, and the ack phases slide
>through an open window wide enough to allow streaming (e.g. ack is not
>required before next packet is sent.)
There would still be a minor gain if the computer<->modem connection is
run at >9600 bps, or if the modem's error correction protocol reduces
actual modem<->modem bit rate to <9600 bps. UUCP's `g' packets are a
bit too small for efficient high speed communication. If the modem is
strictly 9600 bps, you would gain nothing (since any modem-to-modem
transmission of acks suppressed by spoofing would have to occur on one
end of the modem-to-computer links anyway).
If you use ACSnet-like software, *and* your data flow is approximately
balanced, a true 9600 bps full duplex connection would outperform the
average Telebit TB+ modem in terms of time required to transmit data,
because the aggregate throughput approximates 19200 bps, not ~14000 as
in the (unidirectional flow) TB+. If you use UUCP-like software, *or*
if your data flow is predominately unidirectional, an adaptive half
duplex protocol that provides more than 9600 bps in the primary
direction will win over a full duplex protocol that provides only 9600
bps in the primary direction.
It is worth noting that netnews flow is predominately unidirectional
for leaf USENET nodes. Using a better transport mechanism than UUCP
would still provide no incentive to switch to full duplex modems for
such nodes, assuming that netnews makes up the bulk of your UUCP
traffic. (At approximately 4 MB/day, it almost certainly does. This
seems to be what Mr. McCord has missed: USENET leaf nodes are pushing
multiple megabytes of junk each day in a single direction over any
given dialup connection; we *need* most of the available bandwidth to
be allocated unidirectionally. The data volume is high enough---and
growing fast enough---to indicate that this unidirectionality is not
likely to reverse for some time yet, despite the growing prevalence of
things like SLIP. Netnews data flow remains unidirectional even if
sent over IP or X.25. It will take a either a qualitative change in
usage, which seems unlikely for the near future, or an enormous
quantitative shift, which also seems unlikely, to change this. The
exact compromise provided by the TB+ may not be appropriate a year
from now, but one like it probably will.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Path: utzoo!attcan!uunet!husc6!uwvax!tank!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <14515@mimsy.UUCP>
Date: 12 Nov 88 19:56:21 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 89
>In article <2...@looking.UUCP> b...@looking.UUCP (Brad Templeton) notes:
>>I would rather a modem that is 1400 bytes/second one direction and 100
>>bytes/second in the reverse direction than one that is 960 bytes/second
>>in both directions.
In article <1...@nusdhub.UUCP> rwh...@nusdhub.UUCP (Robert C. White Jr.)
writes:
>The problem is that the 1400/100 must REVERSE on directive reversal of
>base data.
This is true, but the point is that directional reversals need not be
(and in fact are not) frequent.
>Any protocol not "spoofed" which "waits for ACK" will
>trigger TWO FULL TURNAROUNDS PER PACKET.
Not necessarily. UUCP's `g' protocol runs into trouble not because of
reversals---the 6-byte ack packets fit in the reverse channel---but
rather because its packet size (64 bytes * 3 = 192 bytes) is just large
enough to convince the TB+ to send a large data packet (1024 bytes) to
the other modem, but not large enough to fill the large packet.
Streaming protocols and large-packet protocols whose acks fit in the
reverse channel would run at full speed. (Alas, IP acks sent over SLIP
do not fit, although Van Jacobson is trying to change that. Widening
the reverse channel would also do the trick.)
>Not so true as you might think; to whit: (non spoofed of course)
>
>Any small packet protocol.
>Any truely intelegent workstation.
> (just picture yourself at home with a DMD/programable
> terminal preforming emacs-style functions at home.
> downloading huge files for editing while the ones
> you just finished with are being uploaded back, etc.)
>Any "open-channel" bridging.
>Any environment server (X-windows? NeWS?).
>Any "secure" connection.
>Any real-time remote service. (remote lab monitors et. al.)
Many of these actually have predominately unidirectional data flow.
Consider the smart editor, for instance. I type
edit foo
The first screen's worth of `foo' is loaded into my workstation and
displayed; more of `foo' is sent as I begin to examine the text. (Flow
is all host->workstation.) I decide I want to start at the end and
work backwards, and type some command. Only about 4 kB (2 `pages') of
`foo' have reached the workstation, so the workstation sends a command
saying `preempt: send the last page'. This message fits in the reverse
channel. The last screenful comes over and is displayed, and then the
last 2 kB of the file flow over. (Flow is still all host->workstation.)
As I look backward through the last 2 kB, the second-to-last 2 kB come
over. (The theory goes that the region loaded into the workstation
should always be that that is closest to surrounding the current
location, with a slight forwards bias.) I make a few changes. Most
of the commands required to make those changes on the host fit in
the reverse channel. (Never said we had to delay sending them!) A
few do not; those require reversals. No matter; the region I am editing
is in fact already on my workstation, and the changes are made in
parallel. Whenever I am idle, more of the file `foo' flows over.
Only the changes I make must be sent back to the host, and most of them
fit in the reverse channel (just as what I am now typing fits in the
reverse channel on the TB+ I am using at the moment).
See the pattern?
>or any other high-density biderectional traffic you can care to think
>of, which requires a protocol.
There *are* some. The strange thing is that, for most of us, there
are so few.
>True, uucp and usenet, as they exist today (and most hobbiest-level bbs
>up- down-load type transactions) do not take advantage of high-density
>bidirectional traffic to remote sites (simply because it didn't exist).
All the way from 300 bps to 2400 bps, we had full duplex available.
We did not make use of it not because it was not available, but
because it was either unnecessary or hard to use. Only the latter
is likely to change.
Traffic patterns probably *will* change, but not as much as, nor as
quickly as, the pro-full-duplex crowd is suggesting. In the meantime
we are making merry with our half-duplex patterns on our half-duplex
modems.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Path: utzoo!attcan!uunet!husc6!mailrus!ncar!tank!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <14533@mimsy.UUCP>
Date: 14 Nov 88 09:04:20 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 42
`OOPS'
Corrections (as pointed out by Don Speck):
In article <14...@mimsy.UUCP> I claimed:
>Not necessarily. UUCP's `g' protocol runs into trouble not because of
>reversals---the 6-byte ack packets fit in the reverse channel---but
Point 1: The TB+ does not have a `reverse channel'; it has an
`interactive mode'. (See recent technical details posting from
Telebit.) I believe (based on personal observation) that one
modem can be sending big packets while the other is sending little
interactive packets, which means that the g protocol acks fit in
the small packets; the small packets *act* like a reverse channel
but are not in fact the same. So: `1,$s/reverse channel/periodic
small packet/g' :-).
>rather because its packet size (64 bytes * 3 = 192 bytes) is just large
>enough to convince the TB+ to send a large data packet (1024 bytes) to
Ack! I do not know where I came up with 1024 bytes. Large packets are
256 bytes. (Also, I forgot the 6-byte headers this time. A 3 packet
window gives 70*3 = 210 bytes out of the 256 that would fit in a large
packet.)
>the other modem, but not large enough to fill the large packet.
>Streaming protocols and large-packet protocols whose acks fit in the
>reverse channel would run at full speed.
I should emend this: not `would' but `could': the TB+ should delay
somewhat before sending a 256-byte packet if you have fed it only 210
bytes, in the hope that it could fill the remaining 46 bytes. It would
be a bad thing for performance if, every time the host connected to the
modem hiccuped with a slow interrupt, the TB+ had to send a partial
packet. This delay appears (personal observation again) to exist and
to be on the order of ten milliseconds. This could be fixed by having
the tty driver speak a protocol with the modem, so that the modem
knows when to send immediately and when to wait. (This is, of course,
the moral equivalent of spoofing.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Path: utzoo!attcan!uunet!tektronix!reed!omen!caf
From: c...@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <725@omen.UUCP>
Date: 15 Nov 88 22:05:53 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP> <14533@mimsy.UUCP>
Reply-To: c...@omen.UUCP (Chuck Forsberg WA7KGX)
Distribution: na
Organization: Omen Technology Inc, Portland Oregon
Lines: 69
In article <14...@mimsy.UUCP> ch...@mimsy.UUCP (Chris Torek) writes:
:`OOPS'
:
:Corrections (as pointed out by Don Speck):
:
:In article <14...@mimsy.UUCP> I claimed:
:>Not necessarily. UUCP's `g' protocol runs into trouble not because of
:>reversals---the 6-byte ack packets fit in the reverse channel---but
:
:Point 1: The TB+ does not have a `reverse channel'; it has an
:`interactive mode'. (See recent technical details posting from
:Telebit.) I believe (based on personal observation) that one
:modem can be sending big packets while the other is sending little
:interactive packets, which means that the g protocol acks fit in
:the small packets; the small packets *act* like a reverse channel
:but are not in fact the same. So: `1,$s/reverse channel/periodic
:small packet/g' :-).
:
:>rather because its packet size (64 bytes * 3 = 192 bytes) is just large
:>enough to convince the TB+ to send a large data packet (1024 bytes) to
:
:Ack! I do not know where I came up with 1024 bytes. Large packets are
:256 bytes. (Also, I forgot the 6-byte headers this time. A 3 packet
:window gives 70*3 = 210 bytes out of the 256 that would fit in a large
:packet.)
:
:>the other modem, but not large enough to fill the large packet.
:>Streaming protocols and large-packet protocols whose acks fit in the
:>reverse channel would run at full speed.
:
:I should emend this: not `would' but `could': the TB+ should delay
:somewhat before sending a 256-byte packet if you have fed it only 210
:bytes, in the hope that it could fill the remaining 46 bytes. It would
:be a bad thing for performance if, every time the host connected to the
:modem hiccuped with a slow interrupt, the TB+ had to send a partial
:packet. This delay appears (personal observation again) to exist and
:to be on the order of ten milliseconds. This could be fixed by having
:the tty driver speak a protocol with the modem, so that the modem
:knows when to send immediately and when to wait.
Unimportant in the case of ZMODEM and TrailBlazer modems.
Whether or not a "short block" goes out at first, the sending
modem's buffer will continue to accept characters at full
speed. As this buffer is 4k or more, the modems will be
operating at full tilt for the remainder of the file.
With UUCP-g, Sliding Windows Kermit, WXMODEM, and SEAlink, the
frequent ACK packets are the problem, forcing frequent line
turnarounds unless spoofing is used.
:(This is, of course, the moral equivalent of spoofing.)
Adding a modest delay to data transmission is not the moral
equivalent of spoofing. Spoofing creates its own data and
eats some data, all in the name of efficiency.
Telebit's XMODEM and Kermit spoofing bollixes protocols the
spoofing does not understand. Sliding Windows Kermit and
possibly Long Packet Kermit don't mix with Kermit spoofing.
XMODEM and XMODEM-1k transfers that use the full protocol have
problems. YMODEM gets into trouble before the first file gets
through.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla BBS: 621-3746 CIS: 70007,2304 Genie: CAF
Path: utzoo!attcan!uunet!husc6!linus!alliant!steckel
From: stec...@Alliant.COM (Geoff Steckel)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Summary: need error flag propagation
Message-ID: <2628@alliant.Alliant.COM>
Date: 15 Nov 88 22:29:59 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP> <14533@mimsy.UUCP> <721@lts.UUCP>
Reply-To: stec...@alliant.Alliant.COM (Geoff Steckel)
Distribution: na
Organization: Alliant Computer Systems, Littleton, MA
Lines: 27
One reason the 'I want a wire' camp exists is that I have yet to see a
"smart" (= special protocol) modem provide an adequate 'there were errors'
signal to the host. This is also a problem with many of the ISO protocols,
though they are getting smarter.
It really doesn't help, of course, that RS-232 does not provide error
signalling, so hosts aren't equipped with any way the logical hardware
could send the message upwards.
Result: people run TCP/IP, X.25, uucp, kermit, [xyzabcdef]modem, etc., etc.
to get guaranteed delivery and error recovery.
With a 'dumb' modem I get errors, but the connection stays in place. The
higher level program will (it had better!) detect errors, retry, and log
success or failure. This is relatively soft degradation. With a "error
correcting" modem, I get catastrophic degradation - it hangs up. Real useful.
That was X.25's solution until recently as well.
"Smart" systems should be integrated with error handling all the way to
the user.
What we REALLY need is a standard host-to-modem protocol with error recovery
and error signalling. This way the modems could be as smart as they dared,
and the user would have some way to figure out what's going on. Until then,
I want a wire.
geoff steckel (stec...@alliant.COM)
Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!uflorida!haven!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: `smart' modems (was: V.32 will dominate the marketplace)
Message-ID: <14575@mimsy.UUCP>
Date: 16 Nov 88 16:28:29 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP> <2628@alliant.Alliant.COM>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 11
In article <2...@alliant.Alliant.COM> stec...@Alliant.COM (Geoff Steckel)
writes:
>With a 'dumb' modem I get errors, but the connection stays in place. ...
>With a[n] "error correcting" modem, I get catastrophic degradation -
>it hangs up.
I know of no error-correcting modem that hangs up on errors. They
do try to perform flow control, however.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!uflorida!haven!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <14576@mimsy.UUCP>
Date: 16 Nov 88 16:40:20 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP> <725@omen.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31
In article <7...@omen.UUCP> c...@omen.UUCP (Chuck Forsberg WA7KGX) includes
everything (sigh) from article <14...@mimsy.UUCP>, in which I noted that
>>This [small delay, hoping to fill a packet] could be fixed by having
>>the tty driver speak a protocol with the modem, so that the modem
>>knows when to send immediately and when to wait.
>Unimportant in the case of ZMODEM and TrailBlazer modems.
Yes. But not in the case of generic interactive traffic, or indeed
any other generic sort of traffic that does not involve long streams
of data (the ratio of traffic-where-it-matters to traffic-where-it-
does-not depends very much on your application; spoofed UUCP, or
unspoofed ZMODEM, transmission of netnews leans very far in the
does-not direction, for example).
>>(This is, of course, the moral equivalent of spoofing.)
>Adding a modest delay to data transmission is not the moral
>equivalent of spoofing. Spoofing creates its own data and
>eats some data, all in the name of efficiency.
It is not the *delay* that is equivalent: it is the speaking of a
protocol directly with the modem. If I reprogram my modem to speak
SLIP with my host, I have moved the `SLIP spoofing' up to the level of
a direct interaction with the modem. The modem is no longer spoofing
per se, but the effect is the same: the action has merely been
`legitimised'.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Newsgroups: comp.dcom.modems
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <1988Nov16.200012.18164@utzoo.uucp>
Organization: U of Toronto Zoology
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP> <14533@mimsy.UUCP> <721@lts.UUCP> <2628@alliant.Alliant.COM>
Date: Wed, 16 Nov 88 20:00:12 GMT
In article <2...@alliant.Alliant.COM> stec...@alliant.Alliant.COM (Geoff Steckel) writes:
>With a 'dumb' modem I get errors, but the connection stays in place. The
>higher level program will (it had better!) detect errors, retry, and log
>success or failure. This is relatively soft degradation. With a "error
>correcting" modem, I get catastrophic degradation - it hangs up. Real useful.
Of course, with an error correcting modem, as opposed to an "error correcting"
modem, what happens is that the data rate goes down momentarily but nothing
else unpleasant happens. I've never used an "error correcting" modem, but
we make heavy use of an error correcting modem -- the Trailblazer.
--
Sendmail is a bug, | Henry Spencer at U of Toronto Zoology
not a feature. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
|