robby@beattres.UUCP (Robby Kates) (03/30/88)
Hi folks! This is a question for everyone using Trailblazer modems. I am pushing to get some here, but because PC magazine gave them a bad review, I've been up against a brick wall. I am looking for reports from people using them as to how they found performance, and how much problem they've had with line noise. Particularly, I'm looking for reports on connections between 3B2 computers, and between 3B2 and an IBM PC/XT/AT or PS/2 computer doing terminal emulation. Most importantly, I'd love some reviews from people using them over long distance lines, or lines that are fairly noisy (regardless of machine type). Please help me out and mail me some reports from "the field". I've got the claims of the Telebit people, but they get dismissed out of hand as biased by the brass around here. Thanks much. -Robby P.S. I can also be reached as kat2@sphinx.uchicago.edu -- Robby Kates ...ihnp4!beattres!robby Beatrice Corporate Headquarters, Chicago "...and a lover who looks straaaaangly, like Time the Avenga..." -CH- #include <disclaimer.h> (312) 558-4028
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (03/31/88)
I don't think I ever posted this. It's a longish journal of the testing
I did with a couple of trailblazers which I'd had in for testing ...
(Various university and political delays have kept us from getting
our order out until a couple of weeks ago, sigh)
Mon Nov 23 19:46:12 EST 1987
I've been using it for only a few hours (i.e. <10) ... there is some
delay for echo, but not "several seconds". More like a half second
normally and sometimes not noticeable. Repainting the screen does take
one or two or three bursts. But it happens smoothly and quickly.
For reference ... the terminal is an Ampex 210 running at 19.2 kbaud.
The computer is a uVaxII running through DEC DHU-11's. The machine has
13 megs of memory and we're running MtXinu 4.3+NFS on it. The drives
are the 70 meg qd5? drives that DEC likes to sell on a uVaxII.
The modem generally claims 15kbaud effective xmit/rcv rates on the
phone lines. My roomate feels that the phone service in our area of
town is very bad ... we're in the student ghetto and it's not hard to
imagine that they'd put less emphasis to that area, plus it's an
"historic" neighborhood, with a few buildings that date back to the
Civil War days...
The point is, it runs well in the slightly adverse conditions to which
I've subjected it. I have some more tests in mind, like leaving the
extension off the hook and see what happens to the baud rate. etc
etc. I'll probably post a fuller report in a couple of weeks.
One bad note so far. This morning I transferred some files between
my Unix PC and the uVaxII and got some really bad transfer rates.
Down around 2kbaud whereas I was getting around 10kbaud transferring
files with the uunet machine. I dunno what was wrong there. Possibly
just a buggy uucp on my 3b1 or the fact that it can only do 9600 baud
out its' serial ports.
----------------------------------------------------------
Wed Nov 25 10:19:44 EST 1987
More testing ...
First, last night I was paying attention to delays and such and began
to notice that sort of behaviour. But it's not much of an annoyance,
possibly after I became accustomed to it ... for instance, right now
I'm using vi to edit this file. I'm having 1/2 to 1 1/2 second delays
on echo. Normally vi has some delay but not this bad. A minute ago I
was positioning the cursor to edit a word, and overshot badly.
Probably I have attuned myself to the normal delay, and am unused to
the delay that's active now and am missing things as a result. Last
night I was experiencing the same thing with editting command lines.
(If I remember correctly, the command lines were over on the PR1ME so
therefore I use ^H and it doesn't erase as I go ...)
Another result. I realized that the modem on this end wasn't going
into the UUCP protocol when using uucp to call ukma. That could easily
account for the 2kbaud throughput. Rewriting the L.sys entry to enable
the uucp mode caused the effective rate to go up to 8300 baud. Not bad
considering that it's a Unix PC and can only run its' serial lines at
9600 baud...
And finally, a *real*test*. I connected up and ran "rain". (BTW, rain
is real fun to watch at ~15kbaud from home! :-)). Anyway, picking up
the extension line didn't seem to phase the modem. i.e. rain kept on
running w/o problems. So I whistled. Still no pause. Whistling more
did cause some problems. Oh, by the way, I also have Alan Parson's
_Stereotomy_ playing on the speakers in here. It wouldn't hang up
though. This is treatment which would have caused any other modem I've
ever seen to freak out and hang up. I pulled out my Casio SK-1 (a toy
keyboard which does some limited synthesis and limited sound
sampling). A little bit of playing in the piano mode would cause small
canniptions in the modem. But it would recover and keep on going
eventually. Finally, a LOT of playing did make it freak out and hang
up. I don't know if this was absolutely necessary, but when I called
back the modem wouldn't work right. So I called up on a different line
and killed the getty then called back to the telebit, and it worked
fine. Possibly when I called the first time my processes hadn't gotten
their hangup and so forth and the modem wasn't all the way reset.
Possibly not.
Some usage notes. I have the modems on both ends configured to work at
a fixed baud rate. If I want to call some 1200 baud place, I have to
say "ats50=2" to the modem (i.e. when you call up, answer to the 1200
baud tones). This causes the trailblazer to sync at 1200 baud and
continue talking to the serial port at 19200. It handles all the
buffering internally. I haven't looked inside to see how much memory
it has, and haven't given it a situation where it would possibly run
out of buffer. (i.e. I haven't called up the vax at 1200 baud on that
trailblazer ... since it's at 19200 ...)
The trailblazer on the Vax is set with ats50=0 so that when you call up
it will cycle through all the tones. (ats92 and ats90 are both
important here also). When I place calls to uunet I have to tell it
"ats50=255" so that when the uunet modem answers, they'll sync with the
PEP tones. I also have it configured with ats52=2 so that the values
of the s register's'll reset themselves after a call, allowing me to
muck with values for a UUCP call, but then have it revert to the proper
mode for dialup use afterward.
The point of the last couple paragraphs is that there are a lot of
conveniences in this modem. For instance ... a real big convenience
for this playing with it to configure it has been the fact that, while
connected and at this modem's command mode, I can have the other modem
perform commands with "at%command". NOTE that with some commands you
put the remote modem into it's command level and you have to put it
BACK into it's online mode before connecting back ... i.e. "at%o"
before "ato".
And the reference card! That's been a lifesaver in that, now after
using this modem since last friday, all I need is a prodding of the
memory for which register to set. The real manual was very helpful
and good to read, but now I don't need it so badly, and I was about
to say I couldn't find it even, but it was under the reference card.
There has been one confusing thing so far. That is, how to set flow
control. I don't even know if the boards on the uVax can support
proper flow control or not. I know that this terminal can possibly
support the right kind of flow control, but why bother ... it can
also keep up at real 19200 baud. But flow control would be important
for later if I wanted to support 1200/2400 baud in and out of the modem.
Something which occurs to me but I haven't checked up on. The hardware
and firmware in this guy must be very well integrated. I say this
because there isn't a second set of chips inside to run the
300/1200/2400 speeds. This isn't very surprising because to be able to
control the phone line as they do they'd have to have put in some very
exacting amounts of control. (re-write that sentence later). The important
thought about this is that, with this exacting control, they could possibly
put different firmware into the modem and suddenly be able to do some
other protocol in addition to the current ones. For instance, if they
aren't able to establish a strong market niche by offering such a
neat fancy modem, not very many people will have these modems. Their
customers will be stuck holding onto a very expensive paper-wieght.
But possibly by just swapping out ROM's their customers will be able
to talk whatever protocol becomes the standard for 9600 baud, but
also be able to continue talking the old protocols.
I would like to know how much CPU bandwidth is left. That 68010 in
there must be one busy sucker, he's keeping track of about 100 channels
of information flow, retuning each one all the time, doing error
correction on each channel, and so forth. He must be real busy... but
HOW busy?
I would also like to know how much ROM is being used against what can
be used.
--
<---- 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!wtm@neoucom.UUCP (Bill Mayhew) (04/03/88)
Arrrrrrrrrgh! I think somebody ought to fire Marks and Stone (the authors of the PC Mag article). I don't know what sort ofline impairment tests they did, but they must have been very severe to make the Trailblazer have a poor showing. I have done such things as shout into the receiver or dial DTMF tones while my trailblazer is doing a transfer and it never loses its connection. If one makes enough racket on the line, the Trailblazer will detect that it has received several bad packets in a row, then stop and go through the training sequence over again. The trailblazer is the only modem is the only unit I know that has special firmware supprot for xmodem, kermit and UUCP g protocol. With the built in firware "spoofing" algorithms, I routinely get data transfer rates on my home computer that are equal to the transfer rates between our Vax and the computer in my office at work that has a dedicated line. (Typically 880 char/sec when the Vax is lightly loaded, talking on a 9600 bps port). The trailblazer also provides sterling performance at 1200 and 2400 bps due to its internal adaptive line equalizer. I can not get a hayes smartmodem, for instance, to connect dialing from my home to my office. The Trailblazer has no problem. (There is some sort of sharp high frequency roll-off on the line that gives modems without equalizers fits.) The only thing bad I can say is that there appear to have been bugs in the Telebit version 3.xx firmware that made MNP error correction not work when other brand modems called into a Trailblazer. This seems to have been fixed in 4.xx firmware, as users routinely dial in with MNP modems into my 3b1 at home. I really wonder if the guys at PC Mag actually tested the Trailblazer, of if they just read the glossy press release and wrote something they thought would sound good. If you want to sway your bosses to buy a Trailblazer, show them an article in Unix World by John Blair -- I think it was in the January '88 issue, but I am not positive. About the only modem I know of that does as well at rejecting line impairments at 1200 baud is the 1200 baud internal modem that IBM sells for its PS/2 microchannel products. (By the way, IBM's modem is manufactured by Racal-Vadic, in case you were wondering.) --Bill
james@bigtex.uucp (James Van Artsdalen) (04/05/88)
IN article <1072@neoucom.UUCP>, wtm@neoucom.UUCP (Bill Mayhew) wrote: > I really wonder if the guys at PC Mag actually tested the > Trailblazer, of if they just read the glossy press release and > wrote something they thought would sound good. More likely, Telebit simply didn't buy enough advertising in the issue the review was in. Magazine reviews in general are of dubious value. InfoWorld did a review of several 80386 machines last fall, including the 16MHz *static* RAM, no wait state, no refresh, PCs Ltd 386. They rated it in CPU performance slower than three or four dynamic RAM designs. I never figured that out. To be fair, there was no evidence they were favoring heavy advertisers there. -- James R. Van Artsdalen jva@astro.as.utexas.edu "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) (04/06/88)
In article <1451@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: | [...] | More likely, Telebit simply didn't buy enough advertising in the issue the | review was in. If their results don't match your results (or expectations) they must be slanting the tests? This is typical sour grapes. I think some echnical questions are totally valid, if you have them, but your statement above belongs in rec.flame. | | Magazine reviews in general are of dubious value. InfoWorld did a review | of several 80386 machines last fall, including the 16MHz *static* RAM, Everyone has to decide what parts of the test applies to his/her own situation. If I need a modem for local connections I want Hayes compatibility, hardware reliability, and price. If I need to make long distance calls through a rural phone system I will be more interested in noise rejection. To the extent that the testing procedures are not always well enough defined to clarify the results, I agree that some tests shed little illumination. As to the speed of static vs. dynamic RAM 386s, while I would not claim that the tests were representative, I would expect the results reported to be replicable. Many of the machines advertizing "static RAM" are really using "column static RAM," which does in fact generate wait states, depending on memory usage. My experience is that reviews and tests are useful for eliminating hardware or software which is obviously unsuitable, leaving time for better evaluation of the remaining units. I also feel that if five tests indicate that unit A is better than B in some areas, that it almost always is true. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
tankus@hsi.UUCP (Ed Tankus) (04/07/88)
Maybe it behooves us all to not only question apparent discrepancies in product
performance reviews but to request the test configurations/conditions and the
data input/output.
It would be most helpful to those who must make real-world decisions based
in part or in whole on product reviews to have this kind of kind of information
so that test results may be replicated. I think PC MAG/Tech Journal would
be providing a tremendous service if we could simply circle a reader service
number to request this info. I believe this info is available from consumer
product test labs. Why not PC MAG/Tech labs??
A letter to the editor of each of these magazines expressing concern over
the test results and your desire for the information that lead to the results
may well get the ball rolling.
Cheers!
-- Ed.
Net : {uunet,ihnp4,noao,yale}!hsi!tankus
Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511
Bell : (203) 562-2101