unreliable DSL in Washinton DC
slownet
Enthusiast - Level 3

I live in a neighborhood that is not served by FiOS because it is in Washinton DC - one mile from the vice Presidents House.  Go figure.  So I have a DSL link and it crashes occasionally - sometimes it runs for a month but some periods it crashes frequently.  The most recent period of crashes began about a month ago.  I do have a fix - reboot the router - but that gets tedious.  The router is always up and available when the link is down so I feel quite comfortable that the problem is the link and not the router. I called support - telephone works OK even when DSL is down - and they gave me the usual spiel about checking my line.  It was working fine b/c I rebooted the router so they saw no problems.  Since 2 Aug I have been keeping track of the problem and one no day have I not had to reboot.  That is, 9 days I had to reboot at least once and on six of those days I had to reboot twice in one day.  I reboot whe I see it is down, mornings and evenings generally, but that probably is an artifact of my work schedule.  I considered writing a script to ping somewhere every 10 minutes to track when the link goes down to see if there is a pattern to when the local switch reboots their DSL interfaces and leaves me hanging.  I've also considered using the neighborhood chatlist to see if any other people are having problems with their Verizon DSL service.

Anyone else have any ideas for getting reliable Verizon DSL service in the nation's captal? 

0 Likes
Reply
1 Solution
slownet
Enthusiast - Level 3

You are right - thanks.  The line went down again this morning and I checked the transceiver stats before rebooting.  The downlink noise margin was 0.-3 (sic) when it usually is around 6.  After rebooting it was back to 6.

Thankyou for the help. 

View solution in original post

0 Likes
Reply
22 Replies
FieldT
Enthusiast - Level 3

Try demanding a tech come out to your house, bad numbers almost can never be fixed without someone coming out and fixing the problem.

0 Likes
Reply
slownet
Enthusiast - Level 3

Thanks to all contributors for the help.  You were right that the answer lay in a new pair.  Sometime about a week ago I call Verizon for the umpteenth time, spoke to numerous supervisors, rejected their argument that my problem was the modem, and got them to promise that a tech appointment would be scheduled (although they did have to see the link crash one more time).  Last Thursday I got a modem in the mail, which worried me somewhat, but I had reconfigured the wireless part of my network both to improve throughput and to take those duties off the Westell unit, so replacing the modem was relatively trivial and accomplished in 30 mins.  Then on Sunday I got a call saying that the tech would be at my house no later than 1700 on Monday.

He did contact me a little after 1700 and came a little later.  Once I explained the problem he agree that the problem was not in my house and began investigating the wiring from my house to the street.  After some mucking about he confirmed that the measurements on my pair were very erratic and that he would switch them.  He promised that the work at the co would be done no later than 1000 the following morning.  A quick, efficient and courteous visit although it took months to get it.

He left, the line went down and was not up when I went to work the following morning.  That evening, when I got home, it still wasn't up and I called the tech who promised to fix it directly.  In the end, the DSL link and my phone were dead for 72 hours and I got to talk to a lot more Verizon employees.

This evening I came home, spotted a ladder truck and found that I had actually managed to get Verizon to fix the problem without waiting for me.  The problem seems to have been that my pair is not on the pole it is listed at and that my pair spans two poles.  I suspect that the tech and the co switched two different pairs.

I now have good values on the transceiver stats and I hope that it won't crash tomorrow morning.  The people I have spoken with at Verizon have been uniformly nice but as far as I can tell the corporate values of Verizon are to avoid doing anything that costs money as long as possible.  My very first trouble call identified the problem as being between the co and my home and it still took over a month of very energetic calls to get it fixed.

Telco deregulation seems to have done more for the telcos than for the consumers.

slownet
Enthusiast - Level 3

So, it has been one month, 30 disconnections, 9 "solved" trouble tickets and the problem persists.  

I've spoken to a significant number of very polite Indians who all have to say "don't worry - we will solve your problem."  {please keep your posts courteous}

Who does one call:  Better Business Bureau to complain about fraud?  The FCC to complain about false advertising and monopolistic behavior?

Welcome any ideas.

0 Likes
Reply
dslr595148
Community Leader
Community Leader
Since I now know what modem you are talking about...

The correct path might be System Monitoring -> Advanced Status -> Transciever Stats.

^
0 Likes
Reply
slownet
Enthusiast - Level 3

I had hoped to include stats for the transceiver when the link was down but have not had a crash since the morning of the 13th.  These are the stats for the transceiver while it is working fine.

Transceiver Revision A2pB020b3.d19d

Vendor ID Code 4D54

Line Mode ADSL_G.dmt

Data Path INTERLEAVED

Transceiver Information Down Stream Path Up Stream Path

DSL Speed (Kbits/Sec) 2944                             832

Margin (dB)                         6.8                                     9.0

Line Attenuation (dB)         40.0                                     25.0

