Line stability issues and line statistics advice

Hi all,
I've had BT Infinity (business option 2) for a few days and since day 2 it has gradually been getting worse. I was originally using the supplied Openreach modem and Business Hub 3, however due to the sudden lack of connection speed (dropping from 76Mbps~ download to about 0.3Mbps~ download, if that) and having to resync I thought it would be one of those causing it.

So I tried my Cisco 887VA directly in the data port and it produced the same symptoms as the OR modem and Business Hub 3, but this time I was able to notice that I had massive spikes of HEC and FEC errors (ranging from 10,000 to 40,000 per second). These spikes didn't occur most of the time, only suddenly, most of the time I was lucky to get about 1 error a second.

I've tried the following to eliminate possibilities that it's something internally here:
- Changed modem and router
- Changed RJ11 cable
- Changed LAN cables (rediculous but I did so anyway)
- Changed cordless phones to corded phone
- Moved all electrical wires or equipment (except the modem) away from the master socket
- Checked the wiring
- Tested 17070 #2 (Quiet Line Test) on the corded phone (no noise noticeable)

Since Saturday it has been raining off and on, and ironically since then it has managed to go worse each time it synced. Until this morning about 1am I was unable to keep a sync for more than one hour before the FEC/HEC errors spiked massively and not recover unless I disconnected and reconnected the RJ11 cable. This morning at roughly 5:30am interleaving depth was introduced by DLM, though I didn't see any HEC/FEC spikes cause that this time. Since then I've noticed only a small amount of FEC/HEC errors on the GUI and graphs, but a massive amount of RSCorr instead.

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? Interestingly FEC on the telnet connection shows a massive value compared to the web GUI value given.

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

I've obviously unlocked the OR modem so I can see this. Everytime I re-sync the noise disappears, for a while, then returns. I still think it exists looking at that FEC count on interleaving, but interleaving is managing to filter it out.

Log this with BT

Ok, how should I word this? Obviously I'm not meant to unlock the Openreach modem to find these horrid errors in the line stats. Do I just simply say everything I said except mentioning the error counts? E.g. I changed phones, tried another Openreach modem (borrowed from a friend), tried my router via the OR modem instead of the Hub, etc. etc?

Oh, and should I lock it before I call them?

Edited by Ixel (Wed 13-Jun-12 12:31:59)

Hi from J-in-Bristol.
I turned on this morning and have found very slow speeds - down from 2314 to 529 Kbps.
(Sorry but I do not know any of your tecnical terms)
I have since rebooted and have been able to get a web page up but it all just seems slow this morning.
I have BT broadband
I thought that I would get my two hapensworth in!
J-in_Bristol

Thanks for the reply but I'm using Infinity FTTC, not ADSL broadband.

Any suggestions from anyone about how I should word this to BT Business?

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?

In reply to a post by Ixel:

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?

How did you measure the "sudden lack of connection speed (dropping from 76Mbps~ download to about 0.3Mbps~ download, if that)", because those stats look pretty good.

They show that you are on an ECI DSLAM, syncing at 96Mbps, with throughput capped at 80/20Mbps. Many people would chew your arm off to have a connection like that.

The FEC count might seem huge, but it has to be viewed in relation to the number of data frames transmitted and received. And empty frames are sent even when there is no layer 3 traffic. And those empty frames are still checked for errors. So the error counters will keep on rising, even when there's no internet traffic to/from your PC.

Since you've had FTTC for only a couple of days, maybe give it a bit longer to level out. Hopefully it will turn out that you're one of the 'worried well'

cheers, a

Edited by deleted (Wed 13-Jun-12 17:34:38)

Hi,
Thanks for the reply .

