pete@octopus.UUCP (Pete Holzmann) (04/15/88)
A question and a couple of thoughts regarding the recent PC magazine review
of high speed modems, in which the Trailblazer got 4 cow patties, and V.32
modems got 4 gold nuggets.
The question: In their testing, V.32 modems generally seemed to be able to
transmit without error at any level of simulated noise, while the
Trailblazer fell apart at high noise levels. I know that in real
life, the Trailblazer actually handles noise amazingly well. Does
anybody out there have real-world experience either with V.32 on
bad lines, or (better) comparing V.32 and Trailblazers on the same
bad line? Enquiring minds (and managers) want to know! Is V.32 really
*that* good? No need for fallback *ever*? (PC mag tested with up to
19dB S/N worst case).
The thoughts: Since I know that the Trailblazer handles real-world noise
rather nicely, I've been pondering what it was about the PC mag
tests that could have made it look so bad. Came up with a couple
of thoughts:
- The trailblazer looks for noise-free areas in the frequency domain,
while other modems depend on noise-free areas in the time
domain (MNP sends lots of ever-shorter packets until a whole
packet can get through). If the PC mag noise-box simply adds
lots of *full spectrum* noise at random ever-more-frequent
time intervals, the trailblazer could have trouble, methinks.
Anybody know whether wide-spectrum noise is common? (The
results we're all getting with the Telebit would indicate
otherwise, but maybe somebody who Knows could speak up).
- From their test description, I surmise that they tested datarates
at various noise levels by starting a connection at one
level, then slowly turning up the noise while measuring
data throughput. The Trailblazer analyzes the noise level
only at the start of the call, then sticks with it unless/
until things get really bad, at which point it will retrain.
Again: anybody know which model more closely models the Real
World? On a single connection, are you likely to get a variety
of noise levels, or is it reasonably constant per connection?
- They never got better than 900 chars/sec out of the Telebit; the
same as any of the 9600 baud modems. I wonder if a PC/AT
can really handle full 19.2 data rates? On our 68000 box
here, we can certainly do better than that! The main
limiting factor I've seen is latency due to hard disk
accesses.
Basically, I'm trying to decide whether PC mag has found the Achilles heel
of the Trailblazer (and therefore people really SHOULD be going for V.32
modems in international/etc situations), or whether PC mag just ran a bunch
of tests that have little to do with reality.
Obviously, the part of their test that dealt with protocol-transfers was
completely out-to-lunch (they ignored the trailblazer protocol spoofing
because their test setup didn't handle it). Hmmm- that's another interesting
question:
- When performing protocol spoofing, the trailblazer gives local
ACKs to the sending computer. Is a 9600 baud protocol
transfer using trailblazers actually *faster* than a 9600
baud bare-wire (and/or V.32 full duplex) transfer? Seems like
it should be, since there's reduced ACK delay. Does anybody
Know?
Well, that's enough rambling.
Pete
--
OOO __| ___ Peter Holzmann, Octopus Enterprises
OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete
___| \_____ Phone: 408/996-7746caf@omen.UUCP (Chuck Forsberg WA7KGX) (04/16/88)
In article <187@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes:
: - They never got better than 900 chars/sec out of the Telebit; the
: same as any of the 9600 baud modems. I wonder if a PC/AT
: can really handle full 19.2 data rates? On our 68000 box
: here, we can certainly do better than that! The main
: limiting factor I've seen is latency due to hard disk
: accesses.
:
That depends on the software one is using. The TeleGodzilla bulletin
board runs Professional-YAM on a 4.77 mHz PC with an add-in hard disk
(equivalent to an XT). It can receive (with ZMODEM protocol) files from
a 386 Xenix system with 1890 cps throughput, and send to Xenix with 1520
cps throughput. An AT is much faster, but requires 16550A UARTS and
software that knows how to exploit them (DSZ, ZCOMM, Pro-YAM) to avoid
interrupt latency problems at the higher speeds.
TrailBlazer downloads from TeleGodzilla get 600-1400 cps throughput
depending on how many beavers are gnawing on the local loop, etc.
(TeleGodzilla has an old TrailBlazer, not TB Plus.)
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: CAFcsg@pyramid.pyramid.com (Carl S. Gutekunst) (04/18/88)
In article <187@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: >Does anybody out there have real-world experience either with V.32 on bad >lines, or (better) comparing V.32 and Trailblazers on the same bad line? I have not, although we (Pyramid) plans to very soon, and at least one of our customers has. We have two applications: SLIP and X.25 LAPB. For the former, we can use the stock asynchronous TrailBlazer+ and any of the new crop of V.32 asynch modems. For the latter, we're trying to convince Telebit that it would be a "good thing" for them to support LAPB. So far, the results with SLIP over the TB+ have been interesting, but not exciting. Telebit is considering a number of strategies for improving SLIP performance. The customer's application was cross-country dialup for low-volume nodes on a wide-area network. They developed their own protocols which allowed them to layer over asynch tty, X.25, or TCP/IP. Their *preliminary* observations (the package has not yet gone into production use) were that they were disappointed with V.32 on domestic AT&T phone lines. The TrailBlazer was somewhat slower, due to turnaround delays, but at least you got a connection 100% of the time. The V.32 modem often wouldn't connect. Didn't fall back, either; just wouldn't connect. (I don't know whose modem they used, but they cost $2500 each.) >If the PC mag noise-box simply adds lots of *full spectrum* noise at random >ever-more-frequent time intervals, the trailblazer could have trouble, >methinks. Bingo. All the magazine modem tests I have seen rely on gradual increases of broad-spectrum ("white") noise. The clear winner of the sheer gall award was a review in PC Magazine two years ago that compared the Microcom AX9624c against the DCA Fastlink. The reviewer *had* the capabaility to run bandwidth limiting tests. But when we ran them, the V.29 AX9624c simply refused to make a connection. So he DROPPED THE BANDWIDTH TESTS FROM THE RESULTS and relied entirely on the broad-spectrum noise tests, and pronouced that AX9624c as the better choice. My experience has been that the original TrailBlazer handles broad-spectrum noise very poorly. This was also reflected in its mediocre performance on Bell 212A emulation. The TB+ is better, but the DAMQAM encoding is inherently much less resistant to broad-spectrum noise. We notice this in international calling -- Chile is mostly plagued by bandwidth loss, while London is plagued by broad-spectrum noise. We talk great to Chile, poorly to London. (Although the 'Blazer talks to London much better than does a Bell 212 modem.) On the other hand, V.32 modems (and trellis coding, in particular) are very resistant to broad-spectrum noise. They get killed by bandwidth loss. Which is more common? Based on my experiences with V.29 versus the original TrailBlazer, I'd say bandwidth loss is *MUCH* more common. You can hear the difference if you dial a voice call: loss of bandwidth makes the voice sound hollow, distorted, and far away; broad-spectrum noise adds a whoosing sound, but does not change the timbre of the voice. What was interesting was a very recent experiment with using an alternative long distance carrier. The Trail- Blazer was an ideal choice for the line, since it does that elaborate spectrum analysis that can be retrieved after the call. I could hear the loss of band- width, the TrailBlazer could certainly measure it, and the throughput to uunet dropped from 1000cps to 600. So we moved a USR Courier 2400e to the same line. It could not get a connection *ANYWHERE*. Also, we discovered that 6MHz digitial PBX systems played hell on V.29 modems. I would expect V.32 to have some problems. The TrailBlazer got no measurable difference in throughput. > - They never got better than 900 chars/sec out of the Telebit; the > same as any of the 9600 baud modems. Foo. We get that much between here and uunet. We get 1250 between here and ames (a local call). 'g' protocol, of course. <csg>
csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/18/88)
In article <19903@pyramid.pyramid.com> I said: >Also, we discovered that 6MHz digital PBX systems played hell on V.29 modems. Of course, I meant 6KHz digital PBX. ^ <csg>
wcs@skep2.ATT.COM (Bill.Stewart.<ho95c>) (04/25/88)
In article <19903@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes:
:> - They never got better than 900 chars/sec out of the Telebit; the
:> same as any of the 9600 baud modems.
:Foo. We get that much between here and uunet. We get 1250 between here and
:ames (a local call). 'g' protocol, of course.
Telebit performance (using the older version, at least) depends
radically on the machine you're using. I ran a test from an HP 350 lab
computer here in New Jersey to several machines in California. I got
1300 cps talking to hoptoad (a Sun of some sort), but only 1000 cps
talking to telebit (?? a 386 box, I think??). I was also getting
1300cps talking across the lab to another HP 350.
PC magazine was probably running it on a 9600 baud line; I've noticed
radical performance increases with 19200, at least for UUCP. (They
only got 100 cps for Xmodem - I bet they never got the Xmodem flags set,
or used the wrong kind of Xmodem.)
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# skep2 is a local machine I'm trying to turn into a server. Please send
# mail to ho95c or ho95e instead. Thanks.