Dirty Phone Lines or ...? Next move?

A few weeks ago I started getting lots of 'errors' on my dial up
networking connection which would slow the speed down to a crawl and
ultimately will disconnect me or render the connection inoperative and
the browser etc times out.

I do connect at 44 or 45.x initially. And if I do simple stuff like
visit basic websites 1 at a time or download email it is more likely
to remain OK (some errors but not too many) for a reasonable period of
time. But if I try to refresh multiple sites at once or hit a site
like ebay that is downloading stuff from various locations at once -
that's when the errors start going crazy... In fact I can often
download a reasonable sized file w/ only a few errors. But when I try
to do too much at once that's when it goes crazy w/ errors and drops
speeds progressively.

This is a Zoom (Conexant) 3048C external RS232 modem under Win2K and
typically connects at around 44 or 45.x. (used to connect at 46-48)

I've since tried my old trusty Supra 28.8/33.6 - they too have errors
which surprised me because I always seem to remember they were fairly
immune to noise - maybe not.

I tried a different PC w/ a fresh Win2K install and SP so as to
discount any tweaks on my part - again both modems have errors.

I tried a different serial cable and phone cable and also disconnected
all the other phones in the house (just in case). Again errors. About
the only thing I haven't done is run a long phone cable out the window
and directly to the Telco box port bypassing all in house wiring
(which I'll probably do later).

I tried 3 other ISPs besides mine - again no joy.

I dabbled w/ settings like turning on/off soft/hard compression,
multi-link settings etc - various permutations beyond 'default' had
not impact either.

At this point I'm starting to think there could be a problem w/ the
phone line itself. However that puts me in a tricky spot - I had the
phone guy out here about 4 or 5 weeks ago becaue I was getting a hum
on the line. (speeds had also dropped about 2% but that wasn't the
reason I called) He didnt' find any problem but they also didnt'
charge me. He said he swapped a few cards around and gave me a
different terminal connector in my telco box. I suspect some of my
cheaper phones and/or their proximity to certain devices may be part
of that hum problem. Bottom line is that voice quality is 'good
enough' and meets their minimal requirements and I am initially
connected at well in excess of their minimal 14.4 (though I can easily
drop below that AFTER I connect - that may be difficult to prove).

Q: Does it look like the phone line would be the logical suspect at
this point?

Q: Any suggestions on strategies for next steps while hopefully
avoiding a potentially expensive service call? (Verizon)

thanks!

On Wed, 12 Jan 2005 15:09:47 -0600, LoadHawg <not@chance.com> put
finger to keyboard and composed:

<snip>

Whenever I get hum in my phone line it is due to water in the cable.
My modem's performance deteriorates appreciably when this happens.

You can use HyperTerminal to retrieve the modem's postcall diagnostic
report. This will give you information such as the reason for
disconnect, max/min Tx/Rx speeds, Tx/Rx error rates, numbers of
speedshifts and retrains.

See http://www.modemsite.com/56k/diag.asp


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

I have a very similar situation. I'm not getting any positive help
locally. Anybody have any thoughts on the following???
Thx
----------
I live in a rural, summer resort type area. Most of the homes are
unoccupied 6 months out of the year. I live here year round. We're
1.5
miles from my local phone company (Verizon) hub. (Hard wire to the
hub,
fiberoptics to the rest of the world from there.) I usual connect at
48k.
Occasionally, it drops to 24k, sometimes to 14k. I am connecting
through a
local, relatively large, relatively cooperative, ISP.

I have always suspected the reduced connect speed was due to neighbors
periodically coming back and getting on line. Haven't been able to
confirm
that one way or the other. Numerous discussions with ISP and phone
company
(including technical people) have shown no reason for the reduced
speed.
They maintain I am on a separate line, with no evidence of cross
talk/etc.
In fact, they are saying my line is a tad better than most. I have
tried
several other local phone numbers (for the same ISP) - no joy.

DSL/cable are not available at this location, so my options are very
limited.

My IC is through a WinXP. I have a WIN98SE which accesses through the
XP
via a LAN. Problem exists using either comp, turning off the 98
doesn't
make any difference.

Does anybody get anything concrete out of this? Sure could use some
new
ideas.
Thx in advance

Dave

LoadHawg <not@chance.com> wrote:
What happens if you disconnect and redial? Or redial
immediately after it has disconnected you? Do you get a good
connection again, or is it still bad? Also, is this line ever
used for incoming calls, or is it just a "modem line"? (If it's
a modem line, try calling it from another phone and letting it
ring 10-15 times, and see if that has an effect on the
symptoms.)

....

Do you mean the modem says it is seeing errors? What kind? Is it
seeing block errors or is it retraining?

That is indeed *exactly* what you need to do! Or take a laptop
with a modem out to the telcom box.

That isn't really a "tricky spot", simply because they didn't
find anything. Whatever the problem was, it didn't go away and
is getting worse.

"Hum" is caused by an unbalance on the cable pair.

The most common cause of unbalance on subscriber lines is
corrosion caused by getting wet. The corrosion results in a
high resistance path between whatever conductors it touches.
That can be other telephone lines, or ground. Same results
either way.

There are, of course, other causes, but most often hum is caused
by corroded contacts in some terminal box.

That is quite possible. The reason that you need to use a
different cable to connect to the telco interface is so that you
can be positive your house cabling is not the problem. And
without that check, it's probably 50-50 who owns the problem.

Then you clearly are *not* getting quality that is "good enough"!

It isn't just connecting that counts, it's the ability to
maintain such a connection. Besides, no telco in their right
mind (I'm not sure that such exist though...) today is going to
tell a customer that is able to get a 40k+ connection in the
first place that nothing is wrong if it deteriorates to 14.4K.
If you could _never_ get better than say 16.8K, well... maybe
they just can't get a line that good to where you live. But
since you have a history of good connections, and the initial
connection is good for some period of time, clearly *something*
is wrong.

50-50. It could be the wiring in your house. If it still
happened with all of your telephones removed, they are pretty
much cleared.

Do the outside cable thing... and if the same problems still
occur, post here again, with more details. What kind of
information does your modem give right after you've been dumped
(and while it is still working correctly). How often does this
happen? Every call, within 10 minutes? Or one a day?

Ultimately, yes you'll want to call the phone company again. If
you do the right checks first you can almost certainly avoid a
service call. You've already done most of them, so the last
couple won't be so bad.

Regardless, do post again with a description of how it turns
out.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

Floyd L. Davidson wrote:

Hello Floyd and thanks for taking time to respond,

Nope, not a problem w/ immediately reconnecting in the mid 40s. It's
very consistent about connecting at 45.3 or 46.6 these days.

No it's a voice line too. I'll arrange to have someone call me and
I'll let it ring for an extended period. However I'm curious what are
we trying to accomplish w/ this exercise?

In the DUN window (click on modem icon) there is a section called
'Activity' and the last line has "Errors:" sent | received. Depending
on the ISP I call it always (years now) connects w/ either zero or two
errors. It's that "Errors:" count that starts escallating (and speed
drops eventually to nothing...) but it does not say what kind of
errors per se.

Currently it is now connected via a telephone cable out the window and
directly to the telco port bypassing all internal house wiring - same
deal no joy: 2 different modems, 2 different PCs, 2 different serial
cables, various phone cables, 2 different ISPs and now the house
wiring bypassed and I still get 'errors' that lead eventually to
slower speeds to the point that there is no throughput.

Allow me to qualify the hum in a few ways.

I am told I have exceptional hearing. I'm someone how consistently
hears minor noises that most folks do not hear. The hum I'm hearing is
subtle and easy to 'tune out' - sounds about like a small bit of hum
one might here from a couple of flourescent lights or maybe a TV
that's on but the volume all the way down? There's nothing
inconsistent or varying about it.

My stripped connections at the box on the house are clean. I watched
him as he cut and restripped fresh connections on the box at the
street. I seem to recall he said he did the same thing at the 'other
end'...

His commercial/test handset thingy did not pick up the hum nearly as
bad as my crappy phones did - it was there but if was feint even for
me.

It's very very dry and sandy here - we can go months w/ nary a drop of
rain and until last night I could not remember the last rainfall we
had. Also the neighborhood is 'relatively' new - 10 years ago there
was nothing here but sand and trees and a few cows.

Back when the hum was 1st noticed and arguably excessive (to me) I was
NOT having problems w/ errors and slowing down of the connection
speed. This error problem only started in the last few weeks (after
his visit). In fact I kinda/sorta wonder if he might have made some
sort of change in some 'setting' in an attempt to placate a whining
customer that may have increased teh potential for data errors...? Are
there many different settings or adjustments they can apply to
individual POTS residential line? Gain?

I'll gladly accept some extra hum if that gives me
consistent/dependable data speeds.

See above - no joy w/ a direct connection to the box.

Yeah I know but what i want and what they are obligated to deliver are
probably 2 different things...

Agreed - and I think that's the 'rationale' I'm going to use when I
call them here shortly... I just want to have my ducks in a row as it
were and use the right 'language' and logic so as to avoid any
potential cost to me.

My answering machine is my only culprit. Using my digital ohmeter I
get a very high megaohm resistance across the twisted even w/ ALL
phones connected (on hook) to the wiring EXCEPT for the infamous
answering machine - connecting that one - I can immediately see a drop
in resistance - still 'OK' but... However this one device is easily
eliminated from the equation and is always the first to go whenever I
suspect a problem.

(what brands are good these days for phones and answering machines
anyway!?!?)

Yep - still occuring w/ a direct cable to the telco box outside...

Working on that... I can pull the details (I've got an old copy of
Stanislav's Diag program) out of hyperterminal if I use hyperterminal
to dial my ISP's PPP line but that doesn't tell me much because I can
always initially connect OK. Problem is I need to dial up via the DUN
PPP (not hyperterm) which is how I can induce the problem (multiple
refreshes of sites like ebay.com) - and afterwards when I go in w/
hyperterminal to retrieve data - it's always wiped out (300bps shows).
I found two ATZ commands in the registry I replaced but it still seems
to be losing the data after I disconnect and go in w/ hypterminal.

So am working on it...

Yep - I can induce this every time OR I can 'mitigate' it by modifying
my surfing habits.

If I refresh several web pages at the same time or especially a site
like ebay.com that opens many different links for eye candy I can get
it every time. If I do simple stuff in a sequential fashion like
downloading a single file or checking email or refreshing only 1
simple static html page (not ebay or similar) then I keep the errors
down and speed up pretty consistently.

If I just dial in and do NOTHING - it will sit there and produce no
errors and stay connected for as long as I please.

It's heavy data transfers esp from multiple sources/links that blow it
out of the water every time.

LoadHawg <not@chance.com> wrote:
The typical voltage seen during normal operation of a telephone
line is about 52 volts DC. Ringing the line adds 90-120 VAC
(RMS) on top of that, so the peaks are at least (90 x 1.414) +
52 volts, or about 179 volts.

That can do strange things to a corroded or damp terminal. It
might make it worse, or it might make the problem go away for
awhile. The interesting point is that if it does change
things... it highly suggests a wet or corroded terminal
somewhere.

Hmmm... I'm unix weenie and don't know diddly squat about what
to do with anything Microsoft made. (Somebody else will
probably help clear up what I'm going to try to describe.)

After a call is dropped you want to access the modem and query
it directly. Use a modem program (I don't know what there is on
a Windows box? Does Hyperterminal do that kind of thing?)

Anyway, most modems have various ATI commands, and one of them
will no doubt tell you what the modem recorded for the last
call. Try ATI11? and see what you get. If that isn't it, just
start at ATI1 and go to ATI20 and see what you get.

(I don't do that very often, and there may be other commands
that query the modem too. Somebody will no doubt have better
knowledge than I do.)

Whatever, some modems can even print out ASCII graphs of the
frequency response of the line during the connection. See if
you can capture whatever you get, and post it. 90% is perhaps
meaningless, but I'll tell you what it means as far as your telephone
line goes, and others will tell you more about what it means as far
as the modem is concerned. Sometimes the analysis of those
reports is very interesting...

Call the phone company. Their line is bad.

Are you hearing something down in the 120 Hz range? Or
actually, any multiple of 60 Hz? (It's rare, but harmonics as
high as 2000 Hz can also be generated on power lines. Usually
what you'll hear will be 60, 120, or 180 Hz.)

It shouldn't be loud enough to be heard, even by people with
sensitive ears. But... do you hear it all the time, and does
the volume stay the same? If it is as weak as you are
describing, it actually won't hurt the modem much at all, and if
it doesn't change then it can't be the actual cause of the modem
connection going bad. But whatever causes it probably is the
source of whatever impairment is affecting your calls, so it is
worth noting.

Butt sets aren't known for high fidelity... :-)

Sometimes there are, but he would know which ones are supposed
to make modems better or worse. On many systems there are no
adjustments at all.

The fact that your modem cannot maintain a good connection above
14.4 kbps is indicative of a line that is not meeting
specifications. Of course, if you are getting knocked off every
5 hours, that's a different thing. But if you can't keep a
connection for at least an hour, something is wrong.

The fact that you can actually hear hum on the line is also
highly suggestive. People with good ears who know what they are
listening for shouldn't be able to hear any hum.

Yep.

Do a few things... Ask for a trouble ticket number, and for the
name of the person you are talking to each time you talk to
them. Log it. And make it obvious that you are logging it
(they are!). Ask for expected action dates. For example, when
they say they'll get somebody on it, ask when that is expected
to happen, and make it obvious that you are keeping track and
that you will call back if they don't call you.

If they don't find anything... wait until the next time you
experience the problem, and report it again. Reference the
previous trouble call.

At any point that you get stonewalled (and don't jump the gun on
this, be sure to let the people do their job on their own
schedule), ask for a higher level of management. And then let
them refer it back down the line again. Don't be demanding, but
do be persistent.

And given the tests you describe above, do be insistent that
you are *not* going to pay them a dime to fix *their* problem!

Of course, you may still not get it fixed... Worse comes to
worse, there are other tricks to play, though it will cost you
some money. Have a second line installed. If that line works
okay, you can complain that the original line should work just
as well... and you can ask them to 1) swap the numbers on the
lines this week, and 2) next week have them cancel the original
line (now with the new number).

Not cheap, but you have an entirely new set of hardware. Of course
if that does *not* work, it indicates some common equipment problem
(for example in the fiber optics carrier systems, or whatever), and
you've spent your money to learn what they should have known to start
with! Bummer... ;-)

I don't really know.

One of the several Windows guys here, that deal with a lot of modems
too, will be able to guide you through that.

That is really weird. There are some odd things that can cause
that kind of problem. If your line has what are called "bridge
taps" on it, which are unterminated lengths of cable cross
connected somewhere, they will resonate at certain frequencies.
If your data just happens to cause the modem to send something
at the right frequency, it will go bonkers. It is possible that
you have something like that, and by doing heavy surfing you are
just increasing the number of times that some particular
frequency range gets hit by the modem. (Getting a tech to check
for bridge taps might not be easy either.)

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

LoadHawg wrote:
To ring a phone, your Telco sends a higher AC voltage through the line. If
here's humidity in wires or oxidation in connections, this voltage helps fix
the problem temporarily.

I you find out what it shows I'm interested also. I've seen that counter at
more than 8000 with my current ISP, however with previous ISP it remained at
0. In my case it is ISP dependant. Asked in a MS group without reply

You disconencted the house wiring right?

That hum could be normal from the Telco.

It is a strange interaction.

Got it - thanks.


Yes it does and I've done this type of thing in the past on previous
systems. The problem is something is forcing either an ATZ or AT&F
that clears everything before I can access the modem w/ Hyperterm.

AT&V, AT&V1, AT&V2 it's a Zoom 3048C V92 - I believe it's a COnexant
chipset (formerly Rockwell?). That stanislav diag will further
interpret some of the raw numbers (if it doesn't get reset!)

Indeed - that would be interesting to see - no joy like that w/ this
modem however...

I'm just know familiar enough w/ what i'm hearing to figure that one
out. FWIW the phone is underground and power overhead (underground
from street to house) but both do enter the house within a few feet of
each other (telco box and main house breaker box) (the lines up to the
house are NOT in parallel).

Agreed - I just wanted you to be aware that the problem has been
around and NOT affected data rates (in the past) - at least not in
this manner.


My GE 2 line home office phone and Sanyo DSS cordless seem to be of
reasonably good quality. However the other phones are cheap
Southwestern Bell phones that 'squeel' due to feedback just as the
receiver is hovering over the phone and about to be hunk up. Those are
all presently disconnected from the system (indeed the entire house is
presently bypassed for that matter).


To be fair it WILL maintian a good mid 40s error free connection speed
as long as I don't make much use of it. Of course I won't point
that detail out in my service request.

I had a highly similar problem back in Win 98 w/ errors creeping up in
the connection. A lot of other folks had an identical problem and it
was discussed here and elsewhere. But since upgrading to W2K (and
several modems in between due to lightning) I haven't encountered a
problem like this in a long time. When I first started seeing this I
started looking at my system as a possible culprit but after trying
another PC and different HW well... the line is the only thing I
havne't swapped out.

I'll post a separate post w/ teh raw data from the modem - however
note that will be a GOOD connection and NOT show the errors...

This is a dump of the data from the modem using the AT&V commands.
Note that all I did was dial the ISP (PPP) w/ HyperTerm and then
escaped and entered the AT commands. Because I'm not connecting w/ a
PPP I merely stayed connected for a minute or so and then their system
automatically disconnected me - so that doesn't really tell us much.

I'm still trying to figure a way to get teh data form the modem AFTER
I dial up via PPP and 'induce' some errors thru a little heavy usage
but so far each time the modem somehow gets reset (I cannot find any
&F or Z commands left in the registry...)

Again the following data is an example of a perfectly good typical
normal initial connection is all...

Dials PPP ISP w/ Hyperterminal manually:

OK

+MCR: V90

+MRR: 45333

+ER: LAPM

+DR: V42B

CONNECT 45333


login: <at this point logged in then escaped...>

OK
AT&V1
TERMINATION REASON.......... NONE
LAST TX rate................ 31200 BPS
HIGHEST TX rate............. 31200 BPS
LAST RX rate................ 44000 BPS
HIGHEST RX rate............. 45333 BPS
PROTOCOL.................... LAPM
COMPRESSION................. V42Bis
Line QUALITY................ 019
Rx LEVEL.................... 012
Highest Rx State............ 67
Highest TX State............ 87
EQM Sum..................... 00D3
RBS Pattern................. 01
Rate Drop................... 00
Digital Loss................ 2000
Local Rtrn Count............ 00
Remote Rtrn Count........... 00
V90 9401834355C1

AT&V2
BEGINaa15ab15ac15ad15ba42bb42bc43bd43ca77cb67cc238 da4ea1eb0fa109fb109fc109ga11gb
0ha23hb17hc48hd0he14hf211hg0hh0hi0hj21hk21hl23hm22 hn23ho20hp21hq22hr22hs23ia26ib
26ic26ja0jb0jc1jd0je0jf3ka0kb0kc0kd0ke16kf0kg0kh10 ki38kj0kk0kl62km33kn103la135lb
103lc103ld135ma0mb2mc17na2nb16oa4ob1oc0od2oe61of0o g87pa1pb0pc0pd0qa21qb4qc255ra1
8rb148rc1rd131re67rf85rg193rh213ri224rj193rk101rl1 9rm148rn42ro141rp71rq101rr141r
s224rt193ru101rv19rw148rx42ry141rz71sa3sb0sc32sd0t a23tb0tc0td218te0tf128tg255th2
ti0ua0va0vb0wa0wb0wc0END
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000




<the above buffer pasted into the diag tool below produced...>

Rockwell Diagnostics/W32, version 1.3.0.0, compiled at Jun 13 2002
22:35:24
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru,
2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Connection time : 00:02:17
Handshake Time/Retries : 23 sec/0
TX Rate (Last/Init/Min/Max) : 31200/31200/31200/31200
RX Rate (Last/Init/Min/Max) : 44000/45333/44000/45333
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 11/0
RX Signal Level (Last/Min/Max), -dB : 11/11/11
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 17.875
EQM Value (Last/Min/Max/Negative) : 23/17/48/0
EQM Samples Running Sum : 00D3
EQM Last 10 Readings : 21 21 23 22 23 20 21 22 22 23
SNR Ratio (Last/Min/Max), dB : 44/44/44
TX Non-linear Encoding : OFF
TX Precoding : OFF
TX/RX Constellation Shaping : ON/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 10
TX/RX state (Max TX/RX, Last TX/RX) : 87H/67H, 87H/67H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 573/87
RBS Pattern/Alternating RBS Pattern : 01/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/No/No
Retrains (Issued/Granted/Fast) : 0/0/0
Renegs (Issued/Granted) : 1/0
Retrans per frame/Frames rejected : 1/0
Total number of REJ sent/received : 0/0
Last Retrain/Reneg reason : Fall-back due to high EQM
Last Retrain/Reneg requested : Local Rate Renegotiation
Minutes Since Last Retrain/Reneg : 2
Disconnect reason : NONE
Remote Manufacturer/Licensee Code : Conexant/Lucent
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not
supported
Remote V.8bis caps (K56Flex version): 1.0, 1.1
Remote K56Flex RAM version supported: 85
Remote Coding used/forced by server : m-law/Yes
Remote controller version number : 1
Remote supports symbol rate (1,2,5) : 2743:ON 2800:ON 3429:ON
3429-TX:OFF
Remote supports symbol rate (3,4) : 3000-L:OFF 3000-H:OFF 3200-L:ON
3200-H:ON
Remote power drop support : ON
Remote max symbol rate difference : 0 steps
Remote is a CME modem : No
Remote supports V.34bis : Yes
Remote frequency source : Internal
Remote is ITU/K56Flex neg/High IMD : Yes/No/No
V.8 bis CRe detected/early : Yes/No
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/Yes
V92 debug information : Retrain/reneg/fast retrain
successful
Call waiting count during connetion : 0
Last MOH Condition State : Idle wait for MOH action
Last MOH Datapump State TX : Sending A/B "Retrain State"
Last MOH Datapump State RX : Unknown
PCM Upstream RBS2 Detection : Unknown
PCM Phase4 Upstream Const./RR : 4-point/4-point
PCM Upstream Pad Detection : 0dB



<At this point (a minute or two) their system disconnected me because
I was NOT responding to their PPP - here's the info after they
disconnected me but dont' think it serves much purpose...>

TERMINATION REASON.......... RETRAIN FAILURE
LAST TX rate................ 31200 BPS
HIGHEST TX rate............. 31200 BPS
LAST RX rate................ 44000 BPS
HIGHEST RX rate............. 45333 BPS
PROTOCOL.................... LAPM
COMPRESSION................. V42Bis
Line QUALITY................ 127
Rx LEVEL.................... 012
Highest Rx State............ 67
Highest TX State............ 87
EQM Sum..................... 00D3
RBS Pattern................. 01
Rate Drop................... FF
Digital Loss................ None
Local Rtrn Count............ 00
Remote Rtrn Count........... 00
V90 9401834355C1


Rockwell Diagnostics/W32, version 1.3.0.0, compiled at Jun 13 2002
22:35:24
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru,
2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Connection time : 00:02:47
Handshake Time/Retries : 23 sec/156
TX Rate (Last/Init/Min/Max) : 31200/31200/31200/31200
RX Rate (Last/Init/Min/Max) : 44000/45333/44000/45333
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 5/0
RX Signal Level (Last/Min/Max), -dB : 11/11/11
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 17.875
EQM Value (Last/Min/Max/Negative) : 127/17/50/0
EQM Samples Running Sum : 00D3
EQM Last 10 Readings : 127 101 36 35 35 35 39 50 53 21
SNR Ratio (Last/Min/Max), dB : 44/44/44
TX Non-linear Encoding : OFF
TX Precoding : OFF
TX/RX Constellation Shaping : ON/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 10
TX/RX state (Max TX/RX, Last TX/RX) : 87H/67H, 21H/20H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 573/87
RBS Pattern/Alternating RBS Pattern : 01/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/No/No
Retrains (Issued/Granted/Fast) : 0/0/0
Renegs (Issued/Granted) : 2/0
Retrans per frame/Frames rejected : 1/0
Total number of REJ sent/received : 0/0
Last Retrain/Reneg reason : Fall-back due to high EQM
Last Retrain/Reneg requested : Local Rate Renegotiation
Minutes Since Last Retrain/Reneg : 2
Fallback to V34 reason : Data Pump decision to FB, EQM
also bad
Disconnect reason : RETRAIN FAILURE
Remote Manufacturer/Licensee Code : Conexant/Lucent
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not
supported
Remote V.8bis caps (K56Flex version): 1.0, 1.1
Remote K56Flex RAM version supported: 85
Remote Coding used/forced by server : m-law/Yes
Remote controller version number : 1
Remote supports symbol rate (1,2,5) : 2743:ON 2800:ON 3429:ON
3429-TX:OFF
Remote supports symbol rate (3,4) : 3000-L:OFF 3000-H:OFF 3200-L:ON
3200-H:ON
Remote power drop support : ON
Remote max symbol rate difference : 0 steps
Remote is a CME modem : No
Remote supports V.34bis : Yes
Remote frequency source : Internal
Remote is ITU/K56Flex neg/High IMD : Yes/No/No
V.8 bis CRe detected/early : Yes/No
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/Yes
V92 debug information : Retrain/reneg/fast retrain
successful
Call waiting count during connetion : 0
Last MOH Condition State : Idle wait for MOH action
Last MOH Datapump State TX : Sending A/B "Retrain State"
Last MOH Datapump State RX : Unknown
PCM Upstream RBS2 Detection : Unknown
PCM Phase4 Upstream Const./RR : 4-point/4-point
PCM Upstream Pad Detection : 0dB
Workaround used : V90Phase2Escape
Workaround used : RateRenegFailure

"Dave" <djbahb@dcwis.com> wrote:
How often do you get these lower connect speeds? And if you
connect at a good speed, does the connection stay up and remain
good?

There are all sorts of possible reasons that some small
percentage of your connections will not be at reasonable speeds.
For example, I am located less than 1 mile from the telco, and
the modem bank I'm dialing is located in the telco office, yet
I get an odd bad connection now and then. It might be a bad
modem, it might be a bad path through the switch, or it might
just be that the connection is setup when there happens to be
some odd noise on my line that isn't normally there.

What I've done is use an init sequence for the modem that has a
lower limit for the bit rate that it can connect at. If it does
connect at a lower speed, it just drops the call and forces a
retry.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

OK I finally got it to stop clearing the modem after a disconnect and
was able to induce the errors and slow speed. Usually the connection
ceases to pass data anywhere around 50 to 100 errors which I can
usually get to in a matter of minutes if I try however this one, while
it was easy to induce the errors... hung on tenaciously passing a
'trickle' of data all the way up to 578 errors at which point it
simply would not do even the simplest thing and no data whatsoever
would pass and I disconnected the session. I immediately grabbed the
&V and #UD data and ran it thru the diag analyzers - below is both the
raw and procesed data. Interestingly enough it appears to be
maintaining the speeds which leaves me scratching my head... ideas?

thanks,

PS: In the process of trying to get the system to stop reseting the
modem so I could retain the diag info I installed the modem as a
"Standard 56000 V90". For kicks I tried it - guess what? For the first
time in weeks I could not induce errors at will. I don't know exactly
what's different about this driver but one thing I noticed was it
showed no options for things like h/w or s/w compression. (I have
turned both of those off at various times before under the Zoom
drivers but no joy).


=============================================


AT&V1

TERMINATION REASON.......... LINK DISCONNECT
LAST TX rate................ 31200 BPS
HIGHEST TX rate............. 31200 BPS
LAST RX rate................ 44000 BPS
HIGHEST RX rate............. 46667 BPS
PROTOCOL.................... LAPM
COMPRESSION................. V42Bis
Line QUALITY................ 029
Rx LEVEL.................... 012
Highest Rx State............ 83
Highest TX State............ 87
EQM Sum..................... 00CB
RBS Pattern................. 04
Rate Drop................... 00
Digital Loss................ 2000
Local Rtrn Count............ 00
Remote Rtrn Count........... 00
V90


AT&V2

BEGINaa15ab15ac15ad15ba42bb42bc44bd44ca77cb67cc239 da4ea1eb0fa109fb109fc109ga5gb0
ha29hb19hc66hd0he15hf203hg0hh0hi0hj36hk35hl29hm31h n29ho30hp33hq29hr29hs29ia26ib2
6ic26ja0jb0jc2jd0je9jf3ka0kb0kc0kd0ke16kf0kg0kh10k i38kj0kk0kl65km33kn103la135lb1
31lc103ld135ma0mb38mc1na2nb16oa4ob4oc0od2oe60of0og 86pa1pb25pc7pd25qa12qb4qc255ra
0rb255rc255rd255re255rf255rg255rh129ri224rj193rk10 1rl19rm148rn42ro141rp71rq101rr
141rs224rt193ru101rv19rw148rx42ry141rz71sa4sb0sc32 sd0ta21tb0tc0td222te0tf144tg25
5th18ti0ua8va0vb0wa0wb0wc0END
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000


Rockwell Diagnostics/W32, version 1.3.0.0, compiled at Jun 13 2002
22:35:24
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru,
2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Connection time : 00:38:01
Handshake Time/Retries : 21 sec/0
TX Rate (Last/Init/Min/Max) : 31200/31200/31200/31200
RX Rate (Last/Init/Min/Max) : 44000/46667/44000/46667
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 5/0
RX Signal Level (Last/Min/Max), -dB : 11/11/11
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 18.813
EQM Value (Last/Min/Max/Negative) : 29/19/66/0
EQM Samples Running Sum : 00CB
EQM Last 10 Readings : 36 35 29 31 29 30 33 29 29 29
SNR Ratio (Last/Min/Max), dB : 44/44/44
TX Non-linear Encoding : OFF
TX Precoding : OFF
TX/RX Constellation Shaping : ON/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 10
TX/RX state (Max TX/RX, Last TX/RX) : 87H/83H, 87H/67H
Error Correction Status : SABME:T UA:T,R XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 572/86
RBS Pattern/Alternating RBS Pattern : 04/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/No/No
Retrains (Issued/Granted/Fast) : 0/0/9
Renegs (Issued/Granted) : 2/0
Retrans per frame/Frames rejected : 1/25
Total number of REJ sent/received : 25/7
Last Retrain/Reneg reason : Fall-back due to high EQM
Last Retrain/Reneg requested : Local Rate Renegotiation
Minutes Since Last Retrain/Reneg : 18
Disconnect reason : LINK DISCONNECT
Remote supports symbol rate (1,2,5) : 2743:ON 2800:ON 3429:ON
3429-TX:OFF
Remote supports symbol rate (3,4) : 3000-L:OFF 3000-H:OFF 3200-L:ON
3200-H:ON
Remote power drop support : ON
Remote max symbol rate difference : 0 steps
Remote is a CME modem : No
Remote supports V.34bis : Yes
Remote frequency source : Internal
Remote is ITU/K56Flex neg/High IMD : No/No/No
V.8 bis CRe detected/early : No/No
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/No/No/No/No
V.8bis success/V.8bis neg started : No/Yes
Quick Connect Info0 : QC attempts failed and fall back
to V8
V92 debug information : Retrain/reneg/fast retrain
successful
Call waiting count during connetion : 0
Last MOH Condition State : Idle wait for MOH action
Last MOH Datapump State TX : Sending A/B "Retrain State"
Last MOH Datapump State RX : Unknown
PCM Upstream RBS2 Detection : Unknown
PCM Phase4 Upstream Const./RR : 4-point/4-point
PCM Upstream Pad Detection : 0dB




AT&V

ACTIVE PROFILE:
B0 E0 L1 M1 N0 Q0 T V0 W2 X4 Y0 &C1 &D2 &G0 &J0 &K3 &Q5 &R1 &S0 &T5
&X0 &Y0
S00:000 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:060
S08:002 S09:006
S10:014 S11:085 S12:050 S18:000 S25:005 S26:001 S36:007 S38:020
S46:138 S48:007
S95:044

STORED PROFILE 0:
B1 E1 L1 M1 N0 Q0 T V1 W0 X4 Y0 &C1 &D2 &G0 &J0 &K3 &Q5 &R1 &S0 &T5
&X0
S00:000 S02:043 S06:002 S07:050 S08:002 S09:006 S10:014 S11:085
S12:050 S18:000
S36:007 S40:104 S41:195 S46:138 S95:000

STORED PROFILE 1:
B0 E0 L1 M2 N0 P Q1 V1 W2 X1 Y0 &C0 &D0 &G0 &J0 &K7 &Q3 &R0 &S0 &T5
&X0
S00:002 S02:050 S06:002 S07:006 S08:014 S09:085 S10:050 S11:146
S12:000 S18:000
S36:195 S40:000 S41:000 S46:050 S95:001

TELEPHONE NUMBERS:
0= 1=
2=


AT#UD

DIAG <2A4D3263 41=80>

DIAG <2A4D3263 42=00>

DIAG <2A4D3263 43=19>

DIAG <2A4D3263 44=01>

DIAG <2A4D3263 50=02>

DIAG <2A4D3263 51=02>

DIAG <2A4D3263 52=0FAF6507>

DIAG <2A4D3263 53=6FB24100>

DIAG <2A4D3263 54=0000>

DIAG <2A4D3263 55=0000>

DIAG <2A4D3263 56=0032CB00>

DIAG <2A4D3263 57=00B13800>

DIAG <2A4D3263 58=0700>

DIAG <2A4D3263 59=0019>

DIAG <2A4D3263 60=5F>


Unimodem Diagnostics/W32, version 1.1.0.1, compiled at Nov 20 2002
22:29:14
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru,
2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Protocol/Compression : NA/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 0
Error control NAKs received : 25
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 263152903/1873953024
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 3328768/11614208
TX/RX I-Frame error count : 1792/25
Termination Cause : Disconnect Frame Received

Now that you mention all of that, sounds like a familiar situation. Years
ago I had an internal Conexant Soft56 modem in an old computer (Pentium
200MHz running Win95) and I was experiencing similar problems. The
connection would be slower and slower until no more data was being
transmitted. Usually if the CPU load and bandwidth usage was kept low, you
could surf normally without problems. But if you tried to open many webs at
once, or started some CPU-intensive program (i.e. Outlook Express in that
PC), the connection would start to drop in performance until no more data
flow.
When I bought a new computer it came with a similar internal Conexant Soft56
modem (not the same model). I started using it and noticed all these
problems I belived were due to my ISP, weren't showing any more, fluid and
reliable connection. Thus the culprit was the old PC/modem combo.

Interestingly enough I tried my new modem in my old PC and it worked great.
Then installed my old modem in my new PC and also worked great. I belived
the 200MHz Pentium was unable to keep up with the Soft drivers for that
modem model, however there could be another reason.

About your error counter showing 578, I've seen mine at more than 8000
errors without a significant performance loss. I don't know what kind of
errors shows. I've a good line and I get usually 52K connection, and as I
commented in another post, these errors didn't show with another ISP.

LoadHawg expuso:

On Thu, 13 Jan 2005 17:39:48 -0600, LoadHawg <not@chance.com> put
finger to keyboard and composed:


What kind of errors do you see in your modemlog and ppplog?
http://www.modemsite.com/56k/modemlog.asp
http://www.modemsite.com/56k/ppp.asp

It appears that your ISP's equipment terminated the call, perhaps
because it detected an inactivity timeout (???).

Termination Cause : Disconnect Frame Received
Disconnect reason : LINK DISCONNECT

AFAICS, your phone line seems to be quite good. In particular, your Rx
error rate is very low. The only thing that concerns me is the RBS
figure (robbed bit signalling). Ideally it should be zero. Your other
log showed a value of 1. I have no idea whether this parameter is of
significance.

The variation between your two logs could be due to different ISP
equipment. Notice that your other AT&V2 report identified the server
equipment as Conexant/Lucent, whereas there is no such info in the
current log.

Connection time : 00:38:01
TX Rate (Last/Init/Min/Max) : 31200/31200/31200/31200
RX Rate (Last/Init/Min/Max) : 44000/46667/44000/46667
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
Signal Level (TX/Power Drop), -dB : 5/0
RX Signal Level (Last/Min/Max), -dB : 11/11/11
EQM Value (Last/Min/Max/Negative) : 29/19/66/0
EQM Last 10 Readings : 36 35 29 31 29 30 33 29 29 29
RBS Pattern/Alternating RBS Pattern : 04/00
Retrains (Issued/Granted/Fast) : 0/0/9
Renegs (Issued/Granted) : 2/0
Retrans per frame/Frames rejected : 1/25
Total number of REJ sent/received : 25/7
Minutes Since Last Retrain/Reneg : 18


TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 263152903/1873953024
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 3328768/11614208
TX/RX I-Frame error count : 1792/25

That's puzzling. Yours is a hardware modem (ie no drivers), so there
should be no difference, unless the initialisation string contains
some unusual AT commands.

Not a driver, just an INF file.

That's because the generic INF file contains no EC or data compression
AT commands. Regardless, the modem will still negotiate these by
default.

The first part of your AT#UD report is missing.

<snip>

Try this procedure to have the AT#UD report automatically appended to
your modemlog. I'm not sure if it will work for Win2K, but it
definitely works for XP.

http://groups-beta.google.com/group/...d?dmode=source


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

Franc Zabkar <fzabkar@optussnet.com.au> wrote:
The odd thing about the RBS figure was that it changes. Every
dump he has posted had a different number. That may just mean
there is one RBS link, and the different numbers listed
indicated a different frame number for each connect, which would
be normal.

Note that the Signal Level figures for both TX and RX are
"adjusted". It appears they refer to testtone levels, not data
levels. Whatever, without knowing exactly what they are
adjusted for, it is impossible to say they are good or bad.
There is no modem that will transmit at -5 dBm, and a RX level
of -11 dBm wouldn't likely work either. Hard to say what the
numbers actually mean.

....

None of that look bad at all.

However (not included in the quoted text here), the SNR numbers
were 44 and 43 on every one of these reports. That is
borderline. I'm surprised that it was able to connect at 44K,
though I suppose the reason is that the "hum" being heard is 60
and 120 Hz, and the reports are indicating that the low end of
the bandwidth being used is 150 Hz.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

Franc Zabkar Jan 13, 9:31 pm
Am working on that tomorrow...

Sorry - no let me clarify - 'I' AM DISCONNECTING usually at the point
that NOTHING further can be sent/received or sites are displaying at
such a snails pace they time out - picture trying to surf the web at
aound 0-1200 baud. SOmetimes it will disconnect but not that often -
usually just a complete inability to send receive forces ME to
disconnect/redial (too often I might add) and this is the standard
data I always see when I disconnect myself... I've never understood
why it doesn't say something like USER DISCONNECT.

Let me also clarify that as we approach this situation of no longer
able to send receive data - very occasional sporadic small bits of
data go thru - imagine about 45 seconds of nothing and then maybe a kb
or two. then a minute of nothing then 2 kbs and so on and so on. Just
a little 'flicker' every once in a while. Apparently those tiny little
amounts of data are still coming thru at a decent rate of speed - the
problem is the long periods of silence and the end result is a
perceived connection speed that is a snails pace.

In case I goofed on the previous logs I posted two logs that I
carefully staged - one w/ a good session and the other where I induced
errors by doing some heavy refreshes in sites like ebay.com.

Well unfortunately Zoom forces a 7M 'installation' routine on me to
get to the .INF. And that INF references at least one .SYS and one
..DLL and maybe a few others.

Making it worse Zoom uses some sort of proprietary encryption on their
3048C install file so I can't try and just pull out actual modem data
stuff and skip all the MOH stuff they force on me. It's not that bad
however mostly it's installing the MOH software which I dont' use or
turn on and has remained basically a non-issue for a year or two now.

After installing the package I've tried to recover just the modem data
files (ACF_VA.INF, HSFINST.DLL, MDMXSKD.DLL, MDMXSDK.SYS...) but
didn't have much like trying to trick that install. I spent some time
going thru the .INF - I think the lack of those options has more to do
w/ how the INF file is 'installed' by W2K than in any AT commands.

Understand. One solution might be to just go w/ the generic (I need to
test me and see for sure that I can't induce errors and drop in data
throughput) and just enter some add'l commmands like the PCW command
to disconnect for incoming calls. Might be 'good enough'.

That or I might tweak my own hybrid .INF using a combo of the ACF and
generic versions... At the least it would be nice to always see my
initial connect speed rather than the generic '56.7' the generic
always reports.

Sorry 'bout that. I noticed this too after posting - I just posted a
new thread w/ two complete post session diags, one bad and one good.


Will check these out tomorrow - thanks Frank!

And to confuse matters worse - 44 is generally 'slow' even now for an
initial connection speed. I rarely see it (can't remember the last
time). I've been connecting at 46.x for as long as I can remember and
sometimes 48. Lately it's been around 45.x.

In my testing I tired another ISP (earthlink) besides my own regular
one and that one I still connect at around 46.x. The V.92 light shows
up on that one too FWIW. HOwever I also was able to induce the errors
pretty easily there as well. However I didnt' spend a lot of time
there - it was just a test.

Franc I wanted to follow up further on a couple of points you
raised...

Franc Zabkar Jan 13, 9:31 pm
OK to follow up I've looked at the modemlogs before and again today -
in short I don't think there's much of anything there that will help.
If you'd like I can post some but as you know it's just capturing
stuff like the AT commands and my own inits and so forth. I'm seeing
nothing special or unique between a 'good' session and one that I
induce to 'go bad' in that log.

The other one, PPP log looks much more promising. Unfortunately I have
W2K so have to start it at the shell - I'm going to have to come back
to this later today when I have a little more time but this one
definately looks like it's worth checking out further...


<SNIP>

A further follow up on the two different modem INFs and the initial
apparent success of teh generic settings: A) Zoom 3048C V.92 vs B)
generic 56000 V.90. I had earlier reported that no errors were
occuring when I switched to this driver. This is only true in part.

