From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: 5ESS Audio Quality
Date: 18 Nov 91 22:42:09 GMT
Organization: Digital Equipment Corp., Littleton MA USA

In article <telecom11.908.5@eecs.nwu.edu>, u1906ad@UNX.UCC.OKSTATE.EDU
writes ...

> I am sure glad to hear several people mentioning the problem of clock
> synchronization when talking about line noise.  We have an Ericssen
> MD110 PBX connected to trunks leading to a DMS100 Southwestern Bell
> switch via a digital interface of which I have no practical working
> knowledge.  We do, however have the strangest problem.  Sometimes,
> when calling in on any data line using 1200 or 2400 baud, we get a
> connection which sounds perfectly normal to the ear, but produces a
> rhythmic pattern of garbage characters which march across the 
> screen....

Okay, go to your telephone services people and lay the law out to
them:

TIMING ON A PBX MUST BE SLAVE TO THE CENTRAL OFFICE!

A digital PBX has its own low-accuracy crystal oscillators.  The
public network, on the other hand, is synchronized to a Stratum 1
Cesium clock, which means that it won't slip more than once every 36
days if linked, free-running, to another Stratum 1 (10^-11 accuracy).

The MD-110 should derive all of its own timing from the digital CO
line!  Otherwise you WILL get clock slips, causing } on modems.  In
Europe, where telcos don't give customers so much freedom, it's
usually a requirement.  In America, it's simply the way things work;
telco can't force you to do it right, but it only works right if you
do it right!


Fred R. Goldstein   goldstein@carafe.enet.dec.com 
                 or goldstein@delni.enet.dec.com
                    voice:  +1 508 486 7388 

Newsgroups: comp.dcom.telecom.tech
Subject: Re: Bad trunks handle voice, no data
From: floyd@tanana.polarnet.com (Floyd Davidson)
Date: 26 Nov 97 09:54:14 GMT

<wdg@|NoSpam|hal-pc.org> wrote:
>Here's some more info on the Houston (Southworstern Hell) modem problem.
>
>When the client modem encounters one of the mal-provisioned interoffice
>routes, the measured bandwidth, level and SNR is sufficient to easily
>support a 3429 symbol rate (required for 33.6k bps to function) yet the
>modems train and retrain and retrain during initial link negotiations and
>finally settle on a 2400 symbol rate (2400 symbols per second) with a 1600
>Hz center carrier frequency which will only encode a maximum of 21.6k bps.
>In spite of gobs of bandwidth, the modems find that only 400-2800 Hz is
>usable for spectral energy. By contrast, over a "good" route the modems
>will quickly negotiate a 3429 symbol rate with a 1959 Hz carrier (spectral
>energy in 244-3674 Hz).  It's as if there is tons of group delay over the
>bad path and so the modem pulls in its horns to minimize the effect. But
>these are DIGITAL interoffice trunks and group delay shouldn't exist.
>
>So far the common denominator in all the subscribers experiencing trouble
>is Houston's National office, HSTNTXNADSO. It's a 5E supposedly at 5E.10
>generic.  ANALOG modem calls that originate externally but terminate in
>National DSO are the ones experiencing the problem.
>
>And Southwestern Bell just hasn't a clue.

Stepping back to 2400 bps doesn't mean necessarily that it only found
400-2800 Hz usable.  There are other impairments that are probably more
likely.

Hmmm...  You can test for controlled clock slips easier than the telco
can, and that still sounds like the most likely problem.

Set up a modem for 2400 bps (v.22bis ??) with *no* error
correction.  If you have an old "2400 baud" modem around, that
makes it easy, but most v.34 modems can be configured to reject
everything else during setup.  It might take some heavy reading
in the modem's manual to figure out how.

