US Telco Support > Frontier Communications > [DSL] drop outs, connection interupted....multiple service calls

reply to COjosh

Re: [DSL] drop outs, connection interupted....multiple service c

The FEXT issue was experienced w/ subs generally within 4k feet or so, on VDSL2 mind you, and the ADSL2 problem seems to have been mostly less than 6.5k feet.

As far as why the ADSL2 anomoly, I really have no idea. I HAVE heard, however, that it has to do with how "hot" the SNR comes to the far-end modem. Most subs, on 3Meg, should be provisioned on an ADSL card as opposed to an ADSL2 that can provide faster sync rates and "louder" SNR values...at least that's the way I understand it, I could very well be wrong..

The OP does indeed appear to be further out than that..

Again, a shot in the dark, no more no less..

Good to know. Thanks for the info! Never hurts to take a shot in the dark.

reply to COjosh

reply to wchill09
It's not like you're taking a ton of FEC's right before, or even leading up to, when the modem goes down..weird

It also doesn't look like any of the DSL stats fluctuate AT ALL during the period of time these screen shots were taken.

To be honest, I'm stumped...There are a SOME discard packets on the ATM side but nothing too unusual..

I'm of the opinion that this isn't copper trouble at all, at least not currently.

Does the DSL light actually go out/start to flash, or are we dealing with the Internet light going out but DSL staying solid?

From all the info you provided in the screen shots it would seem to be the later..

Sounds like a key circuit is bouncing and failover is not going smoothly or getting a problem that is resulting in a ton of communication errors. If this is the case, a circuit should not be encountering an issue that often. Anyone nearby you seeing the same issue at all?

Some more food for thought. Before a family relative of mine moved to Cable Internet, they had Verizon DSL service that could operate at no more than 1.5Mbps/384kbps due to their line being 2.7 miles out from the remote. They were fed off of a Catena Remote Terminal with Integrated ADSL DSLAM which was fed by OC-12 fiber and demuxed to T3(or multiple T3s). This is a pretty old remote and had a fair amount of users on it, and it's age might account for the T3 connection. At random, the DSLAM would seem to stop working correctly where it would retrain every single line endlessly for up to a few hours at a time almost as if the unit was rebooting due to a fault. Phone service would continue to work without a single problem. This went on for about a year. After that was fixed, or so they say my relatives started noticing their Internet slowing down towards the night time hours. Towards the last few months of their service with Verizon being active the connection got to the point where it was nearly unusable at night, and PPP sessions would drop. I found out the circuit to the remote my relative was running through had been running at >90% capacity for a good handful of days each month. Their Ping Plotter looked just like yours too.

As on the previous page you posted some horrible ping results, I wonder if this is in fact a connectivity issue back at the DSLAM. If connectivity is having problems you won't lose sync but you will lose all connectivity that must transit back to the Central Office and isn't hosted locally by equipment at the DSL source. I don't know if you'll explicitly see ATM errors when this happens but if this is an IP DSLAM, you won't see that happen anyways due to the conversion from IP --- ATM at the DSLAM itself.

reply to wchill09
What Smith mentioned: "a circuit should not be encountering an issue that often. Anyone nearby you seeing the same issue at all?"

I think that's the nail on the head..any of your neighbors having the same problem?

Depending on how the various circuits make it back to the local aggregator and then to the POP, more people than you should be having similar issues. It IS possible that traffic out of your CO may be routed to more places than just one, yours being the circuit more impacted by the problem than the others.

I'd bet that this is a known problem and may be symptomatic of good ol' fashioned congestion...

reply to COjosh

That second hop would be the aggregator, the third being the virtual interface at your region's POP...I think that's the way it goes...

During this screen shot of your outage, those two points are the problem.

I would say that it's a card issue on the aggregator, not the local RT. No way to tell from the outside if the problem is w/ the physical circuit or the hardware itself.

What's funny about this is that the help desk tech that you speak to on the phone should be able to see the loss of connectivity at Layer 3 and escalate the problem to the MCO...which is essentially Tier 2 or whatever you want to call it...

Has the field tech ever contacted anybody on the phone regarding your problem? I'm sure he did when he changed ports for you but I'm talking about since then. I highly doubt this is anything an FT can fix.