Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bald_Eagle1]

As some of you are aware, my connection appears to have managed only 1 month of stability until FTTC & telephone services were both suddenly "accidentally" cut off for 4 days back in July 2011.

Ever since then, unlike most other users’ FTTC connections I have seen, I have been unable to maintain a connection for more than a few days at a time.

Along with this general instability, I occasionally lose my connection simply by picking up a telephone handset ready to make a call, or when the phone rings.

SNRM drops by as much as 7dB & when the norm for my connection appears to be around 6dB, a drop of 7dB causes a disconnection.

When my connection is behaving itself, I can use the telephone with only a 0.1 or 0.2 dB drop in SNRM.
I imagine these are perfectly acceptable & normal levels.

This particular issue usually only lasts for a couple of days, thus making identification & rectification work very difficult for any visiting engineers as their basic line tests usually return a LTOK result.

However, as it has now been ongoing since 25th March, I am hopeful that yet another engineer’s visit, about to be arranged by Plusnet, will now be able to identify the cause & effect a remedy, thus restoring my connection’s initial stability & decent Sync/throughput speeds.


To try to understand what may be causing these intermittent issues, I have selected the band plan (D2 band) where the issues appear more prevalent & have plotted the data accordingly.

I have cross-referenced my data with information provided in a number of JDSU documents, as that is one of the main tools currently used by BT OR engineers.

This is just one example JDSU document:-

http://www.jdsu.com/ProductLiterature/sctpsbridgedtap_an_tfs_tm_ae.pdf


I have put together my own PDF document, showing a few example stats of when the connection looks fairly reasonable & when the issue(s) can be seen graphically.

The symptoms exhibited by my connection do have some similarities with the examples from the JDSU documents.

My document is located here, if anyone fancies a read/comment:-

Bald_Eagle1's Example Stats

Grabbing the stats while the issue(s) is/are evident has not been easy due to the intermittent nature.

I am hopeful an experienced & specialist engineer will have much more success than I, especially if he/she will actually take a quick look at my example connection stats, that in my mind do prove that a repairable issue does actually exist.

One aspect that I have so far been unable to determine is the likely distance of the "problem(s)" from my master socket.

If you recall, a long time ago, one engineer removed a double-jumpered connection inside the cabinet.
The engineer was convinced he had resolved the issue(s), so the line wasn't retested to check, or to test for any further issue(s).

The removal of the double-jumpering had very little, if any effect - see the attached IP Profiles graph.
 
Despite me repeatedly requesting them via Plusnet, not one other visiting engineer has been instructed to (or been willing to) conduct another TDR test since.

The net result of these intermittent issues is much reduced Sync & therefore throughput speeds, frequent & random disconnections, & a “stuck” DLM Profile.
Currently my DLM Profile appears to be stuck again, at 24999 k, giving me an IP Profile of only 24.2Mb as reported in BT's Speed test & as calculated by the 96.79% method (24196.5 k).


EDIT:

I would just add that sometimes my connection is so poor that I get absolutely nothing from the D2 band (Attenuation too high or SNR too low?)




[attachment deleted by admin]

[les-70]

 I am no expert but had similar experiences but with ADSL2.  All was solved when a faulty filter in the master socket face plate was replaced.  I expect that you have tried this so apologies if this not a very relevant reply.

[Bald_Eagle1]

I have no means of testing the master socket's inbuilt filtering so a fault there can't be ruled out.

I currently have the faceplate & all extension wiring removed, with just 1 phone plugged into the test socket via a dangly filter.
The HG612 modem is still connected to the dedicated VDSL2 socket.

The whole master socket & faceplate were replaced when my drop wire was replaced/rerouted in November.

[les-70]

 Since you have already had the master socket replaced I doubt that the fault is in it. 

 However in my own case complete removal of the faceplate - a filtered faceplate including the filter - was needed.  A new filter straight to master socket was fine but an extra filter on the faceplate telephone extension did not help at all, I think that is what your using.   You may like to try going right back to master socket by removing the VDSL filtered faceplate altogether. I don't have  VDSL but I think if your still using the VDSL2 socket I think the inner socket is still filtered and not a master socket.  You need to remove the next section to get back the master socket.  VDSL works fine with ordinary adsl filters although a good one is always best.  Thinking it the best I had an ADSL Nation faceplate, but the active transistor components in that may have scope for real trouble if they have a fault.  I replaced it with a Pressac one, the same as the BT ADSL filtered faceplate.  The change in stability was dramatic.

   Good luck - reading back over your posts something is clearly loose or faulty somewhere!