Transmit Power (dBm)        18.8                                     11.9 

This weekend I expect to run a test to compare the logs from a physical line failure to those from a logical line failure.  As far as I can read the logs above and the lights, my problem is a logical disconnection rather than a physical one since the DSL link remains up but the internet connection drops.  Similarly, the error logs only refer to logical problems rathe than physical problems.  Of course, that is where I started, seeing the problem as being high in the OSI stack and on Verizon's end rather than in my modem or DSL path, but I don't usually spend my days troubleshooting modems, so YMMV.

0 Likes
Reply
Telcoguru
Master - Level 1
You may be too far from the C.O. for 3Mb service.  You need to be about 12,000ft or less otherwise downgrading to a lower tier will fix your problem.
0 Likes
Reply
slownet
Enthusiast - Level 3

You are right but the connection is generaly steady and then has periods, this is the longest one, when the service is unreliable.  It has gone for months with no hiccups and then suddenly there is a period when it can't remain alive.

Yesterday we had a huge rainstorm and that did not bring the service down although it did lower the noise margin - on the downlink only - which reduces the chances that the cause is environmental.  Yesterday I also started logging the exact time that the link went down, based on the logs.  So far I've had three crashes since yesterday afternoon, 16:42, 05:31 and 08:37.  Since the rains remain in the area and there are showers off and on, that may be a correlation though I still loose the link when it is completely dry.

We'll see.  With any kind of luck the five day monitoring cycle will give the c/o staff something to work with. 

0 Likes
Reply
FieldT
Enthusiast - Level 3

Does not sound like a CO problem at all, sounds like it's in the lines. Even if you are only 10' from nid anything else on line can still interfere with it. See if you can plug directly into the nid. Have the techs ever done a pair change? That is change the pair of wires you are on to the CO with a spare pair. If not I would have this done first. If that doesn't help have the tech call the MCO dept. And have them run a MLT test to see how the line looks. Ask them if the multi notch setting is turned off, if not ask them to turn it off and see if the capacity and the noise margin increases or decreases. If it is better or the same, leave it off, if it's worse have them turn it back on. Then have them temporally turn you down to 1.5m and see how the capacity and the noise margin look then. I have had many DSLs work better and faster at 1.5m then 3m

0 Likes
Reply
Telcoguru
Master - Level 1
Your stats look bad. I suspect that there is a line trouble somewhere. Try to test from your NID if you can. If not call DSL repair. Your download noise margin is too low causing disconnects.
0 Likes
Reply
slownet
Enthusiast - Level 3

You are right - thanks.  The line went down again this morning and I checked the transceiver stats before rebooting.  The downlink noise margin was 0.-3 (sic) when it usually is around 6.  After rebooting it was back to 6.

Thankyou for the help. 

0 Likes
Reply
slownet
Enthusiast - Level 3

So, I called Verizon when the link was down and after about 20 minutes of testing they declared that there was a problem between the c/o and my house.  "Yes" I said.  They started a trouble ticket and declared it closed, by phone call, about 12 hours later.  The following morning, the line was down again.  So, yesterday morning, I called to reopen the trouble ticket - that's hard becasue the phone staff are trained on the assumption that every call is a new problem.  We went through all the troubleshooting again during which they found that I had no problem because the line was working (here is the secret that they wouldn't hear: I fixed it by reboting the modem.)  Yesterday evening a very polite young man called to say that they had started a 24 hour test of the line and this morning - about 14 hours later - they called to say that the trouble ticket was closed and the problem fixed.  We'll see.  So far, I have not been able to convince them that the test for an intermittent problem is not a 24-hour test but a 7 day test.

From a technical perspective, the noise margins on the down link are slightly higher, I think, closer to 7.5 rather than 6 where I mostly saw it, but I am not checking it every 5 minutes so don't have a very good picture of what is normal.  We'll see.  The customer staff are all very nice, follow the scripts and the follow up is good, but the attention to the technical problem is not half as good.

0 Likes
Reply
FieldT
Enthusiast - Level 3
Did you try plugging in directly to the Nid and see if noise margin increased? Make sure to use the cord that came with modem to go from modem to jack/Nid, if not avail., use shortest cord you can. If noise margin is better you have bad wiring or bad connections in house. If it looks the same, trouble maybe outside in the lines. 80% of the time it is in the house, you need solid copper phone wire, not stranded wire like the stuff most phone cords are made of. Disconnect all unused lines in the house. Have you ever had a tech out to the house? If so did he do anything?
0 Likes
Reply
slownet
Enthusiast - Level 3

I'm typing with one hand and talking with Verizon in India as I type.  The line went down again this evening and this very nice tech ws trying to diagnose a problem in my computer.  Squelshed that idea, reset the line and now we are doing a line test - which won't show much since I rebooted the modem and fixed the problem.   She has permission to open a trouble ticket at the c/o which - I predict - will complete a 24-hour line test in half that time, declare it solved and call me with that good news.