A) it does NOT seem to be popping errors like the Zoom setup - stays
at a rock steady 0 or 2 (depending on which ISP - it's always been
that way for years). This is different from the Zoom 3048C .INF.

B) unfortunately it STILL does die the slow death of devolving to no
throughput - just the dead modem w/ only kb here or there w/ extended
periods of silence. This is exactly the same as before.

While both teh issue of popping errors in the DUN window and the
slowing and final lack of throughput manifested at teh same time - it
suggests they may not exactly be connected. Or the errors continue and
the generic settings don't share that info w/ the DUN... At any rate
the problem of the connection dying is identical but less easy to
notice w/o errors being displayed using the generic driver - just
wanted to follow up on that as it was indeed puzzling. Hope that
helps.


Anyway at this point as soon as I have a little time I'm going to
pursue grabbing some PPP logs for both good and bad sessions to
compare and see what can be seen and will share. I already posted a
full pair of good and bad diags (post call, AT&V...) in a separate
thread - it's long but a full set of data is there for 2 sessions.

Thanks!

On Thu, 13 Jan 2005 21:35:46 -0900, floyd@barrow.com (Floyd L.
Davidson) put finger to keyboard and composed:

FWIW, my typical results are:

Signal Level (TX/Power Drop), -dB : 10/0
RX Signal Level (Last/Min/Max), -dB : 18/18/18

