Reports on Trailblazer modems (especially with 3B2 and IBM PCs)

Thu Mar 31 09:06:46 AEST 1988

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 at ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david at UKMA.BITNET
<----
<---- I don't have a Blue bone in my body!