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.