Print

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

[notaclue]

The SNR appears to take a hit (but only on the download this) on a test commenced at 22:00. (I do not know what the happened in between the 2 dial back tests as there appears to be a drop between them)

The connection has been dropping much more frequently than this graph would suggest and as evidenced by the Attenuation Log?

Code: [Select]

Down Up

19 Jul 2014 13:42:30 28.0 35.6
19 Jul 2014 13:45:05 28.0 35.9
19 Jul 2014 13:49:05 28.0 35.0
19 Jul 2014 14:06:05 28.0 35.2
19 Jul 2014 14:14:06 10.5 4.9
19 Jul 2014 14:34:05 10.5 5.0
19 Jul 2014 14:37:05 28.0 34.8
19 Jul 2014 15:21:05 28.0 32.8
19 Jul 2014 15:37:05 10.5 4.9
19 Jul 2014 16:05:05 28.0 34.8
19 Jul 2014 16:06:06 28.5 34.7
19 Jul 2014 16:09:05 28.0 34.7
19 Jul 2014 16:25:05 28.0 34.1
19 Jul 2014 16:28:05 28.0 34.2
19 Jul 2014 16:37:30 28.0 33.8
19 Jul 2014 16:43:29 28.0 33.3
19 Jul 2014 16:46:29 28.0 34.2
19 Jul 2014 16:51:30 22.0 7.3
19 Jul 2014 17:01:10 26.5 27.0
19 Jul 2014 17:10:09 26.0 25.8
19 Jul 2014 17:12:10 10.5 4.9
19 Jul 2014 17:58:09 26.5 26.7
19 Jul 2014 18:15:17 10.5 5.0
19 Jul 2014 18:17:10 27.0 30.0
19 Jul 2014 18:22:10 27.5 30.6
19 Jul 2014 18:29:10 10.5 4.9
19 Jul 2014 18:37:09 10.5 5.0
19 Jul 2014 18:46:09 10.5 5.1
19 Jul 2014 18:52:09 10.5 4.9
19 Jul 2014 19:16:09 10.5 5.0
19 Jul 2014 19:18:10 10.5 5.1
19 Jul 2014 19:33:10 11.0 5.2
19 Jul 2014 19:46:09 27.0 28.9
19 Jul 2014 19:55:09 27.0 29.9
19 Jul 2014 20:42:09 10.5 4.9
19 Jul 2014 20:47:10 27.0 30.2
19 Jul 2014 20:49:10 11.0 5.3
19 Jul 2014 20:56:09 27.0 30.9
19 Jul 2014 21:15:09 27.5 31.8
19 Jul 2014 21:22:39 10.0 4.7
19 Jul 2014 21:29:09 10.5 4.9
19 Jul 2014 21:43:09 10.5 5.0
19 Jul 2014 21:44:54 27.5 31.2
19 Jul 2014 21:47:10 27.5 31.3
19 Jul 2014 21:49:40 27.5 31.4
19 Jul 2014 22:01:24 10.5 5.0

The connection speed is related to the attenuation, the lower the faster?  (Which I have included as reference.)
I have also included a HLog for konardo5.


With regards to the DSLAM and Annex_M, wouldn't it eventually be handed out if the connection was stable enough? (I am led to believe this happens with fast path and interleaving?)

[kitz]

I will grant you that fact. But please remember, it is not a "hard and fast" science -- it is more of a "black art". If we take another look at the recent SNRM graphs that notaclue has posted, both DS and US have "taken a big hit" when the ringing voltage was applied to the circuit.

Thank you b*cat.  Exactly!   
Perhaps I should have expanded more for those that didnt realise -  when I said tones 40-80, this range encompasses and spans both upstream and downstream frequencies.

As to Annex M . . . doesn't it need to be configured at the DSLAM/MSAN?

Yes its set as an available profile on the MSAN..  which can then be selected via the CPE.   When I was on annex_M, I could toggle it on/off via my router.
Selecting annex_m means you get different psd masks etc. 
Most routers will auto-select it - presumably because the order of priority will be set on the MSAN.   

[kitz]

And that is fairly conclusive evidence of either a HR or semi-conducting joint.

What about Hlog? notaclue fault is visible on Hlog. But you have said HR faults are not noticable on Hlog. Defected joint cause temporary signal reflections?

Best regards
konrado5

Good god Konrado give it a rest will you please.  Ive been trying to ignore you, but you arent adding anything other than nitpicking mine and b*cats posts.   Get this - there is no hard and fast rules with adsl.  You have to look at the wider picture and not just focus on individual items.  Quite often dsl diagnostic's is having a feel for things and a gut instinct that only comes by years of reading line stats.  B*cat knows his stuff and is pretty damn proficient at line diagnostics.