Now I am supposedly getting 24 hr line tests for several days (until Tuesday) and then they will contact me.

The modem is plugged in using the rj-45 cable that came with it and it is about 10 feet from the outside box as well as the first device on the line.  The only way the modem could get closer to the outside box would be to park it on the lawn.  The connection from the outside box to my distribution panel was done by professionals five years ago.  I guess I'd believe in an internal problem if both up and down noise margins were bad, but my uplink is stable while the downlink margin is consistently lower (by 4-5 dB) and crashes every 12 hours or so.  The uplink margin shows no variation at all.  The fact that the crashes seem to coincide with sunrise/sunset makes me think that it is some device on a diurnal cycle between my house and the c/o or a device with a problem that crashes itself on a regular cycle.

Anyway, thanks for the ideas. I will double check the lines and makse sure that no spider is warming it's babies in the distribution box. 

0 Likes
Reply
ElizabethS
Moderator Emeritus
If you would like the "solved" designation removed from this thread, slownet, just PM me and I'll be glad to do that for you.
0 Likes
Reply
slownet
Enthusiast - Level 3

Thanks Elizabeth,

I think the problem is solved from an intellectual point of view - we know that the problem is a low noise margin on the down link.  Now the problem remains conveying that through customer service to the c/o techs who can do something about it.  Naturally, intermittent problems are the hardest to solve and the ones that the customer service can do least about.  None the less, their scripts require them to do certain things in a certain order and it is not possible to actually solve the problem on the timescale apparently imposed by Verizon.  Even the follow up calls, reporting the results of the 24 hour tests, seem to come before 24 hours have passed.

I am formulating a theory which runs along the lines that the customer's cost of complaining must at least equal the cost of Verizon's repair.  If there is a physical line problem between the c/o and my house, my efforts/costs to get that problem resolved must be at least as high as the cost of fixing the line because any repair to infrastructure takes away from profits.  It might make sense from a telco perspective but is not what I expect to be the responsibility of the telco in a commodity arena which esentially is monopolized by a few companies.  If they own all the copper, they need to maintain it at a reasonable level of service.  Similarly, ISPs can charge per MB when the serives is equivalent to power, gas and water.  As long as the ISPs provide "up to x download speeds" they shouldn't be able to charge by consumption.  Imagine if PEPCO promised up to 110V/50 Amps, or WASA up to 100 gallons of water a day.  Their service is as much as I can use in a normal residence, and ISPs should be the same.

Back to the point, can we change the title to  "unreliable DSL in Washington DC - problem identified but not fixed"?

0 Likes
Reply
dslr595148
Community Leader
Community Leader
If you have no idea on what "Telcoguru" meant, the brand and model of your router would help...
0 Likes
Reply
slownet
Enthusiast - Level 3
The light that reads "Internet" has changed to red from green.  All other lights remain green and active.
0 Likes
Reply
slownet
Enthusiast - Level 3

Whew, for a while there I thought I'd have a day without a lost connection.  The "internet" light doesn't turn red, it goes off when the link is lost.  The "DSL" light remains green as does "power" and "E1."  "Wireless" also remains green.  In other words, the only visible difference between connected and disconnected is that the "internet" light goes out.  As seen from my computer, the router also remains fully accessible with no signs that it has suffered an internal malfunction.

Next time it is down I'll go through the system logs to see if they add any useful data although I have little doubt that the problem lies between my Westell 5700 and the local c/o.  Looking at the logs now just tells me what happened after I rebooted.

Appreciate the assistance. 

0 Likes
Reply
Telcoguru
Master - Level 1
Please post your modem stats from this page. http://192.168.1.1/transtat.htm
0 Likes
Reply
slownet
Enthusiast - Level 3
This is the log for this morning's link loss.  I've removed some computer names used on my network and begun the log when errors begin to appear right before the crash.  I laos had to delete soem redundant messages to avoid exceeding the max message length on this forum.  I'll collect more stats next time it crashes.  I was fortunate to be at my computer as the link went down.  By now I'm not going to bother resetting the clock in the modem to summertime.  Thanks for the assist.
 
Time Severity Process Details
Aug 13 05:23:29 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 
iplocal:96.231.xx.xxipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 xx.xx
161.12
Aug 13 05:23:29 daemon.warn pppd[937]: pppd[937] EXIT_PPPOE_TIMEOUT_PADO caused InternetFail 

light to be lit
Aug 13 05:23:29 daemon.notice pppd[937]: PPPD Exit Status changed 