With 2400bps and no error correction you will be able to see
every bit of garbled data on a connection with a modem program
and terminal emulator (don't make a PPP or SLIP connection
because you can't see the errors).  If a T1 system has clock
sync problems there will be an approximately 45 degree phase hit
every time the T1 re-adjusts to match the correct speed.  That
is not usually enough of a hit to bother 1200 bps modems, and it
has absolutely no effect on an old 300 baud modem, but the
effect at 2400 bps is predictable.  Since the phase hit is
likely to be almost exactly the same every time, the garble will
likely have repeating characteristics.  Here is an actual
example, saved just for demonstrations like this, of the type of
pattern you are most likely to see:

  Local> {{{r{{{{m{xD{{rw3{{r{{{m{t({{xD{{{{v{{{t(t^O5rw3{{v:{{
  Xyplex -701- Command syntax error

Note the "{{{" strings, but also there are "{r", "{x", "w3", and
several other patterns too.  The most commonly seen pattern is a
string of "{" characters, but I've seen instances where that
character never showed up at all.  In one case about every five
minutes there would be a single ' character, and that was all.

The important part is repeating patterns, of any kind.  If you
see them, the cause is "controlled clock slips", which you can
then persistently insist to the telco are the cause.  (If that
is what you see, and they give you the run around, feel free to
send me email and we can work together on how to enlighten them.)

I did once see an instance where the above type of test was not
showing repeating patterns, but on a very regular basis there
would be a blast of about 30-300 garbled characters.  Sometimes
it was happening so fast that even reading a prompt from the
distant end was impossible.  It was also a one way phenomenon.
That turned out to be a manufacturers defect in some very old
channel cards for NEC channel banks.  NEC said their tests
indicated no out of specification parameters, but changed the
ROM chips to the latest firmware anyway, and the problem was
cured.  We did a system wide check of all similar cards to find
those with older firmware.

  Floyd



--
Floyd L. Davidson   <floyd@tanana.polarnet.com>   Salcha, Alaska

Newsgroups: comp.dcom.telecom.tech
Subject: Re: Bad trunks handle voice, no data
From: floyd@tanana.polarnet.com (Floyd Davidson)
Date: 28 Nov 97 12:41:04 GMT

In article <347EF87D.1616@btmaa.bel.alcatel.be>,
Jan Ceuleers  <ceuleerj@btmaa.bel.alcatel.be> wrote:
>Jan Ceuleers wrote:
>
>> I can't remember what V.22 (1200 bit/s) does (and I can't get to the
>> spec right now), but I seem to remember that the points on its eye
>> diagram are 120 degrees apart, so that a clock slip still won't
>> influence the receiver.
>
>Actually, the points in the eye diagram are only 90 degrees apart. At
>2400 Hz (the highest carrier frequency used by V.22), a clock slip
>corresponds with 108 degrees, so this would certainly lead to a symbol
>error. Still, if clock slips don't occur too frequently the higher
>layers will probably be able to maintain the connection.
>
>Jan

The significant part is that with v.22 at 1200 bps controlled
clock slips will not cause errors, and at 2400 bps there will be
errors.  Not all 2400 bps modems (e.g. older ones) have error
correction, but virtually all newer modems do, so it is
important to point out that error correction must be turned off
to make observations, and it must be a 2400 bps connection.

One other item which might be noteworthy, is that not all DS-1
interface equipment is built with a full frame buffer to allow
controlled clock slips, and such equipment does not adjust to
clocking drift by "slipping" a frame.  Instead when its small
buffer it has overruns, it just drops frame sync and re-acquires
it.  That is called an "uncontrolled clock slip", and causes a
total signal loss for some arbitrary amount of time until frame
sync restored. It generally will cause any modem to have a
serious problem trying to do error correction!  Most modems lock
up and drop the connection.

  Floyd

--
Floyd L. Davidson   <floyd@tanana.polarnet.com>   Salcha, Alaska

From: floyd@ptialaska.net (Floyd Davidson)
Newsgroups: comp.dcom.modems
Subject: Re: Testing equipment for POT line quality
Date: 11 Oct 1999 10:13:07 GMT

news <tsaim@mft.com> wrote:

>In my case, all the customers that called w/ this specific
>CO's exchange number suddently started to get slow speed
>connection. Regardless they used X2/ V90, or Kflex V90 or even
>V34 33.6K modem. All run very slow. Like below 14K.   On our

With a proper "voice grade" line, you should be able to get
at least 14.4Kbps connections (actually you will almost
always get 16.8K or better), and not being able to achieve
that is indeed an indication that there might be telco related
problems involved.

>end , our modem is 3COM TCH, w/ T1/PRI lines that customers
>was called in.  Looked into the modem statics on our end, we
>found there were more "RESENT" blocks than then "SENT" block.
>That tells why customers perceived the SLOWness.
>
>Actually, I thought the problem lies in the sw programming
>between the originated CO and our carrier's CO which
>happended to be 2 different carriers. That makes the
>whole trouble shooting much more difficult.
>
>Many possible could have such cause. A simple one
>like , one of the trunk/tandem on the path happend to
>programed as AMI frame format instead of B8ZS or
>timing/clocking issues.  But who , where and what, is
>to be determined.

Unfortunately, there is no modem and no customer usable test
equipment which will allow diagnosis of those types of problems.
Issues like AMI/B8ZS encoding require looking directly at the T1
carrier signal, and cannot be determined by looking at a signal
that has passed through such a T1 facility.  (Actually, a
v.90 modem, because it does have direct access to one end
of a T1 facility, could do that.  But they don't.)

The same is true of timing/clocking issues, although in that
case there are ways to determine some types of problems.

If what is called an "uncontrolled clock slip" occurs, the T1
carrier will suffer from a "Loss of Frame Sync", and it will
take from a many milliseconds to as much as 1 second for it to
recover.  When that happens there will be a most _obnoxious_
"schkicct" sound produced on the line, which will be very
audible to the human ear, and which will probably lock up a
modem and drop the connection entirely.

If that is the problem you are experiencing, you will likely
hear that noise while you talk to the customer on the voice line
(or he will hear it, as this is going to be in one direction
only).

A second timing problem can be detected with a modem.  You can
set the modem to 2400 bits per second, with no error correction,
make a connection, and watch for garble of a particular nature.
Note that it must be 2400 bps, as at 1200 bps this problem will
usually not cause any garble at all!  You _must_ have error
correction disabled, or the modem will deliver only good data to
your screen.  If you have that, and you see garble that looks
like this (a real example),

Local> {{{r{{{{m{xD{{rw3{{r{{{m{t({{xD{{{{v{{{t(t^O5rw3{{v:{{
Xyplex -701- Command syntax error

Then there is a digital carrier system which is suffering from
"controlled clock slips".  Note that "{{" is a common pattern.
But the key is _repeating_ patterns of any kind, because "noise"
normally is never the same twice, and if it is then it has to do
with timing.  In the above example there are several repeating
patterns: "{m", "xD", "rw", "w3", and so on.  I've seen one
unusual case where the pattern was a single ' that showed up
about once every ten seconds.

If you see a pattern like that, report the problem to the
telephone company, and be insistant that what you see is an
indication which can _only_ be caused by "controlled clock
slips".  (The effect is caused by a huge phase jump taken every
time one of these clock slips occurs.  The carrier system either
retransmits a 'frame', meaning a single byte of data for your
circuit, or it drops one frame.  In one case the phase of your
modem signal jumps back, and in the other it jumps ahead.  Since
2400 bps modems are very sensitive to phase shifts, it shows up
as described.)

>So with a proper testing equipment for line testing.
>I can have a chance to bring up this kind of issues
>to the carrier's attention and so they could think
>this is a real serious issue not just some one
>did not configure their modem properly.

Unfortunately, with the exceptions mentions, there are no
definitive diagnostics you can do.  The profile that modems such
as the USR Courier provide are very helpful, and I personally
would say that having one configured as Alan Fowler was so kind
as to describe would be very useful.  One tech support box
could have that modem and it could be switched to some specific
line manually whenever needed for testing.  Let the customer
dial it up with a regular modem program or a PPP connection, and
then send him a few minutes worth of data.  Then review the
modem diagnostics, which you might want to be able to print out
for faxing to the telco as verification of the problems being
experienced.

>And finally,  I heard someone mentioned about
>this modem line tester "MLT560" by motro tel. corp.
>(I have nothing to do w/ them at all) , does anyone
>know can such device do what I am looking for ?

I'm not very familiar with the kinds of line testing equipment
that Local Exchange Carriers use (Steve Uhrig probably can
answer that one better than anyone).  I will say that because of
the need to test the _connection_ rather than just the
customer's line, there is almost no chance that any kind of
useful test can be done on premises using anything other than a
modem.

  Floyd

--
Floyd L. Davidson                          floyd@barrow.com
Ukpeagvik (Barrow, Alaska)

From: floyd@tanana.polarnet.com (Floyd Davidson)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech,comp.dcom.modems
Subject: Re: Phone line woes
Date: 24 Oct 1998 04:41:50 GMT

Let me summarize the significant symptoms being described here,
and then I'll tie it all together.

Dan Lanciani <ddl@danlan.*com> wrote:
>schuster_@at_panix_.dot_com (Mike "NO UCE" Schuster) writes:
>
>[...]
>|       Suddenly I'm getting disconnects. Especially (but not
>| exclusively) from my ISP - dialing pretty much anywhere off the island.
>| On a modem with alphanumeric display, I get connected with excellent
>| SNR and carrier speed, only to have it suddenly and randomly (could be 5
>| minutes ... could be 50) degrade with the modem trying valiantly (but

The line is normally good, and goes bad at random intervals...

>| unsuccessfully) to retrain. Using this line for voice conversations, I am
>| unable to hear audible evidence of periodic line impairments.

The impairment is inaudible to your ear...

If I remember right you also mentioned that 2400 bps connects did
not get dropped, and anything faster would be disconnected.


On to the second description:

>I had a problem like this a few years ago.  Any call outside of my local
>CO was affected.  The particularly interesting thing about the problem was
>that it occurred only between about 11PM and 7AM.  Extensive testing (by

Basically it happened only during the minimum use hours, which
would be a time when the first choice trunk group would always
be available.  At other times you might use different equipment
with every call and see that particular facility only rarely.

>me) revealed that the audio path from my end to the remote phone was being
>muted at seemingly random intervals (seconds to minutes) for seemingly
>random periods (milliseconds to ~2 seconds).  There was absolutely no audible
>(from my end, that is) indication that anything was happening.  Moreover,
>the muting as (not :) heard from the other end was completely clean.  No
>clicks or pops or anything.  People to whom I was speaking thought I was
>actually dropping words from the middle of sentences.

Entirely restricted to one direction, with up to 2 second drop outs.

>I taped two calls from different lines in my house to completely different
>locations outside of the local CO.  On comparison, I found that the muted
>sections came at the same times (and had the same durations) on both tapes.

This indicates that a group of trunks, not just an individual
one, is being affected.

>One "expert" explained that a bad connection on one wire of the pair would
>cause the effect of muting audio in one direction.  At that point I realized
>that there was no chance of my communicating with anybody who could understand
>(let alone fix) the problem and I went to the public utilities commission.

This indicates you are a pretty fair judge of bullshit artists...  ;-)

>Fortunately, the PUC/DPU was quite impressed with my detailed log of 9 months
>of trying to get Nynex to listen.  The problem was corrected within 48 hours.
>Unfortunately, nobody (including the Nynex relations person who called to make
>sure I was happy) could ever tell me exactly what was wrong or what was fixed.
>Several months later when the problem came back (but only for a few days), the
>Nynex relations person (along with his entire department) no longer existed
>and had no "forwarding" department.

This last case, described by Don, is fairly obvious.  Drop outs
of that length, one way interruptions and affecting more than
one trunk at a time all indicate you were using a T1 that was
suffering from Loss of Frame hits.  It could be either a bad
timing circuit or it could be what are known as "uncontrolled
clock slips", which are a way of recovering from time
synchronization differences on equipment that does not have at
least a 2 frame input buffer.  What it amounts to is either a
buffer overrun or underrun is handled by dropping frame sync an
re-acquiring it.  During the loss of frame period the distant
end will hear nothing, and normally it would last no longer than
a little more than a second.

Mike Shuster's problem is probably caused by what are known as
"controlled clock slips".  In this case the input buffer of a T1
facility is large enough to hold 2 complete frames and when an
overrun happens they just drop an entire frame to bring the
input and output back into sync, while with an underrun it will
just retransmit the last frame twice while the input catches up.
In either case it will cause a massive phase hit, but human ears
can't hear phase shifts that will send modems completely into
orbit!  Note also that the typical "little computer test set"
that a telco repair person uses does not test for phase hits.
And in many cases there really isn't anything that will flag it
for him if he doesn't realize that it is something to check.

But, any modem that can be configured for 2400 bps with no
error correction can test it better than the telco!  Here is
an example of what can be expected to show up:

Local> {{{r{{{{m{xD{{rw3{{r{{{m{t({{xD{{{{v{{{t(t^O5rw3{{v:{{
Xyplex -701- Command syntax error

That was saved several years ago as an example to demonstrate,
and it has been posted here a few dozen times!  The significant
things to note are the repeated patterns.  The most common
pattern seen is "{{{", but there are several others in this
example: {r, w3, {xD, and so on.  I saw one where what happened
was a single quote character was printed each time.

Be careful to NOT look at a PPP initiation exchange though,
because it looks almost the same!

If you can set up for 2400 bps (it will not show up with a 1200
bps connection) that has no error correction turned on, and you
see that kind of pattern you can tell the telco that you are
*certain* it is caused by "controlled clock slips" on a T1
facility.  There is no other cause.  And if they don't fix it
immediately, call them back every day for a update on the
progress...  which will cause them to want it fixed just to get
rid you your calls!

  Floyd

--
Floyd L. Davidson                                floyd@ptialaska.net
Ukpeagvik (Barrow, Alaska)

From: floyd@tanana.polarnet.com (Floyd Davidson)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech,comp.dcom.modems
Subject: Re: Phone line woes
Date: 26 Oct 1998 19:19:24 GMT

Mike "NO UCE" Schuster <schuster_@at_panix_.dot_com> wrote:

>I have a shell account here, so setting up a text based session is no big
>deal. Over the weekend I called at different times of the day using
>V.22bis 2400 bps with no error control. Some sessions lasted as long as an
>hour, either doing interactive work or sitting at the shell prompt waiting
>for repetitive extraneous characters. The result: nada. No visible munged
>characters (certainly no repeating series of them), no carrier drops ...
>nothing. Yes, error control was off. I will try some other tests at
>differing times and longer connect sessions but ... if I don't see the
>characteristic patterns of errors - does that _exclude_ clock slips as a
>cause of my high speed disconnects?


That pretty much tells you that it is not caused by clock slips.
To be absolutely sure you would want to alternate sessions
between the setup used above and trying regular connections that
normally get knocked off.  If you are indeed loosing the
connections with v.34 (or whatever) on every other attempt and
not seeing repeating patterns as I previously described on the
2400 bps attempts, that proves that you problem does exist at
that time and it is not clock slips (or any kind of phase hit).

Which also suggests that it may not be the modem or telco line
at all!  Have you tried a text session using v.34, or have all
such connections been a PPP connection?  If so, try a text
session and see what happens.

  Floyd

--
Floyd L. Davidson                                floyd@ptialaska.net
Ukpeagvik (Barrow, Alaska)                       floyd@barrow.com

From: Ken Becker <kab@airmail.hobl.lucent.com>
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech,comp.dcom.modems
Subject: Re: Phone line woes
Date: Tue, 27 Oct 1998 12:02:55 -0500

Mike NO UCE Schuster wrote:

> After responding to the first batch of great insights posted here
> (thhanks, folks) I connected again to my shell server at V.22bis 2400 bps
> with no error control. Unfortunately there were no extraneous characters
> or errors whatsoever. Due to the intermittent nature of the problem, I am
> going to have to try this for longer periods and at different times of the
> day before giving up on that proof. More later....
>
> --
> Mike Schuster                   |       70346.1745 at CompuServe dot COM
> schuster at panix dot com       |       schuster at pol dot net


Hmm..
	I heard Floyd Davidson weigh in with this topic regarding clock slips.
Now, I understand that you people have figured out that this isn't T1 clock
slipping. However, maybe what's going on here isn't exactly a T1 problem
at all!

	Now, let my theorize slightly. A couple of years ago the telco's
were running SLC (that is, a T1) to curb boxes and then delivering analog
DS0 channels to customers. Now, however, we have a craft fella telling
you that they ran fiber to some spot down the street and >>then<< ran an
analog channel down to your home.

	A slight leap of faith: The telco's are big on fiber and they're
even bigger on SONET. So, let's suppose that the telco has laid in a
fiber trunk running an STS-1 or an OC-3 to the neighborhood. They then
extract the T1's from the SONET, then further mux and codec things down
to the POTS level. So, we now have both SONET and T1 timing to consider.

	Now, a SONET system is much like a DS3 in that if a T1 is put
into a DS3, you get back the T1 at the far end with the same timing that
you put in. In fact there are some real interesting Bellcore docs
regarding how much jitter the mux/demux operation can take. The point:
DS3's don't put in much significant jitter into a T1.

	However, SONET is different. You can put in an off-frequency T1
into a SONET.  The T1 that comes out does have the same average
frequency, but the jitter is 'way up there due to the way that a T1 gets
encoded into a SONET.

	Second: If a SONET link itself is off frequency, it does "pointer
adjustments" so the payload within the SONET doesn't get lost. That is...
	1) If you off-frequency a T1 in a T1 based system, you lose data
when slips occur.
	2) If you off-frequency a SONET in a SONET based system, you
don't lose data because the SONET signal itself has a specific byte that
it sacrifices periodically when a slip "would have" occured. This
adjustments are called "pointer adjustments", and are essentially an
indication that there's a frequency offset in some piece of equipment in
the SONET chain.  Note: If you have a link of, say, 5 pieces of SONET
equipment, and, say, the third piece is off frequency, then pointer
adjustments from you toward the sink of the data will be occuring in the
third, fourth, and fifth pieces of gear. Going in the other direction
means that there will be pointer adjustments going on from the third
piece of gear and the others going in your direction. (I know this is
hard to follow, but believe me, if this is occuring, it'll be true).

	Now comes that catch. When a SONET does a pointer adjustment
microseconds of jitter get induced onto the T1 line within the SONET. For
this reason, (unlike DS3's), T1's carried inside of SONET payloads cannot
be used for network synchronization - the jitter can cause some real
strange artifacts in network timing.

	However, we're talking V.90 here. On V.90 modems we're locking
the phase of an internal 125 us sampling clock to the "Decoder" part of a
telephone CODEC. Suppose for a moment that the 8 KHz clock driving the
CODEC starts jumping around because of SONET pointer adjustments. It may
be that the modem can't track it, loses lock, and has to retrain. If the
"Decoder" clock is still jumping, it may not be able to (especially if
this lasts 100's of milliseconds), and you lose your connection.

	Note that a 2400 baud modem may not see any problems because it
doesn't really care about the CODEC clock, unlike a v.90 modem. You also
wouldn't hear any audio impairments, because no DS0 data was actually
lost.

	So, I'm not exactly sure where to go from here. The telco's do
keep track of pointer adjustments on SONET links (or have the capability
of doing so). Talk to your helpful craft - maybe there's some log data he
can pull of a SONET link that shows bursts of pointer adjustments
occasionally.

		Ken Becker