W8SDZ@SIMTEL20.ARPA (Keith Petersen) (10/17/87)
The Northern Telecom DMS100 digital switch being installed in some ESS
central offices may be the cause of spurious "}" on 1200 baud modem
connections.
Illinois Bell recently found that one particular type of board in the
DMS100 frames were the source of the problem. They found that about
1/3rd of the boards of this type were defective! They have sent out a
nation-wide alert to all Bell operating companies describing the
problem and how to determine which boards in the frame are bad.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)gnu@hoptoad.uucp (John Gilmore) (10/21/87)
I have also seen these -- typically as "}~" happening once a second or so --
on hoptoad's modem lines. It seemed to occur with high frequency to certain
exchanges -- Pacifica and the Berkeley campus.
Last time this question made the rounds, Marnix van Ammers of Pacific
Bell spoke up, and we corresponded (edited down and reproduced below).
I'll see if he has any further information this time around.
My brief understanding of the problem is that the central offices are
digitizing your modem data, and if this digital data stream gets out of
sync in transit from one central office to another, the audio signal
reconstructed on the other end gets a brief phase shift. The modems
encode bits as different phase shifts, so this produces a bit where no
bit has gone before :-).
John
Path: ptsfa!pttesac!vanam
From: vanam@pttesac.UUCP (Marnix van Ammers)
Newsgroups: comp.dcom.modems
Subject: Re: An interesting modem problem
Message-ID: <334@pttesac.UUCP>
Date: 14 Nov 86 17:19:41 GMT
Organization: Pacific*Bell ESAC, San Francisco
The "}~r" problems on 212A type modems is due to time division
multiplexing on telephone company trunks. It is not the fault
of the modem. It is the fault of the digital carrier equipment.
--
Marnix A. van\ Ammers Work: (415) 545-8334
Home: (707) 644-9781 CEO: MAVANAMMERS:UNIX
{ihnp4|ptsfa}!pttesac!vanam CIS: 70027,70
From: gnu (John Gilmore)
Thanks for your answer on the }~ problems. I had heard that it was
due to loss of sync between central offices in the digitized 56KB
data stream. Is this true? It sounded like your explanation and
this one could be the same.
From: ptsfa!pttesac!vanam
I was frustrated by the }~ problems myself many years ago. It takes
a lot to get it fixed. But when it's as bad as once every few seconds,
they will fix it if they can find it. The trouble is that the people
who test the trunks cannot (as I recall) detect sync troubles. They
can detect distortion, loss, echo, and maybe a few other things. Also
the 611 repair people are almost like robots (not their fault, just the
way they are trained) and they usually don't pass on the trouble reports
with the kind of detail required.
...
What you said about 56K baud facilities may be true too. Any kind
of loss of sync on digital facilities will cause the }~ problem.
But I believe that most of the troubles are caused by T carrier
facilities (1.5 Megabaud PCM) because apparently one or more
models of T carrier equipment do not automatically detect this
trouble. In these facilities, there are only routine transmission
tests done, and they only detect deterioration in voice sound quality.
It's been about 4 years since I researched this subject (not as part
of my job), so things may have changed some.
From: gnu (John Gilmore)
It sounds like if it's true that the test people cannot detect lost
sync on a digital trunk, this is a major hole in the repair capability.
Do people in upper management at PacTel know about this?
From: ptsfa!pttesac!vanam
This trouble has bugged me enough in the past that I wouldn't
mind finding out just what the trouble is with isolating and
repairing it. Last I heard was through several mouths. As I
recall, the bottom line was that some of that equipment was
too expensive to upgrade, especially when less than 1% of the
traffic was affected.
--
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@toad.com