Telebit modem questions answered
Super user
A BRIEF TECHNICAL OVERVIEW OF THE TELEBIT TRAILBLAZER MODEM
By Michael Ballard, UNIX Program Manager, Telebit Corp.
Before starting on this document, a caveat: this document is intended
to address many of the questions and comments about Telebit
modems that have appeared from the user community. We are
striving to provide as much information as possible, in such a
way that will be useful to the widest group of readers. This is
NOT intended to be a Marketing Article, but rather a technical
overview for the more sophisticated reader. Its purpose is to
inform, not to sell product. If anyone is offended by Telebit
taking this action, please mail directly to me first, to avoid
cluttering the newsgroup. Thank you.
I would like to provide some background for Unix users considering
the use of Telebit's TrailBlazer Plus high speed dialup modem.
I served as project manager and principal programmer for
Telebit's protocol support developement. The UUCP "g", Kermit,
Xmodem and Ymodem protocols are directly supported in the TrailBlazer
modem's firmware. Peter Honeyman, co-developer of ATT's
HoneyDanBer/BNU UUCP, coded those portions of the TrailBlazer
firmware which support the "g" protocol.
The Telebit modem employs a patented multicarrier modulation scheme
coined DAMQAM (Dynamically Adaptive Multicarrier Quadrature Amplitude
Modulation). A CRC-16 based sliding window protocol with selective
retransmission runs on top of this modulation scheme insuring data
integrity across the phone line. This telephone line protocol is
known as the Packetized Ensemble Protocol or PEP. PEP is the
trademark by which all modems employing this technique can be
recognized.
This technique (DAMQAM) divides the voice bandwidth into 511
individual channels each capable of passing 2, 4, or 6 bits per
baud based on the measured characteristics of the individual
frequencies associated with each channel. On a typical phone
connection, the modem uses a subset of about 400 of those channels.
Each time the modem connects to a circuit established on the dialup
Public Switched Telephone Network (PSTN), the TrailBlazer measures the
quality of the connection, and determines the usable subset of the 511
carriers. The aggregate sum of bits modulated on this subset of
carriers multiplied times the baud rate yields a bit per second
rate that on a local telephone connection (i.e. round trip through
your local telco) is 18031 bps. This 18031 bps is then reduced by
about 20% to allow for the CRC overhead, to about 14400 bps of data
throughput.
Long distance line quality varies with location and carrier, but you
can expect this number to be in the 10000 to 17000 bps range under
most conditions domestically. By choosing a high quality long
distance carrier, you will ensure the best throughput overall.
The modem operates at 7.35 and 88.26 baud, transparently changing
baud rates to accomodate the pace and quantity of data traffic.
When in "interactive mode" the modem sends data using 11 msec
packets (which run at 88.26 baud). Each packet contains 15 bytes
of data. In "file transfer mode" the modem uses 136 msec packets
(that transfer at 7.35 baud) that contain 256 bytes of data.
The TrailBlazer decides which packet size to use on an ongoing
dynamic basis. No intervention from the user is required.
At lower speeds, such as 300, 1200, and 2400 bps, the TrailBlazer
provides emulation (performed in the DSP section, not by a "chip"
modem) to support these standards. The 300 bps standard is called
Bell 103C. At 1200 bps, two standards exist, Bell 212A and CCITT
V.22. Both are supported. At 2400 bps, the standard is called
CCITT V.22 bis. These speeds are all available with or without
MNP Class 3 Error Correction.
The TrailBlazer employs a Motorola 68000 and a Texas Instuments
TMS32010 digital signal processor to accomplish this performance.
Because of this substantial computer horsepower (about 7.5 MIPS),
the TrailBlazer is really a communications processor, rather than
a conventional modem.
The software defined architecture produces a flexible product platform
that allows broad feature development capabilities while allowing the
product's installed base to benefit from those developments by installing
upgrade EPROM sets.
All four protocols (Kermit, Xmodem/Ymodem, UUCP), V.22bis support, MNP at
low speeds, multiple releases to improve the interactive performance
(earlier TrailBlazers utilized only one baud rate), a multitude of
RS-232 behavior related features, leased line capabilities, remote
command processor access, echo suppressor compensation, increased
data rates, and a myriad of user requested features have found their
way into current production modems and are available to earlier
revisioned modems via the EPROM uprgrade kits.
PEP modems provide a full duplex serial interface to an attached computer,
however they employ a half duplex implementation on the telephone line.
Telebit refers to this half duplex technique as "Adaptive Duplex".
As the name implies, the ownership of the line (i.e. the ability
to transmit) adapts to the quantity of data available to send at
any single moment. Maximum efficiency is achieved by sending data
in a nonstop data stream at 19.2Kbps relying on serial interface
flow control to moderate the data flow into and out of the modem.
This allows the maximum amount of data to be available every time
a transmitting modem takes ownership of the line. In this way the
modem, not the DTE, controls the line turnarounds. The protocol
provides a ceiling at about 3k of sent data before a transmitting
modem must give up its turn and allow the other modem an opportunity
to send. A continuous 19.2Kbps data flow into the modem is required
to ensure that there is always 3k of data to send each time a
transmitting modem takes its turn. The serial interface speed must
exceed the telephone line speed, potentially 18,031 bps, or the maximum
efficiency of the modems can not be reached).
UUCP's "g" protocol behavior on dialup lines was a clear contradiction
of the desired behavior with the PEP protocol. "g" sends 3 small data
packets at time and then waits for the remote UUCP to ACK or NAK their
receipt. The resulting throughput when using UUCP and "g" with the
TrailBlazer was only a little better than a standard 1200 bps modem.
This was unacceptable.
What did we do about it?
The TrailBlazer can be configured to "spoof" the protocol by setting
a register (S111) to one of several values. The spoof can support four
different protocols: UUCP "g", Xmodem, Ymodem, and Kermit.
"Spoof" means to fool the various protocols into thinking that they
are getting their acknowledgment packets from the remote computer,
when in reality they are getting them from the modem.
All of these protocols are what are commonly referred to as
"send and wait" protocols. This type of protocol builds a packet
in computer A, sends it out through the modems, where it is received by
computer B. Next, computer B looks at the packet to determine whether
or not it arrived intact. If it did, it sends an ACK (acknowledgement)
packet back to computer A. If it did not arrive intact, it sends a NAK
(non-acknowledgement) packet. In either case, computer A can't send the
next packet out until it gets the ACK from the first packet. This is slow!
Since our modems are error-free between the modems, the only place data
could get "broken" is between the modems and their respective computers.
Let me draw the connection diagram below:
Ca <======> Ta <----------------> Tb <======> Cb
Ca = Computer A Cb = Computer B
Ta = Telebit Modem A Tb = Telebit Modem B
====== RS-232 Cable
------ Phone Line
When we are running our protocol support, we look at the packet coming
from Ca. Ta checks the packet for validity and sends the ACK or NAK.
Ca can begin building the next packet immediatly upon receipt
of Ta's ACK. This results in Ca building and sending packets as fast as it
can. Many packets are now forwarded to Tb. Tb now delivers the packets
to Cb, observing the rules of the protocol. Tb will deliver the next packet
or retransmit the previous packet based on the ACK or NAK received from Cb.
Cb ACKs and NAKs are then thrown away so as not to return to Ca.
Protocol support can be configured to run in parallel with data compression
enabled. The real world result of this is to increase protocol transfers
from 2-3 Kbps to 10-19.2 Kbps.
This covers most of the commonly asked questions about the TrailBlazer.
If any of the above information is unclear, or you have questions
regarding other aspects of modem technology or performance, send mail to:
======================================================================
Richard Siegel UUCP: {uunet,ames,hoptoad}!telebit!modems
Senior Systems Engineer ARPA: telebit!mod...@ames.ARPA
Telebit Corporation
======================================================================
Bill Mayhew
1. Both my Trailblazer's have General Instruments DSP chips. One
modem is about 8 months old with rev 3 firmware. The other is
about 3 months old with rev 4 firmware. I take it that the GI DSP
chip is a functional equivalent to the Texas Instruments chip?
2. The older modem has some SMD chips on a little daughter board;
the newer modem has an AMD "Worldchip". I take it these are then
strictly for DTMF generation and call progress detection?
3. Oh yes, here's another. What is the big square (Toshiba, I
think) chip in the newer telebit design doing?
Thanks for posting the tech summary.
--Bill
Jonathan Clark
he did the relevant bit of the Telebit firmware, but the answer may prove
to be of general interest.
Many of us have tweaked our uucico's to use a window of 7 outstanding
packets, rather than 3. Given this, does it make sense to have two Telebit
modes for the 'g'-protocol spoof (one for each window size); and iff it
does, are there any plans to implement this?
--
Jonathan Clark jonatha...@mtune.att.com, attmail!jonathan
Any affiliation is given for identification purposes only.
The Englishman never enjoys himself except for some noble purpose.
Peter Honeyman
window size doesn't affect trailblazer throughput -- a window size of 1
gives the same performance as 3 or 7.
in fact, the modem converts a request for a large window size into a
request for a window size of 3. it does this transparently, but you
can watch it happen with -x9 debugging on.
we considered knocking the window size down to 1 in all cases, as this
eliminates the windowing inside the spoof code, but we were unable to
assert unequivocally that all versions of uucp would work with a window
size of 1. (we tested against a long list of uucp versions, but there
are versions to which we didn't have access.) we were confident that 3
would work in all cases, so we stuck with that.
so to answer the question, no, you don't need multiple versions of
spoof code to accommodate window size variants, the modem takes care of
that (too!) for you.
peter
Carl S. Gutekunst
>window size doesn't affect trailblazer throughput -- a window size of 1
>gives the same performance as 3 or 7.
Peter and I have argued this one in private before -- and I still disagree.
I know the modem is perfectly capable of running flat out with window size 1.
But a lot of computers are not -- and in fact, window size 3 at 9600 or 19200
bps is too small. We have many connections where the throughput is obviously
constrained by the system's ability to get ack packets out; I think a bigger
window size would help immensely.
Of course, a lot of machines that can barely buffer 3 packets at 19200 are
going to gag on 7. No problem; they don't have to run a uucico with the window
size pushed up.
<csg>
Peter Honeyman
carl, i'd buy your argument if uucico's throughout the land knew how to
piggyback acks. it's admitted by the chesson spec, but i've never seen
a version that does it.
if you're not convinced, why not recompile uucico with a window size of
one and compare? i'm sure the results would be interesting.
peter
Jerry Aguirre
>In article <38...@umix.cc.umich.edu> ho...@citi.umich.edu (Peter Honeyman) writes:
>>window size doesn't affect trailblazer throughput -- a window size of 1
>>gives the same performance as 3 or 7.
>
>But a lot of computers are not -- and in fact, window size 3 at 9600 or 19200
>bps is too small. We have many connections where the throughput is obviously
>constrained by the system's ability to get ack packets out; I think a bigger
>window size would help immensely.
I have to agree. If the host were talking at 19200 and able to generate
acks reasonably fast then throughput shouldn't suffer. But I have to
run my interface at 9600 bps, to a heavily loaded slow CPU.
While it might be able to generate acks fast enough on average to keep
the line going it can't do so at any given instant. There are other
things like disks and other serial lines to service. Remember that the
acks are not being generated by the tty driver at interupt level. They
are being generated by a user process. It reduces overhead if the
process can process and ack several packets at each context switch.
The suggestion that full speed is possible with a window of 1 is
ludicrous. The modem would be able to send only 1 packet. It would
then have to wait for an ack before it could send another. At a minimum
that means 8 bytes of idle time for every 64 bytes received. The line
would be idle for 12% of the time. Any time to process the incomming
packet and generate the ACK would add to that.
If the connection from the modem to the computer has additional delay
then performance really suffers. By example consider dialing into a
packet switched network like tymnet or PC persuit. Before switching to
a window size of 7, I and others experienced terrible thruput on
networks like that. I also run UUCP over lines with a satellite delay.
Again, thruput is terrible without a window of 7.
3 packets * 64 char/packet * 10 bits/char = 1920 bits
1920 bits / 19200 bps = .1 second to send 3 packets.
If the system takes more than 100 ms. to return any ack then performance
suffers. (Actually it is 66 ms. because I can't begin generating an ack
until after the first packet is received.) A satellite circuit has 700
ms. of delay. Many packet switched networks have several hundred ms. of
round trip delay.
If the modem really negotiates the window size with the host then why
can't it use the value each host asks for? That way systems that can't
buffer 7 packets can leave their window at 3 and systems that need a
larger window can do so. (No, 3 is the magic number. Count ye not to
2, nor on to 4 ...... :-)
You are too locked into what the modems are doing internally and not to
the host interface. If I ask for a window of 7 then you should give me
a window of 7, I might have a good reason.
Jerry Aguirre
Peter Honeyman
if the wire is slower than the host, windowing is a clear win. but
here, the wire is faster than the host, usually a lot faster. the
modem immediately fills the window, whatever its size. thereafter, the
modem sees a window of one -- host acks, modem sends a packet to fill
the window.
your point about context switches is well taken -- it depends on the
scheduler's behavior when the host calls write(ack). you can probably
convince me that a window of two is worthwhile, but i don't see this
argument extending to anywhere near seven.
someone should run an experiment here. (i can't, because i don't have
a fast computer with a serial board.)
peter
William E. Davidsen Jr
| [...]
| The suggestion that full speed is possible with a window of 1 is
| ludicrous. The modem would be able to send only 1 packet. It would
| then have to wait for an ack before it could send another. At a minimum
| that means 8 bytes of idle time for every 64 bytes received. The line
| would be idle for 12% of the time. Any time to process the incomming
| packet and generate the ACK would add to that.
If the feed to the modem is at 19.2k, since the ack is generated at
the modem, and accepted at the modem, the two systems should be able to
drive the actual line at the maximum of 11-14k (depending on who's
figures you see).
I completely agree that this is not a desirable thing from the
standpoint of interrupt overhead.
--
bill davidsen (we...@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me