I have been evaluating a new Trailblazer packet-ensemble modem made by Telebit
for possible use to connect IP hosts together via ordinary dial-up lines. This
interesting modem packetizes serial-asynchronous data on multiple carriers and
is theoretically capable of speeds to 14 Kbps. It operates in buffered,
half-duplex mode with error control by retransmission. I connected a pair of
Trailblazers between two fuzzballs in the same calling area operating with the
SLIP protocol at 4800 bps. For comparison a leased line operating with
conventional full-duplex, synchronous modems at 4800 bps was also available
between these machines. This is a short note describing the results of delay
and throughput tests.
The tests used ICMP Echo/Echo Reply messages with lengths randomly distributed
in the range 40-256 octets and were conducted in the same manner as described
in RFC-889. Each test accumulated 512 samples, where a sample consisted of one
ICMP Echo/Echo Reply volley across the link with no other traffic on the link.
The samples were then displayed on a bitmap display as a scatter diagram of
length versus delay and saved in a file (telbit.bit on udel2.udel.edu in Sun
format if you're interested). The linear regression line was then computed to
determine the intrinsic delay and throughput as a function of packet length.
>From the scatter diagram it is apparent that the Trailblazer packetizing
mechanism is multi-modal, in that different packetization algorithms are used
for the shorter packets and for the longer ones. By trial and error it was
discovered that the boundary between the two lies at about 125 octets, so
separate regression lines were then computed for each region. The (one-way)
results are shown below along with the results for the conventional 4800-bps
Trailblazer 4800-bps modem
40-125 125-256 40-125 125-256
min delay (ms) 756 1093 103 247
max delay (ms) 1084 1388 244 467
slope (bps) 2075 3551 4802 4767
Obviously, the Trailblazer performance doesn't look too impressive compared to
the 4800-bps modem when both are operated at the same interface speed. One
reason for this is that the Trailblazer packetizes data internally upon
submission and depacketizes it before delivery. Unfortunately, the particular
fuzzball interfaces used here are simple character-at-a-time devices that do
not work reliably above 4800 bps.
If the interface speeds could be increased at both ends of the link without
limit, the Trailblazer delays could in principle approach values given by
subtracting twice the delays in the fourth column from those in the second and
third columns of the table. This leaves about 500 ms to be accounted for by
the Trailblazer packetization and transmission protocols, including the
turnaround and resynchronization procedures necessary for half-duplex
operation. Not bad, but not thrilling either.
Inspection of the scatter diagram suggests the 3551-bps slope for the
Trailblazer may be characteristic beyond the 256-octet limit of the
measurements. Above this value; however, the modem begins to flow-control the
source, at least in the test configuration, where the telephone line is only
about three miles long. The Trailblazer line speed can be estimated as
follows: of the (1388-1093) = 295 ms to transmit a (256-125) = 131-octet
message, (467-247) = 220 ms are consumed in the interface, so that 75 ms
represents the time required for transmission. Therefore the Trailblazers are
humping data at 131*8/.075 = 13973 bps, which could be predicted on the
assumption of good local line quality.
I conclude the peformance of the Trailblazer, while potentially brilliant,
is badly eroded in applications where the data already are packetized. This
would seem a shame, considering the thunderous horsepower of the modem
circuitry (M68000, TMS3020, oodles of memory), and could be easily remedied
by the inclusion of a parallel port and appropriate handshaking protocol.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:00 GMT