Before interleaving depth increased (which I hate as I'm a first person gamer too, but at the current level of interleaving I can tolerate it) I found when I had a sudden burst of FEC's and HEC's (10k - 30k in an extremely short period of time) it rendered the downstream almost unusable. Ironically the upstream and ping wasn't effected. In order to restore my connection I found disconnecting the RJ11 cable and reconnecting it made it work again, for a while anyway. Strangely the noise virtually disappeared when this was done, as you can see from the HEC/FEC error graphs for last night at 11pm and 1am. If I didn't intervene the modem didn't automatically lose sync and re-establish.

Now interleaving is enabled, the line appears stable, but I thought that it might also be masking a line problem, I suppose I'll only know this as and when DLM reduced the interleaving depth back to 1 (OFF).

My original attainable rate on Friday, Saturday, Sunday and part of Monday was around 103Mbps~, but since then has gone down a little (not a big problem though as I can see). I'll go along with this 10 day thing I keep hearing about, though from my understanding I thought the DLM constantly monitors the line anyway.

Finally, in regards to the FEC count, as I say, before interleaving depth was increased this morning about 5:30am I found the connection became unusable when I had a huge burst of them come in. As soon as I disconnect and reconnect the RJ11 cable it goes back to normal. Hmm, I'm confused . I found analysing ADSL errors was far easier.

I forgot to say that I'm more than happy with the connection when it's stable, but there are, or were (before interleaving depth increased) occurances where it was unusable until I disconnected and reconnected the RJ11 lead. On the day it was installed, Friday of last week, the engineer and myself were stunned when I said my estimate was 58/18.

Edited by Ixel (Wed 13-Jun-12 16:44:32)

Firstly, forget the error counts as reported in the modem's GUI & only rely on the stats from either direct telnet commands, or the scripts.

The GUI has a couple of known bugs in the way it reports some connection stats.

DLM may never return Interleaving to OFF for your connection (a depth of 1), but given time it may reduce from the current level.

INP & delay are also related to Interleaving/error correction. What are those values (can be seen in the plink log)?

Has Interleaving actually had a negative effect upon your gaming experience?
TBH, I would swap connections with you, right here & now if it were possible.

BTW, the next update to the scripts (expected soon) will include quite a bit more data such as errored seconds etc.

Edited by deleted (Wed 13-Jun-12 17:15:18)

Thanks for the reply.

Ok I'll ignore the FEC currently being reported, I did wonder if that was a stupidly high value (the millions of them happened after interleaving was made >1 this morning).


INP: 3.00 0.00
delay: 8.00 0.00

Interleaving hasn't had a huge impact on my gaming experience, my ping is still reasonable for my standards of gameplay online (between 25-35ms most of the time). The interleaving depth increased the ping by about 10ms, which is quite good considering.

It's interesting you'd say that you'd swap connections with me right now, if possible, because last night I doubt you would've, I was lucky to remain online for an hour before getting a sudden burst of thousands of FEC and CRC errors, where I had virtually none to worry about before that happened. But I've stated that before.

The next update to the scripts will be good, look forward to it .

I also found a reply on another forum to my problem quite interesting, but I'm still unsure whether I should call BT Business and report a possible fault. With interleaving depth things seem stable now, haven't had a problem all day today but it has also been warm and sunny. For the past few days where I've been experiencing problems it has been raining and cooler. Anyway the reply I'm mentioning is at http://business.forums.bt.com/t5/Broadband-and-inter....

Any other suggestions or what not feel free to add, much appreciated .

EDIT: I have noticed however that bitswapping is increasing on the downstream by 1 every second.

Edited by Ixel (Wed 13-Jun-12 18:20:26)

Have a look at the notch in the SNR at around tone550 ... and also at 1100. The bit loading at 2bits/tone on low frequencies is very low ...

I see, I noticed that in your reply. That does indeed look odd, I'm not sure how I could report this to BT though given my connection is stable today now interleaving depth has increased and that I'm not meant to even be able to access this sort of data anyway. If anyone has any ideas I'd welcome them.

Would it be worth me doing a line fault check via the BT website to see if it can pick something up?

In reply to a post by Ixel:

I also found a reply on another forum to my problem quite interesting, but I'm still unsure whether I should call BT Business and report a possible fault. With interleaving depth things seem stable now, haven't had a problem all day today but it has also been warm and sunny. For the past few days where I've been experiencing problems it has been raining and cooler. Anyway the reply I'm mentioning is at http://business.forums.bt.com/t5/Broadband-and-inter....

Any other suggestions or what not feel free to add, much appreciated .

If only all this wasn't such a secretive black art...........

I have well documented the FACT that my connection (when it was having fairly recent problems) performed & was far more stable during wet & cold weather, the problems only appearing during warm & dry weather.


Work that one out !!!


EDIT:

Just for curiosity, were you originally supplied with the ECI modem & the HG612 you are using to access the stats is an "addition"?

Edited by deleted (Wed 13-Jun-12 19:21:57)

I see, very strange.

No, I was supplied with the HG612 as the only modem, not an ECI variant.

Edit: I'm wondering if my master socket has a problem, other than anything external it's the only thing I haven't tested internally as I don't have a spare one to replace it, only standard ADSL microfilters or the ADSLNation faceplate, which I imagine will make the line ten times worse if I tried?

Edited by Ixel (Wed 13-Jun-12 19:40:33)

In reply to a post by Ixel:

I see, very strange.

No, I was supplied with the HG612 as the only modem, not an ECI variant.

We have been led to believe that the modem & the DSLAM should be matched for compatibility purposes.

From your band plan details we are able to confirm you are connected to an ECI DSLAM.

Other modems will work with the ECI DSLAM, but we have also seen "notches" at lower frequencies as mentioned by MHC when using "unmatched" modems..
I don't think that is a major issue, but you never know........

Edit: I'm wondering if my master socket has a problem, other than anything external it's the only thing I haven't tested internally as I don't have a spare one to replace it, only standard ADSL microfilters or the ADSLNation faceplate, which I imagine will make the line ten times worse if I tried?

I recently diagnosed a faulty OR supplied VDSL2 faceplate by using a standard ADSL dangly filter plugged directly into the actual test socket (OR VDSL2 faceplate completely removed).
Instantly, my connection's SNRM levels stabilised & I was able to use the phone again without causing a disconnection.

So, yes. by all means try out an ADSL microfilter. I can assure you that they do work O.K. wiith FTTC connections. You MAY even see an immediate improvement.

BT OR are currently trialing microfilters with a view to eventually making FTTC a self-install service, pretty much like a standard ADSL connection.

In reply to a post by Bald_Eagle1:

So, yes. by all means try out an ADSL microfilter. I can assure you that they do work O.K. wiith FTTC connections. You MAY even see an immediate improvement.

BT OR are currently trialing microfilters with a view to eventually making FTTC a self-install service, pretty much like a standard ADSL connection.

They "work" but the ADSL filters are not wonderful at the higher frequencies on 17A and may present strange impedances which can affect the signal with higher attenuation or distortion of phase.

Could be worth seeing if it changes that notch!

Another update.

Call me paranoid but the line is becoming worse again, and this time it's evident.

Look at the latest line graphs and see how erratic the SNR is becoming, up and down like a yoyo! http://i.imgur.com/jvipy.png

I'll change the faceplate shortly and hope to see improvements, otherwise it will have to be flash back to locked firmware and a phone call to BT tonight, assuming business support work at these hours.

Edit: With the current state of the connection I'm barely able to get a speed of 8Mbps through anywhere except the BT speedtester site which claims I have about 50Mbps or so throughput on the DL.

Edited by Ixel (Wed 13-Jun-12 22:49:18)

Still early days! You don't strictly need a filter at all. For maximum line liberation, maybe go commando and plug the Huawei into the test socket behind the faceplate.

cheers, a

Switched faceplate to ADSLNation XTE-2005, but this improvement could mean anything at the moment in my view. The connection always fully restores after reconnecting the RJ11 cable for a while, then degrades to a point where it becomes virtually unusable.

Line State
---
Just before I changed faceplate: http://i.imgur.com/aRkuJ.png
After I changed faceplate: http://i.imgur.com/nfRSi.png

Considerable difference with the return of the lower tones. Wonder if this will last or whether it was indeed a faulty faceplate that Openreach installed.

Input anyone?

You are still getting an impressive 80/20Mbps throughput. The absolute maximum throughput for that particular Openreach VDSL2 service.

In the second of those two sessions that you have graphed, the throughput is achieved by a different bit loading profile. Loading is higher in subcarriers further up the bandplan. Since you're still getting 80Mbps, it's not cause for complaint.

The spectrum management of the ECI DSLAMs, is distinct from the management in the Huawei DSLAM. The ECI seems more dynamic - as we can see here. Not a fault. More of a feature, perhaps.

During the negotiation for the second session, the background noise in downstream band D3 was measured as slightly lower than in the first session. Consequently, the DSLAM controller decided to utilise the extra SNR in those tones by loading them slightly more.

That would provide relief on the lower tones, which could be an advantage: it is likely to reduce crosstalk for ADSL (and other VDSL2) subscribers whose broadband service is provided in the same D-side cable bundles as your own.

Otherwise, the two sessions look very similar. In particular, the line attenuation characteristics - evident from both the Hlog graphs and the raw numeric data - are essentially unchanged between sessions.

The notch (or trough) in the SNR graph (and in the bit loading graph), centred on DMT#500, is a result of that spectrum management. The notch is not caused by line noise since that would manifest in the QLN graph.

On the basis of those graphs, I would be very happy with that service. If you're experiencing connectivity issues, that's perhaps caused by a problem at a higher layer of the communications stack.

cheers, a

Edited by deleted (Wed 13-Jun-12 23:49:00)

My thoughts on the dip at tone 550 is that there is also one at the second harmonic tone 1100 (both approximate). And I ask why the modem would work in that way when it knows it can get better bit loading on lower tones (normally).

Well the dip around 1100 still remains, and I've had a slight increase in interleave depth this morning as well as a sync speed reduction. Since changing to the ADSLNation faceplate the connection hasn't become troublesome as yet, but I'm waiting to see what happens again this evening, for rain, or hopefully a 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, ideally I should leave it for several more days and see how the connection performs though right? Then if things still get worse (further actions taken by DLM in reducing the sync and/or raising the interleave depth) I report a fault to BT Business?

Here's the latest two graphs depicting tones, errors and such for the last 24 hours:
- http://i.imgur.com/LhTLX.png
- http://i.imgur.com/3JWWE.png

Thanks for everybody's input , I really appreciate it!

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 began 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.

The connection hasn't become unstable yet however, though I'm sure without interleaving it would be unusable by now. I'm suprised however that the loss of the lower end tones hasn't effected the attainable rate or SNR values. I'll keep monitoring it, interleaving at the current depth is tolerable for gaming still, at least for me anyway.

I'm using JD's auto speed tester which runs a speed test every 15 minutes and graphs it, if that suddenly gets a sharp decline I'll know the problem is back in full force.

Edit: I also expect that if I disconnected and reconnected the RJ11 cable the lower end tones would return to normal and I would have no RSCorr's for a while.

Edited by Ixel (Thu 14-Jun-12 20:13:46)

If anyone is still reading this thread, I believe the lower tones is a false reading, though at this time I can't fully confirm that assumption. My reasoning behind that is the SNR is hardly wavering like it was on the original Openreach VDSL faceplate, it's been stable for over 24 hours, and although the RSCorr is through the roof I also believe that is giving a false reading. I'm mostly relying on RSUncorr, CRC errors and HEC errors values, which aren't too bad. Interleaving depth is still on obviously, but if it goes off I'll get a better idea of whether the line is broken or currently hiding most of the problems it originally started showing.

Also I believe the lower tones suddenly disappearing/minimising on the lower end is false reading because I would imagine that the 'Signal-Noise Ratio' tone graph would also be effected, but it's not.

If anyone is still monitoring this thread then am I right in this assumption?

In reply to a post by Ixel:

Well the dip around 1100 still remains

"The dip"? That trough in the Bit Loading graph? Specifically, the bit loading levels in upstream band U1?

The upstream DMTs only need to be bit-loaded up to the upstream limit of the profile (20Mbps). Your connection is very good, and that 20Mbps upstream limit is soon achieved by bit-loading (modulating a signal) on the higher tones. That frees up those lower tones, which is why they are shown as unused in the Bit Loading graph. It may sound counter-intuitive but that is a good thing. It means your line is in good condition.
.

In reply to a post by Ixel:

If anyone is still reading this thread, I believe the lower tones is a false reading, though at this time I can't fully confirm that assumption...I'm mostly relying on RSUncorr, CRC errors and HEC errors values, which aren't too bad...Also I believe the lower tones suddenly disappearing/minimising on the lower end is false reading because I would imagine that the 'Signal-Noise Ratio' tone graph would also be effected, but it's not. If anyone is still monitoring this thread then am I right in this assumption?

Those very low error counts indicate that you have an excellent line.

The ECI DSLAM uses a different Bit Allocation algorithm to the one currently used by Huawei. That is why those lower tones remain unused in your line. ECI (being Israeli) is using a Be-Nice-To-Your-Neighbour policy in its Bit Allocation algorithm.

That means that where possible, the ECI DSLAM loads the higher DMTs first. It does so because neighbouring pairs in the same cable bundle may not be as capable as your line at carrying those higher frequency signals.

And therefore, for poor quality pairs, the lower frequency tones *must* be used. But if those lower tones had been allocated unnecessarily to your connection, that would have added to crosstalk problems for others. So it's a case of give-and-take in the spectrum management. Which is being done intelligently by the ECI DSLAM controller software so that everyone can enjoy the best service possible. That is not a fault.

In reply to a post by Ixel:

My suspicions lead me to believe the master socket Openreach fitted is faulty, ideally I should leave it for several more days and see how the connection performs though right? Then if things still get worse (further actions taken by DLM in reducing the sync and/or raising the interleave depth) I report a fault to BT Business?

I'm beginning to see the logic in locking modems now! You are one of the Worried Well!

cheers, a

Edited by deleted (Fri 15-Jun-12 18:03:45)

Very low error counts? If you've looked at the previous graphs I've submitted in the past you'll see in one or two of them that the CRC errors spike upwards, or maybe I forgot to post those. At the moment the line is stable, but I suspect interleaving is taking care of that, or perhaps the fact I've changed the faceplate if the OR one was actually faulty.

Example: http://i.imgur.com/jvipy.png

It's interesting to know that the behaviour of the lower tones is unique to the ECI, I can see the logic behind such functionality, I'm suprised that the sudden removal of lots of bits in the lower end doesn't reduce my sync, but I guess there's something I am not realising from that. Is it natural for 1-2 bits to be swapped on the downstream every connected second? The lower end tones occasionally return for a few hours, then go again later.

Anyway, since changing the faceplate the connection has only lost sync once, after which it increased the interleaving depth a tad more. I'm hoping in the next few days it'll go down and my sync goes back up so I can determine if interleaving depth is masking a possible problem. Perhaps I'm one of the 'worried well', but forums are for asking these questions after all, and from my perspective to learn from the answers given . I appreciate your and everyone elses help.

Another question I have is, my sync is currently 73322 (was 79999 to begin with), my IP profile is currently 77.43 Mbps downstream, from my understanding the IP profile usually follows the sync speed on the downstream at about 85% of it. So my question is, based on the IP profile for the downstream would that perhaps mean if I reconnected now I'd get 79999 back? I'm not fussed at losing a few megabits, just purely a question .

Edited by Ixel (Fri 15-Jun-12 18:38:08)

In reply to a post by Ixel:

Another question I have is, my sync is currently 73322 (was 79999 to begin with), my IP profile is currently 77.43 Mbps downstream, from my understanding the IP profile usually follows the sync speed on the downstream at about 85% of it. So my question is, based on the IP profile for the downstream would that perhaps mean if I reconnected now I'd get 79999 back? I'm not fussed at losing a few megabits, just purely a question .

That looks to me like your connection has resynced "on the fly" without initiating a new PPP session. (This can happen regularly).

IP Profile only updates when a new PPP session is initiated.

IP Profile should be around 96.79% of sync speed.

So, with a sync speed of 73322, IP Profile should be approximately 70968, probably shown as 70.97Mb in BT's speed tester.

A full modem reboot would definitely initiate a new PPP session, but a "gentler" way would be to disconnect/reconnect the hub/router, leaving the modem connected.
That would NOT be seen as instability by DLM.

I imagine you are seeing lower throughput speeds anyway. I would guess at 68Mb or so maximum on speedtest.net.

This matter of IP Profile not updating every time the modem resyncs causes a lot of confusion as to why speeds are low, yet IP Profile is high.

It also causes many ISPs (& presumably also BT) to incorrectly claim that connections are perfectly stable, with very few disconnectiions shown in their own logs.

You may wish to check it out some time.

I see. Thanks. So if I disconnect and then connect the Hub (via the admin interface), not the modem, it will correct the IP profile currently seen on the BT speedtester? And presumably if I wanted to try and restore my 79999 sync I'd fully reboot the modem (but I will give it a few more days before I attempt that, so as DLM doesn't see it necessarily as more instability)?

Yes, JD's auto speed test app and speedtest.net show roughly 68 Mbps - 69 Mbps.

Yep.

That's about the jist of it.