All my logs over the past several years vary between 44 and 48. During
the last year my Rx rate was a very stable 48000bps. I live about
1.5km from the exchange. My modem's chipset is Rockwell/Conexant ACF2.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

Hi LoadHawg

Let me suggest two things worth checking:

Try PortMon from http://www.sysinternals.com
Induce the errors and see what it shows. Very simple program requiring no
installation.

Use the ATM2 command to keep the modem speaker on, and induce the errors.
Listen for some discontinuity in the noise, which will indicate that it is
renegotiating due to some noise or quality degradation, or some carrier
disruption.

Good luck

BTW: don't be tempted to install ComSpy from Spywindows. This is garbage and
will corrupt your Windows registry.

LoadHawg wrote:

Franc Zabkar <fzabkar@optussnet.com.au> wrote:
Those are reasonable! If you are using an identical modem, it
does tend to indicate the modem is correctly measuring levels.
If that 5/0 is an accurate measurement, and the -11 is a dBm for
the received signal, that line is *really* screwed up!

The send level for data should be 13 dB down from "test tone
level". Which means the level from your modem seen at the line
card of the telephone company should be -13 dBm, at most.
Modems usually use -11 or -10 dBm as defaults, and assume a 2 to
3 dB loss on the cable (and they are aware that there is 4 dB of
headroom). That gives very little margin of error for someone
located across the road (or inside) the telco office.