EXIT_OK->EXIT_PPPOE_TIMEOUT_PADO during phase PHASE_SERIALCONN->PHASE_HOLDOFF
Aug 13 05:23:29 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_HOLDOFF(11)
 05:23:29 daemon.notice pppd[937]: Westell Random Holdoff returning 454 seconds
 05:23:29 daemon.warn pppd[937]: Leaving destroy_pppoesessionfile
 05:23:29 daemon.err pppd[937]: Unlinking PPPoE session file:/WFIO/ppp-config0
 05:23:29 daemon.warn pppd[937]: Enter destroy_pppoesessionfile
 05:23:29 daemon.err pppd[937]: Unable to complete PPPoE Discovery
 05:23:29 daemon.warn pppd[937]: Timeout waiting for PADO packets
 05:23:29 daemon.warn pppd[937]: waitForPADO: timed out
 05:23:19 daemon.warn pppd[937]: waitForPADO: timed out
 05:23:14 daemon.warn pppd[937]: waitForPADO: timed out
 05:23:09 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 
iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 
bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:23:09 daemon.notice pppd[937]: PPPD Exit Status changed EXIT_PEER_DEAD->EXIT_OK during 

phase PHASE_DORMANT->PHASE_SERIALCONN
Aug 13 05:23:09 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_SERIALCONN(2)
Aug 13 05:23:09 daemon.notice pppd[937]: Wan link is up and PPPoE Terminator on DSL:nas1 is done 

working
Aug 13 05:23:09 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 

iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 

bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:23:09 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_DORMANT(3)
Aug 13 05:18:33 daemon.info dnsmasq[189]: DHCPACK(br0) 192.168.1.42 00:13:d3:51:08:76 
Aug 13 05:18:33 daemon.info dnsmasq[189]: DHCPINFORM(br0) 192.168.1.42 00:13:d3:51:08:76
Aug 13 05:18:04 daemon.err cwmpd[234]: ddnsWanIPCallback WAN State Down
Aug 13 05:18:01 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 
iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 
bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:18:01 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_HOLDOFF(11)
Aug 13 05:18:01 daemon.notice pppd[937]: Westell Random Holdoff returning 308 seconds
Aug 13 05:18:01 daemon.warn pppd[937]: Leaving destroy_pppoesessionfile
Aug 13 05:18:01 daemon.err pppd[937]: Unlinking PPPoE session file:/WFIO/ppp-config0
Aug 13 05:18:01 daemon.warn pppd[937]: Enter destroy_pppoesessionfile
Aug 13 05:18:01 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 

iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 

bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
 05:18:01 daemon.info pppd[937]: Sent 9263314 bytes,received 176378351 bytes.
 05:18:01 daemon.info pppd[937]: Connect time 5057537.0 minutes.
 05:18:01 daemon.notice pppd[937]: Connection terminated.
 05:18:01 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 
linkname:config0 iplocal:96.231.87.49 ipremote:10.1.78.1 ppplogname:root orig_uid:0 
connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 
dns2:68.237.xxx.xx
Aug 13 05:18:00 daemon.warn pppd[937]: pppd[937] EXIT_PEER_DEAD caused InternetFail light to be lit
Aug 13 05:18:00 daemon.notice pppd[937]: PPPD Exit Status changed EXIT_OK->EXIT_PEER_DEAD during 
phase PHASE_ESTABLISH->PHASE_DEAD
 05:18:00 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_DEAD(0)
 05:17:58 daemon.notice net_mgr[237]: Routes transitioning to Down state on ppp0.
 05:17:58 daemon.notice net_mgr[237]: QoS on ppp0 transitioning to Down state.
3 05:17:55 daemon.notice ip-down[1129]: ppp0: 9263314 bytes sent,176378351 bytes received
 05:17:54 daemon.notice ip-down[1129]: ppp0: disconnected;connected for 303452220 seconds
 05:17:54 daemon.warn pppd[937]: Couldn t increase MRU to 1500
3 05:17:54 daemon.warn pppd[937]: Couldn t increase MTU to 1500
 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 

linkname:config0 iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 

connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.x.xx
dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_ESTABLISH(4)
Aug 13 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 
linkname:config0 iplocal:96.231.87.49 ipremote:10.1.78.1 ppplogname:root orig_uid:0 
connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.x.xx
dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_NETWORK(7)
Aug 13 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 
linkname:config0 iplocal:96.231.87.49 ipremote:10.1.78.1 ppplogname:root orig_uid:0 
connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.x.xx
dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell ip_down()
Aug 13 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0
linkname:config0 iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 usepeerdns:1 
dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_TERMINATE(9)
Aug 13 05:17:54 daemon.notice pppd[937]: Serial link appears to be disconnected.
Aug 13 05:17:54 daemon.info pppd[937]: No response to 6 echo-requests
Aug 13 05:16:23 user.err syslog: WSTLIB_HTTP: error sending request
 
{edited IP's for privacy}
Message Edited by KaLin on 08-14-2009 03:42 PM
0 Likes
Reply