[les-70]

   I notice from your other posts that after an engineers visit there is some improvement.  If it reverts to what is bothering you, perhaps you may like to try removing the VDSL filter layer from the NTE5 and going right back to master socket (and using a separate ADSL filter if you need the phone to work). It probably won't help but given your persistance it may be worth a try.
   
  Otherwise I think monitoring Hlog and QLN graphs is wise.  I am trying to improve my understanding of  Hlog graphs.  I wonder if the sharp dip in yours (in your other posts under -Distance from the Cabinet - Realistic speed estimate) is more like a peak of noise than anything else.  The matching QLN should be guide. 

  Hope it does stay improved.

[Bald_Eagle1]

The separate Bit-loading, SNR, QLN & Hlog graphs are included in my document linked to in the earlier post in this thread.

At the frequencies in question, my signal attenuation is already very high, so it doesn't take much of a difference anywhere to stop bit-loading.

I have noticed peaks in the QLN graph, dips in the SNR graph, increased attenuation in the Hlog graph & a lack of bit-loading, all at the same tones & at the same time.

What I'm not sure of is what is causing all 4 items to exhibit the issue at the same time.

High attenuation will decrease SNR, but do high noise levels increase signal attenuation?

My gut feeling is that these are symptoms of a physical issue such as a dodgy joint possibly arcing, thus the signal can't get through with sufficient strength (high attenuation).
As an arcing joint will also introduce electrical noise spikes, that could explain the QLN spikes & together these will cause reduced SNR & bit-loading.

Yesterday, the engineer did 3 things, any one of which or a combination of which may have been the cure for my SNRM levels dropping (occasionally enough to cause a re-sync).

Simply cleaning up & remaking the joint in the cabinet may have been the cure.

The engineer TDR tested my connection from the cabinet & gave it the all clear before visiting my home.
It may just have been more informative to have firstly TDR tested from my home?

Replacing the filter parts of the faceplate may have been the cure.

Stripping back the drop wire insulation & remaking the connection may have been the cure. If is was weak (thin) enough to have simply snapped off, maybe it was struggling anyway.

The dropping SNRM issue has surfaced 3 times (that I am aware of).
Each time, an engineer's visit has resolved it (for a month or so).

My connection re-synced early this morning, but there is no statistical evidence in any of my logs to explain why.

[waltergmw]

@ Paul,

As we still have comparatively little evidence even including our VDSL circuits down here, perhaps we shouldn't overlook the possibility of the modem's processor being overloaded or possibly just hitting a peak load ?
I wonder if that might cause or affect the simultaneous disturbances you observe ?

Any comments Asbokid ?

Kind regards,
Walter

[les-70]

 Walter is right to question the integrity modem.  Overheating is another possibility even with a newer modem.  A fan was found an effective fix by some  people with an overheating  problems.  I have seen set ups with silent 8cm or smaller 12v fans cooling modems and other heating kit.

[Bald_Eagle1]

Hi Walter,

As we still have comparatively little evidence even including our VDSL circuits down here, perhaps we shouldn't overlook the possibility of the modem's processor being overloaded or possibly just hitting a peak load ?
I wonder if that might cause or affect the simultaneous disturbances you observe ?

I have seen stats for quite a large number of connections now, ranging from super speed attainable rates over short distances of up to 400m to low speeds (16Mb or so) over long distances of 1600m.

In the vast majority of cases, the modem appears to have coped very well, exhibiting very stable connections for many days at a time.

Even on the 80Mb/20Mb trials some users are seeing sync speeds of 70Mb+ with stability over many days.

A few users on the trials are however seeing a few re-syncs & variable throughput rates.
I suspect that is more due to physical copper line conditions and/or contention than a modem issue.

The HG612 is apparently 30a (30MHz) compatible. I can only assume it has been fully tested at those frequencies & associated speeds.

So, at 17a frequencies, I imagine the modem has plenty of spare capacity, the earlier faulty "overheating", now being replaced with version 3B modems.

I have a version B & a version 2B modem, neither of which overheat.
The performance of each modem appears identical, both exhibiting the same connection issues (and occasional but rare stability), which again, I put down to the physical copper conditions rather than modem issues.

Cheers,

Paul.