The problem is that digital carrier simply clips at +4 dBm, and
data has peaks that exceed 12 dB over the average. A -10 dBm
modem has peaks at +2 dBm, and if that is connected directly to
the telco line card there is only a 2 dB margin before clipping
starts. That can be too close if there is anything at all in
the system that has too hot a level.

If the modem is sending at -5 dBm... the peaks will be at about
+7 dBM, or 3 dB over the clipping point unless the modem is on
a line with at least 3 dB of loss (perhaps 2 or 3 miles from the
line card).

Typically a telco line design target for received signal is -9 dBm,
so a data signal should be at -22 dBm.

Your -18 dBm is 4 dB hot, suggesting you have a either a short
cable between you and the line card, the line card is putting
out a very hot signal, or the modem is not providing an accurate
reading. (In fact, all of the above are likely to be relatively
true.)

But at -18 dBm, you have a reasonable reading that could be
produced by normal circumstances, and should work.

A -11 dBm receive signal isn't reasonable. If that is true, it
is probably overdriving the modem. And that -5 dBm TX level is
probably clipping at the telco's line card.

If that modem's measurements are anything like correct, there is
something wrong with the telco's equipment. It looks like it
has been configured for a very long line, and is actually on a
very short line. Perhaps the telco tech thought boosting the
level would be helpful, which it is correct up to the point
where it clips, and that is almost instant death for v.32, v.34
or v.90/92 connections.

Okay. That indicates they are giving very conservative
measurements (modems are *not* test equipment as such, and the
readings are totally relative!). If 44 dB is a typical reading
for you when you get 45+K connections, we need not be concerned
about it then.

The problem is, the other measurements may or may not be any
more "accurate". What might be interesting is to see what that
modem produces on another telephone line. Say the neighbors
line, so that it has much the same characteristics.

Regardless, all of the above is just a guess, and cannot be
relied upon as correct.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com