[burakkucat]

And that is fairly conclusive evidence of either a HR or semi-conducting joint.

What about Hlog? notaclue fault is visible on Hlog. But you have said HR faults are not noticable on Hlog. Defected joint cause temporary signal reflections?

It is true that the two partial HLog plots do not "look right". It is also true that there is a defect in the circuit which, given access to the pair and sufficient time to perform some tests, a competent person should be able to trace and fix.

But (and it is a very big "but") fault-finding is not a pure, logical, science where "if it is not black it is therefore white". Fault-finding is far more of a mysterious art, where experience counts and every aspect of the overall picture must be taken into account. Black Sheep has said (on more than one occasion) that remote fault-finding by means of symptoms posted to a web-site is a very poor substitute for physical access to the circuit in question.

Edited to add: Konrado5, I appreciate that you have a very special ability to focus upon very minute aspects of a problem. And that ability is, undoubtedly, a gift. But when one is considering a potential or observed problem with an xDSL circuit such minute attention to detail is actually a hindrance. One has to accept the probabilities, be able to "feel" what seems to be shown and then perform an estimation as to what the problem may well be. Once the fault has been found and fixed, one then takes that fact into consideration when attempting to analyse a newly reported problem. Sometimes things are because they are. (Or as I have said in the past, on average things will be average.    )

[konrado5]

It's bad that TDR devices are very expensive and I can't do TDR of my line because I have not got fault, I have only anomalies. But I'm very curious.

[roseway]

It's bad that TDR devices are very expensive and I can't do TDR of my line because I have not got fault, I have only anomalies. But I'm very curious.

Konrado, we know very well that you're curious. But this thread is not about your connection, and the minutiae of your connection has already been discussed to death. Leave it there.

[kitz]

The connection has been dropping much more frequently than this graph would suggest and as evidenced by the Attenuation Log?

DSLstats records the Signal attenuation, which can and does change on the fly if there is sufficient enough of a problem. 
Line attenuation is measured only during the Sync phase

~ What is the difference between Line Attenuation and Signal Attenuation?]

The connection speed is related to the attenuation, the lower the faster?

Yes in theory.  But attenuation is just actually a measurement that gives an indication of line length and condition.  Its not unusual to see very small fluctuations, but when you have a line fault such as yours, certain theories go a bit out of the window
Your upstream attenuation is way off.  In theory for a good line upstream attenuation should be approx half of the downstream.  The fact that your upstream attenuation is more than your downstream shows that upstream frequencies are being very badly affected too.

With regards to the DSLAM and Annex_M, wouldn't it eventually be handed out if the connection was stable enough?

Yes -sort of.  It has to be made available as a profile, but in your case there are insufficient tones available in he upstream to make use of Annex_M, so it automatically wont select it.

[burakkucat]

It's bad that TDR devices are very expensive and I can't do TDR of my line because I have not got fault, I have only anomalies. But I'm very curious.

Yes, I appreciate that. The Tester 301C that I own cost me £47 in an eBay auction, if I remember correctly. It is a very basic device with sufficient functionality to perform the required tasks.

To purchase either an Exfo AXS-200/635 or a JDSU HST-3000c as a refurbished second hand item would cost me thousands of pounds! Money that I could not afford to spend . . . especially on just a hobby! 

[notaclue]

Thank you everyone for your input. Would raising this issue via the bt forums be a more reliable way of getting this fixed than phoning 150?
I'm apprehensive of doing so because of the possible costs incurred. If I replicate the SNR M changing when it receives a ringing voltage be enough to prove to any engineer that there's a problem that he can fix and won't charge me for?

