WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") (08/04/87)
This one has got me stumped, and I'd appreciate it if this
message was redirected to a more appropriate forum if there is one.
We have noticed this "noise" problem on and off for quite some
time and are now realizing that perhaps what we and our users are
seeing is not line noise but something else.
In general, when a user calls to complain about seeing "noise"
from a TAC connection, we naturally assume the problem is caused by
line noise in the phone circuit between the user and the TAC port
modem. However, it has turned out that we have not been asking the
right question in determining the noise characteristic. The question
is: are you seeing "noise" when there is supposed to be no activity on
the line, or are you seeing it as garbage only when the remote host is
sending a long string of characters. If the answer is yes to the
former, the problem is probably a "bad" circuit. However, if the
answer is yes to the latter, then we have a whole new problem, or so
it seems.
I've seen the latter problem only at 2400bps. Others have
reported the problem at 1200, and some even at 300. With the rumored
eventual upgrade to 9600bps dialup TAC access, I am concerned that
there may be an underlying basic TAC-to-modem interface problem that
needs to be found and fixed before higher speeds become commonly
available and useable.
The characteristic of this form of "noise" is that the first
several lines of expected output appear OK, then garbage (noise).
This is consistently repeatable. We have empirically ruled out
several possible causes, including real line noise, and noise caused
by level settings in the modems themselves. It seems one possibility
remains: that there is a "slight" speed mismatch between what the TAC
outputs and what the modem expects and bits eventually get shifted...
There is one further complication that makes things harder to
track: it appears that the TAC software *may* have been undergoing
"minor" changes during this time without the version number changing
in the TAC herald. Thus, it is somewhat difficult to pinpoint when
this problem started to occur relative to TAC version.
I suggest that followups to this message be made privately amongst
interested parties unless there is some general interest in this
subject on this list. The only reason for bringing this up here is
that I have several high level users wanting answers *now* and I can't
evade the queries for much longer...
--FrankWANCHO@SIMTEL20.ARPA ("Frank J. Wancho") (08/06/87)
Apparently some readers of my message about TAC "noise" inferred
that we had reported this bug and received no action. We have not yet
reported this problem, although we believe others elsewhere may have
reported something similar with no resolution.
My intent in sending that message was to try to gather some
hypotheses to present when I do report the problem to give the problem
more credibility and a higher likelihood of receiving attention and
maybe even getting fixed. After all, the "true" nature of the problem
is often easily misunderstood.
It was also an attempt to discover if anyone else has experienced
the same problem - TAC users are an individually isolated contigent of
users with no one to represent them and no forum to bring up their
problems, except, maybe NIC folks who mainly handle TAC Access card
problems and refer technical problems to the NOC. Most TAC users
aren't technical enough to push their statement of the problem past
the "well, it must be line noise" answer, and the problem is not
properly surfaced.
However, the readership of this forum, not necessarily the forum
itself, is, as hoped, quite technically knowledgeable. I immediately
received several detailed responses basically supporting my suspicion
that clock tolerances are the most likely culprit. In fact one
respondent was actually able to prove the point by using an old 300
bps modem with a clock heavily suspected of having drifted over the
years and observing the same "noise" characteristic as I described.
So, with apologies to BBN for not having made my message clear, I
will now go off and report the problem through conventional channels.
Thank you all for bearing with me while I interrupted your discussions
on the more esoteric aspects of TCP/IP.
--Frankhaverty@CCV.BBN.COM (08/06/87)
Frank -- from my experience, it would be worth looking at "stop bits" in addition to clock tolerances. If a receiver expects more stop bits than a sender sends, things tend to work when there is a non-continuous stream of characters, but get garbled when the line is running flat out - the first bit or two of the "next character" get eaten up as if they were stop bits for the current character. You can test this hypothesis by comparing the characters as received with those as sent, and seeing if bit-shifting would cause a match. Jack
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (08/07/87)
Ether that or someone has their terminal set to 7 data-bits and no parity. -Ron
ROODE@BIONET-20.ARPA (David Roode) (08/13/87)
The CompuServe Network added an option to their 'TAC' to vary the timing of bits or number of stop bits, apparently just to address the type of problem you hypothesize might be what Frank is seeing on TAC's. I believe it was just to send an extra stop bit. -------
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (08/18/87)
Yes, you can send an extra stop bit, and then expect not to receive two and things will work OK, but you can not reliably deal with 7-bit No parity (a 9 bit frame) when you are expecing 8 bit,no-parity or 7-bit,parity (10 bit frames).