cancel
Showing results for 
Search instead for 
Did you mean: 

Infinity is unstable

Ixel
Power User

Update:

Infinity is quite unstable now. I am using the BT Openreach modem with unlocked firmware so I can monitor the line statistics. When instability occurs I suddenly get round 10000-30000 FEC and header errors per minute, until I disconnect the RJ11 cable and connect it again, then suddenly it's fine for a short while, perhaps an hour if I'm lucky (when it's fine it produces about an average of up to 10 FEC errors or header errors per minute).

 

I'll call BT Business in the morning and see what they have to say regarding the instability I am now encountering. Strangely it's been getting gradually worse over the weekend when it's been raining. Friday, on installation day, it was sunny and had absolutely no issues at the time. I'm wondering if I'm going to become one of the group of people who regret moving to Infinity and have a fight to get things solved or at worst get out of the contract if things can't be resolved ever.


Original post:

As some of you might know (more likely MHC however), I'm using the Cisco 887VA which enables me to see line statistics. Currently I'm having an odd problem. At certain times I seem to get a rather large burst of errors on the line, I am considering switching back to the OR modem and perhaps unlocking the firmware so I can see the line statistics and make sure it's not the firmware on my Cisco causing this.

 

See stats (for roughly 1 hour and 30 minutes uptime): http://pastebin.com/Pp0de7w9

 

Note the large CRC errors in that timeframe, and the SES  (serious errored seconds) and ES counts. Now the problem is that as a normal everyday user I wouldn't see these stats nor understand there's possibly an issue, so I'd like to hear if anyone has any suggestions? I would also post this into the residential forum but they'd probably just say that they can't help as I'm a business customer, so I'm not going to.

 

I have no extensions, my router is right by the master socket. I highly doubt however that the Cisco firmware is the problem. Nothing that I'd believe that would cause random bursts of noise is near the master socket.

 

As I see it I imagine my next best step would be to swap back to the OR modem, configure the Cisco router to do PPPoE and unlock the firmware on the OR modem so I can continue monitoring line statistics, then that rules out any hardware issues here.

 

Edit: I am now using the OR modem, unlocked so I can monitor the line statistics, also in routing mode. The only thing connected directly to it is my gigabit switch, with all devices on that having manually configured IP's for now.

7 REPLIES 7

tetrapackage
Power User

You can contact them again and ask for a technician to send over your house to fix the problem. That should do the work.

Ixel
Power User

I see thanks. Before I do I better lock the modem firmware. I've eliminated everything I can think of here.

 

- Bad internal wiring (no extensions, so none)

- Faulty modem/hub (tried another modem and used my router)

- Faulty modem RJ11 cable (tried another cable)

- Electrical devices near the master socket (all moved away except modem)

- Electrical cables near the master socket (all moved except the modem)

- Faulty cordless phones (Panasonic, but disconnected and it has only resynced once (but not due to line errors however, I can't find the cause, but sadly DLM has put on interleaving now, I've connected an analog phone for today, if it's still stable I'll try connecting a new cheap set of cordless phones)

 

So at the moment, allowing for the fact DLM is now error filtering my connection (Interleaving about 5:30am when the modem lost sync, for some reason), the connection is stable. I'll put up with interleaving for now, but as a gamer this can't be the permanent solution. If however it continues I'll phone them.

Ixel
Power User

Just another update.

 

I've currently got a standard cheapo corded phone connected instead of my cordless ones. This morning I lost sync but not due to HEC/FEC error spikes (none that I could see anyway), I actually don't know why but it recovered a minute later after resyncing with interleaving delay of 8ms being applied by DLM. I'm not certain but I have a feeling the problem exists but the interleaving delay is now masking it. Could someone tell me if the below statistics appears to be normal?

 

Since Link time = 5 hours 26 min 33 sec
FEC: 74604360 401
CRC: 394 48
ES: 51 42
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

 

This is from using Openreach's supplied modem.

Ixel
Power User

Another update to provide some graphs.

 

Line analysis: http://i.imgur.com/Mtr0Q.png

Sync and errors analysis: http://i.imgur.com/OCuFw.png

 

Based on those do you think I should phone support, and lock the firmware on the OR modem again before phoning?

MHC
Guru

 

I don't think you have instability but almost certainly an external noise issue.

 

Look at the first image link ...

 

The SNR plot has a massive dip suggesting a noise source peaking at Tone 550 (about 2.4 MHz)  ... and as such almost every tone in Down1 is affected.  

 

I would expect to see bit loading up at 15 or so, not down at 2 for tones to 550 and 7 or 8 thereafter.  Down2 looks reasonable with 12, 13, 14 bits per tone.

 

The noise is causing the errors which you are seeing even though a lot are corrected using FEC and interleavng but it will contribute to te slow down.

 

There is also an issue (possibly) in Up1 - bit loading drops off to 2 from 7 and that is around tone 1100 (4.8 MHz) or twice the downstream problem area.  I would have expected better than 7 in Up1. 

 

How you address this with BT - I have no real suggestion but it might need detailed investigation.

 

 

Ixel
Power User

For those who might be having similar issues to me that read this, I'm posting a possible solution to my problems I've been having.

 

It looks like the problems I've been having are a result of a faulty master socket filter. I'm going to give it several more days and hope that interleaving depth and sync fully restore themselves, or as close as the original results I had on Friday (my first day of Infinity which was stable).

 

Since changing to the ADSLNation XTE-2005 faceplate (I had a spare) the connection hasn't become troublesome as yet, but I'm waiting to see what happens again this evening, for rain, or hopefully soon a small reduction in the strictness to the banding I'm now getting (interleave depth, sync speed) so I can fully determine if the faceplate was the faulty component causing this trouble.

Since after the swap of the faceplate last night at roughly 11pm I haven't had any SNR margin madly fluctuate, HEC or CRC errors start to rapidly rise, or a severe slowdown in throughput as a result of the errors coming in rapidly. My suspicions lead me to believe the master socket Openreach fitted is faulty. If DLM further impedes my connection or faults begin to show again then I'll lockdown the firmware on the modem and call BT Business to report a fault.

Here's the recent two graphs I took earlier this morning that depict tones, errors and such for the last 24 hours:
http://i.imgur.com/LhTLX.png
http://i.imgur.com/3JWWE.png

 

I'll keep monitoring the connection, in particular the bits per tone. Currently the bits for each tone haven't significantly changed, infact they've hardly changed at all, which is good. Over time the Openreach supplied faceplate (which I presume is faulty) showed a gradual loss of the lower end tones down to the point of about an average of 2 bits per tone. Hopefully things will remain the way they are right now and as such DLM will relieve the interleaving depth and sync decrease over the next week or so.

Ixel
Power User

Ok sadly it looks like I'm wrong, the problem isn't fixed again and is beginning to show its usual symptoms.

Here's the line graphs: http://i.imgur.com/TGw0c.png and http://i.imgur.com/8pNtO.png

The lower end tones have once again minimised themselves, and RSCorr errors are starting to creep up. Funnily enough it begun raining for the last hour or so. Do you think I'm on good ground to report a fault? It must be water/dampness getting into something external.