Am I being silly in thinking theres not a graph showing the signal attenuation (Since why would there be one as there generally shouldn't be a problem).
So when it syncs at 10.5D/5U that's the best available? Which makes me curious as the download is higher than the upload, is that normal?

As a side note I guess; for the price of one of those fancy testers you could buy a couple of bonded lines and pay for a few months too (Not an entire term though). Speaking of which, I am planning to get a 2nd line with a different provider will I suffer the same fate as I currently am. (I am going to fix the issue first before getting the 2nd installed.)

[kitz]

Would raising this issue via the bt forums be a more reliable way of getting this fixed than phoning 150?

Whilst this is IMHO a telephone (voice) fault and should be reported via 150.  The impact on your adsl appears to be more of an issue and more easily provable that there is a problem.   If it were me and faced with your concerns over the possibility of a charge, I'd probably phone up BT and report it as a broadband fault.   Your ISP should easily be able to see that your were previously able to sync at 2Mb and now you are getting a pitiful 339 upstream.  The changes in SNRm seem fairly easy for you to replicate - and although I doubt the person on the phone at BT will understand what you are on about, any half decent broadband engineer should be able to see and replicate this too.

It would be nice if all BT Openreach engineers understood the benefit of programs like DSLstats and make use of them.  There are some like BlackSheep who do.  Ive shown a few BToR engineers my graphs and all of them were interested in its capabilities.   We are making slow progress - some ISPs such as Plusnet will accept evidence from DSLstats and HG612_modem_stats as proof of a fault.   

Am I being silly in thinking theres not a graph showing the signal attenuation

No it doesnt graph in dslstats - its just a logfile.   hg612_modem_stats graphs it.  Perhaps its something Eric could put on his very long a-round-tuit list, but you are correct that normally its not worth it because it doesnt hardly move.

So when it syncs at 10.5D/5U that's the best available?

Sorry Im not sure if I understand that question.   In the past youve sync'd at much higher speeds, so no its not the best available to you.  Your sync speeds are fluctuating all over the place.  It will sync at the best it can for the prevailing line conditions.

Which makes me curious as the download is higher than the upload, is that normal?

Yes - its why its called Asymmetric DSL.   Normal adsl2+ (annex_a) is limited to circa 1.2 Mb.  Annex_M borrows some of the downstream tones and can give a maximum upstream of 2.6Mbps.   Downstream maximum for adsl2+ is 24Mbps.

I am planning to get a 2nd line with a different provider will I suffer the same fate as I currently am.

Hopefully not - but it entirely depends on how the 2nd line is provisioned.

[burakkucat]

If the audible noise is now constantly present, I would be inclined to report it (via 150) as a noisy telephone circuit -- "Can you hear that crackling?" -- and do not make any mention of the broadband service (as to do so will only give Beattie India room to "wriggle" and prevaricate).

[notaclue]

My hearing might be very different to an automated systems, will it pick it up the noise if I hear it? (Isn't there an 0845 service where can phone you and record the call? Specifically for this purpose?)

I had a period of less than audible than before noise, which I think is the period the SNR M was at 17db. (I have zero clue as to why this happened.) I picked up the phone as I had noticed the SNR M had risen, when I did this the SNR M started to drop. (I have attached a graph.)

If my line is less than 500 metres (If my line is exchange only and the building is less than 50 metres away in a straight line, I would be confident is saying it should be less than 500.) long should I expect these SNR M's? (But as there's a possible line fault it could be anything!?) And shouldn't I of been getting speeds greater than before the issue increased exponentially.

I greatly apologize for my obtuse question, I currently cannot think of a better way to word my question. 



Update: Left DSLstats running over night. Here's the SNR M, it looks very strange?

[boost]

You have crackly pops wit the faceplate removed and only a corded handset attached to the test socket. You could go one better and try a second corded handset to rule this out but you already have a second piece of equipment suffering; your modem.

On that basis alone you could log a line fault with 150.

Of course, there's a small chance someone will attend and NFF you but given how bad your stats are on both legs, I would hope this would be glaringly obvious to any half tidy line tech.

Your other option is to push it to your ISP who will log it out on your behalf and the onus is firmly on them to prove it. I have seen LTOKs for poor performers but I would be surprised if this one passed given your HLOG.

Your likely path of least resistance is to call your ISP and say 'Internet is crap, please investigate!' Nobody cares about SNR because it's not exclusive to copper issues so probably not worth mentioning unless asked. Your HLOG might help, *if* they ask for more info but they can probably pull one off the line with a DELT anyway.

Your likely quickest resolution is log a PSTN fault for pops/clicks/bangs - don't mention Internets.

I realise this doesn't directly answer your question but sometimes the real goal is 'how do I get my blatant line fault/Internet fixed without getting slammed with bs charges'

[notaclue]

I phoned BT Broadband support as I felt I had more chance proving there is something wrong. However they tell me nothing is wrong and they will call me back in 2 days time (On Wednesday). I think I'm being perhaps led around a ring.

I think I'm going to be stuck with this connection as it is. I think I'm going to need to escalate it to someone whose not in a random Indian call centre.....

(I left DSLstats while I went to work and I think it quite clearly still shows there's a problem.)

Sidenote: It appears it only shows the dslam information when "ppp debug mode" is enabled on the router.

Code: [Select]

DSLAM/MSAN type:        IFTN:0x71c8 / v0x71c8


[boost]

IFTN:0x71c8