Register (or login) on our website and you will not see this ad.
|
|
Hi all,
I've had FTTC (BT Infinity) 18 months now. When it was first installed I was estimated 35/8 but got the (then max) 40/10 IP profile. Openreach engineer said the line was (if I remember correctly) at about 61mbps.
When I upgraded to 80/20 this time last year for about 6 months I was getting about 55mbps. Unfortunately I never saved any speedtest results so can't prove the drop conclusively. About 6 months ago Openreach disconnected me - as it turned out they were installing further up the street. I reported the fault but was reconnected about 2 hours later. An engineer still came out but took nothing more than a cursory look.
Anyway since then I've struggled to get anything over 30mbps, and a few evenings over Xmas it dropped down to 25mbps. I've finally got around to hacking the Modem and have obtained the line stats. Do they "look about right" for my line (~600m from the cab using likely cable route measured on google maps) once high take-up/crosstalk is taken into consideration or should I be having a whinge to BT?
First the wholesale checker output: Available Products
Downstream Line Rate(Mbps) | Upstream Line Rate(Mbps) | Downstream Range(Mbps) | Availability Date
Featured Products
WBC FTTC Up to 58.2 Up to 20 -- Available
WBC ADSL 2+ Up to 5 -- 3 to 7.5 Available
WBC ADSL 2+ Annex M Up to 5 Up to 1 3 to 7.5 Available
ADSL Max Up to 4 -- 2.5 to 7 Available
Now the Line stats: # xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 18089 Kbps, Downstream rate = 34848 Kbps
Path: 0, Upstream rate = 18018 Kbps, Downstream rate = 32418 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.8 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 13.1 6.6
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 64 64
R: 0 16
S: 0.2356 0.4203
L: 8151 4835
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 510804457 492541
OHFErr: 18677 2675
RS: 0 2370571
RSCorr: 0 34669
RSUnCorr: 0 0
Path 0
HEC: 17295 0
OCD: 0 0
LCD: 0 0
Total Cells: 109401197 0
Data Cells: 55594366 0
Drop Cells: 0
Bit Errors: 0 0
ES: 8591 3536
SES: 72 1
UAS: 51 51
AS: 1932692
Path 0
INP: 0.00 0.00
PER: 3.76 6.72
delay: 0.00 0.00
OR: 59.43 33.31
Bitswap: 1081858 243851
Total time = 1 days 21 hours 56 min 7 sec
FEC: 0 0
CRC: 36425 0
ES: 8591 3536
SES: 72 1
UAS: 51 51
LOS: 19 0
LOF: 10 0
Latest 15 minutes time = 11 min 7 sec
FEC: 0 0
CRC: 0 0
Thanks for reading and all feedback appreciated!
Rob
|
|
|
|
Those statistics alone look fine, but they aren't quite enough.
The "--stats" command tells us lots, but we need the remainder of the output. The lower groups of FEC/CRC/ES values are more useful than the topmost set - which lies, and gives stats for the full uptime, not the "1 day, 21 hours" it says).
We also need the output of the "--pbParams" command, so we can see the attenuation and SNR values.
What *is* present is enough information to tell us that you don't have interleaving or FEC turned on, and you aren't synchronised at a "nice" round figure. These two facts mean that DLM hasn't intervened... so whatever happened to your line resulted in one that is running without any major glitches.
The drop over Christmas, of roughly 20% of your speed, is what I would expect if DLM *did* intervene and turn on a "reasonable" level of interleaving and FEC. There is no evidence left to say whether this did indeed occur, or not.
But there is nothing yet that suggests this is a line that ought to be carrying anything like 55Mbps.
|
|
|
@WWWombat
Thanks for the response. Here's the additional output you mention.
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 17996 Kbps, Downstream rate = 34236 Kbps
Path: 0, Upstream rate = 18018 Kbps, Downstream rate = 32418 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.6 6.1
Attn(dB): 0.0 0.0
Pwr(dBm): 13.4 6.6
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 64 64
R: 0 16
S: 0.2356 0.4203
L: 8151 4835
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 514741464 212708
OHFErr: 19227 2718
RS: 0 2401834
RSCorr: 0 41922
RSUnCorr: 0 0
Path 0
HEC: 17516 0
OCD: 0 0
LCD: 0 0
Total Cells: 1037136873 0
Data Cells: 56222250 0
Drop Cells: 0
Bit Errors: 0 0
ES: 8799 3563
SES: 72 1
UAS: 51 51
AS: 1947589
Path 0
INP: 0.00 0.00
PER: 3.76 6.72
delay: 0.00 0.00
OR: 59.43 33.31
Bitswap: 1090664 245980
Total time = 1 days 2 hours 4 min 24 sec
FEC: 0 0
CRC: 36975 0
ES: 8799 3563
SES: 72 1
UAS: 51 51
LOS: 19 0
LOF: 10 0
Latest 15 minutes time = 4 min 24 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 8 0
ES: 7 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 2 hours 4 min 24 sec
FEC: 0 0
CRC: 75 0
ES: 45 22
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 2246 0
ES: 455 102
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 22 days 12 hours 59 min 47 sec
FEC: 0 41922
CRC: 19227 2718
ES: 5086 1894
SES: 14 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#
And
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 17973 Kbps, Downstream rate = 34048 Kbps
Path: 0, Upstream rate = 18018 Kbps, Downstream rate = 32418 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 17973 kbps 34048 kbps
Actual Aggregate Tx Power: 6.6 dBm 13.4 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.0 26.6 40.7 N/A 13.1 33.5 53.2
Signal Attenuation(dB): 5.0 25.5 39.4 N/A 13.1 33.5 53.2
SNR Margin(dB): 6.2 6.1 6.1 N/A 6.8 6.6 6.1
TX Power(dBm): -4.0 -16.2 6.3 N/A 10.5 7.4 5.9
#
Am I right in thinking this is the natural effect of Crosstalk then? I'm annoyed at myself for not hacking the firmware months ago, but I never expected the fall in connection speed would be so dramatic. The concern I have is will it fall even further if even more houses take up fibre? From a completely unscientific test of looking for the number of "BT Fon/Home Hub 3" Wifi access points I can see there are quite a few between myself and the cab, which is not surprising as there is no Virgin Cable in my area and ADSL2+ was ~5mbps on a very good day with the wind behind it. Most of the time it was below 4mbps.
Thanks
Rob
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
someone stole the old pair, and this one not as good?
or maybe the power has been cutback on the dsl signal.
BT Infinity 2 Since Dec 2012 - Estimate 65.9/20 - Attainable peak 110/36 - Current Sync 71/20
|
|
|
On the first bit of statistics...
Latest 1 day time = 2 hours 4 min 24 sec
FEC: 0 0
CRC: 75 0
ES: 45 22
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 2246 0
ES: 455 102
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 22 days 12 hours 59 min 47 sec
FEC: 0 41922
CRC: 19227 2718
ES: 5086 1894
SES: 14 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
The final set show you averaging 850 CRC per day, or about 30 per hour. Quite low, I think.
The first set shows this continuing for the first 2 hours of "today". The middle set shows that "yesterday" was a worse day, running near three times the average.
Overall, it seems to show good line conditions, perhaps prone to some additional bursts of errors.
MadPom's LineMax: Upstream rate = 17973 Kbps, Downstream rate = 34048 Kbps
Path: 0, Upstream rate = 18018 Kbps, Downstream rate = 32418 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 17973 kbps 34048 kbps
Actual Aggregate Tx Power: 6.6 dBm 13.4 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.0 26.6 40.7 N/A 13.1 33.5 53.2
Signal Attenuation(dB): 5.0 25.5 39.4 N/A 13.1 33.5 53.2
SNR Margin(dB): 6.2 6.1 6.1 N/A 6.8 6.6 6.1
TX Power(dBm): -4.0 -16.2 6.3 N/A 10.5 7.4 5.9
The attenuation figures look reasonable for the distance, while the SNR margin certainly looks like the sync targetted 6dB.
As an example, here are the same figures for my old line, taken 15 months ago. That line was 550 metres, but was on a 40/10 package - 80/20 wasn't available at the time, but the cabinet had already been upgraded to provide the 17a profile in readiness.
WWWombat's Old Line: 550 metres, 40/10 package, 17a profileMax: Upstream rate = 16464 Kbps, Downstream rate = 59076 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 39996 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 16464 kbps 59076 kbps
Actual Aggregate Tx Power: 6.6 dBm 12.3 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.4 27.7 40.8 N/A 14.1 34.4 53.1
Signal Attenuation(dB): 11.5 27.2 40.1 N/A 14.1 34.4 53.1
SNR Margin(dB): 11.3 11.2 11.1 N/A 9.3 11.0 9.9
TX Power(dBm): -3.7 -16.8 6.3 N/A 8.5 7.9 5.4
Note that the line is running at a much higher SNR margin than the 6dB target, because it was using a 40/10 package - a long way below the maximum attainable of 59/16.
That line *did* have problems - it ran with interleaving and FEC enabled from day 3 (ie as soon as DLM could intervene, it did). It was using around 22% overhead on FEC, resulting in statistics of about 600,000 FEC per day and 200 CRC per day.
We have since moved, and have a shorter line that started out with an attainable of 90/27 while on a 40/10 package. As soon as we activated the 80/20 package that dropped to 84/26. This gradually dropped to 79/26 over the next 10 months to December, and is now stating an attainable speed of around 76/25. We're still synced at 80/20 because it hasn't been re-synced since early December.
I'm annoyed at myself for not hacking the firmware months ago, but I never expected the fall in connection speed would be so dramatic.
It isn't usually dramatic - more the kind of behaviour that mine has seen. However, it does depend exactly which phone lines have FTTC - and whether they run next to yours over the bulk of the 500 metres.
More strange is the fact that you have almost no errors. Those usually *do* go up!
But there is no getting around it - on those attenuation figures, you *ought* to have a higher attainable speed. And you therefore ought to have a higher actual speed.
The answer may well be hidden in the detailed way that the modem has allocated bandwidth across the spectrum, or in the background noise that your line is experiencing.
Have you seen the software package by Bald_Eagle? Those take even more detailed data from the modem, and create some useful graphs from them. Well worth having, now you've hacked the modem.
I'll try to dig out some of my historical information.
The concern I have is will it fall even further if even more houses take up fibre?
That is the question, isn't it...
Am I right in thinking this is the natural effect of Crosstalk then?
I don't think we can answer that in absolute terms, but the evidence suggests that the problem isn't obviously crosstalk, but it certainly could be.
Crosstalk appears to your modem (and the one in the cabinet) as noise and interference. This would have 2 main effects:
(1) would be to increase the interference to your data, after a "normal" synchronisation - which would be seen as an increasing rate of errors (both RSCorr when FEC was turned on, and OHFErr when FEC was turned off)
(2) would be to increase the base noise seen prior to, and during, sync negotiation. This would alter the signal-noise ratios (SNR) across the spectrum, resulting in lower speed as a result of the negotiation. With a lower speed, there will be fewer errors visible in (1).
In practice, both happen together. (2) is usually visible (in the hacked modem) because the "maximum attainable speed" decreases - but it usually drops a little more gradually.
(1) usually happens too, but only really becomes visible when DLM intervenes to turn on interleaving and FEC.
In practice, we seem to see (1) rather than (2). Error rates go higher, and interleaving (plus FEC) get turned on by DLM.
In your case, you are seeing almost no errors - so few, that DLM hasn't got interleaving + FEC activated, which would be the normal first step. If that didn't help matters, DLM would resort to banding your connection - which would place a limit on the speed, and reduce the errors that way. That doesn't look to have happened to you (it isn't a round figure, like 30Mbps, and your SNR values are very close to the target of 6dB).
So, you might be suffering crosstalk. If you are, then it has hit you exclusively as (2) with no evidence of (1).
A bit of a mystery!
|
|
|
@WWWombat
Thank you for the very detailed response. I've enabled the scripts with the scheduling batch file but don't always have the Virtual Machine running 24/7 to be able to grab a complete picture.
This is (I assume) the most useful image produced by the scripts based on my line stats at 18:19 today (3/Feb/13). If you wouldn't mind could you take a look please and let me know your thoughts.
Assuming then that I should have faster sync than this, how exactly do I report it to BT? I can't exactly tell them I've hacked the modem can I? All I can point to is the Wholesale line estimation which is nearly double my current IP Profile.
One other thing - at the top of the line stats it states this:
Status: Showtime
Retrain Reason: 2
What does "Retrain Reason 2" mean out of curiosity?
Thanks
Rob
|
|
|
if the sync speed has declined substantially from installation then this is the thing to report - Openreach have a limit on the decline of that parameter.
--
Phil
MaxDSL - goes as fast as it can and doesn't read the line checker first.
MaxDSL diagnostics |
|
|
|
I'm looking and comparing. It'll be a little before I can respond properly though...
|
|
|
I found my equivalent image, so uploaded it here. It's from an earlier version of the graphing scripts, so looks a little different.
Note that intepreting these graphs can be a problem, because the X-axis scale means that each pixel horizontally represents quite a large number of tones. In particular, spikes can look wrong.
Note too that mine was working to a 40/10 package, so the bit loading values on mine are probably a bit lower than they could have been if the modem were targetting something higher.
And a link to the Huawei hacking site, and their page about these graphs.
Working backwards from what we already know then...
Your line is carrying less data than my old one, so must have lower bit loading values (bits per carrer) downstream. Comparing those two graphs, we can see:
- that you do better than my line in D3 - the higher frequencies of tones 2792 to 3950.
- that in D2 (tones 1216 to 1963), you are carrying significantly less data - less than half - except for one tiny portion at the end where higher bit loading is evident
- that the lower part of D1 (32 to about 250) seems reasonable, but slightly lower than mine (though my trough appears around tone 500; this differs because of the different distance that the cab is from the exchange)
- that the higher part of D1 (250 to 859) are a little lower than mine.
- and that, on the upstream side, you are using U2 so much more than U1
The modems choose the bit loading based on SNR, so now compare those graphs.
- Your D3 is mostly similar to mine
- Your D2 is noticeably lower than mine, except for 2 spikes - where the improved signal level becomes very similar to mine
- Both lower and upper parts of D1 are notably lower.
Given that your signal level ought to be roughly similar (as there is similar attenuation, and your line has slightly higher transmit power), it seems that you definitely have increased noise throughout D1 and D2 (except for those 2 spikes) but not in D3.
The noise doesn't seem to be worse in any one particular frequency, suggesting that perhaps you are suffering broad-spectrum crosstalk from another VDSL2 customer, but who is perhaps on a longer line and not using any of the frequencies in D3.
Those 2 spikes are strange though...
Moving on to QLN graph, which (I think) is a measurement of the noise detected on the line when no signal is being carried at all. My understanding is that -140 represents very good silence.
Here it is noticeable that QLN in D3 is very good - so would explain why you are using that portion well. However, the QLN value for tones 300-2000ish all seem too high, suggesting too much background noise. Where there are spikes in the SNR graph, I'd expect troughs in this graph... and there is a slight hint. I think it might be present, but masked because of the X-axis scale.
I don't know enough about the Hlog graph to be able to read or interpret it.
Conclusion
I reckon you are suffering from broad-spectrum interference over the frequency range of tones 300-1900ish, or 1.2MHz to 8.2MHz. It seems likely this is caused by other FTTC customers in the form of crosstalk.
What isn't clear is the cause... whether there it is just "luck" (or lack of it), and that you have a very noisy neighbouring line, or that your line has a faulty joint, break, or construction that is allowing a high level of interference in.
For example, I recall someone on here reporting that their hassles were fixed when the engineer found 3 inches of bare copper in the cabinet. Strange problems abound...
As yarwell suggests, the thing to do is to report a fault, on the basis that you are getting much less speed than the estimate *and* that you used to have much better speed before a fault where you got disconnected.
You're going to want the engineer, at minimum, to check joints where you previously got disconnected/reconnected, and check the tie cable joints. If that doesn't work, you'll probably want them to try putting your line on a different pair in the distribution cable, or try a different port in the FTTC cabinet (and different pairs in the tie cable as a consequence)
It may take a number of goes at getting an engineer to attend to get this sorted. I don't know the best approach to take with BT - only with Plusnet.
Note that most other people that have problems, see the effects in terms of errors on the line from interference - and can monitor the effect of any changes by the ongoing error counts. Unfortunately your issue is based on the background noise level... and is probably best monitored using the QLN graph. Unfortunately that data only gets updated when the modem syncs.
|
|
|
One other thing - at the top of the line stats it states this:
Status: Showtime
Retrain Reason: 2
What does "Retrain Reason 2" mean out of curiosity?
Retrain Reason: 2 is the usual reason following an "on the fly" resync, probably taking less than 20 seconds from disconnection to reconnection.
This type of resync is usually (not always) initiated by DLM taking some sort of action - usually to lower speed & compensate for errors, but occasionally increasing speed following a sustained period of connection stability.
Retrain Reason: 0 is always seen following a modem reboot or power off & on again.
These tend to take quite a bit longer than 20 seconds.
There may be other causes of reason 2, but I haven't seen any of those events.
Very, very rarely, I have seen Retrain Reason: 1.
I have absolutely no idea what may have caused that result.
|
|
|
I don't know enough about the Hlog graph to be able to read or interpret it.
Loosely, Hlog depicts attenuation over frequency.
The ideal graph is a gently sloping (almost horizontal) & smooth graph with no peaks or troughs.
A reasonably wide & deep 'v'-shaped valley tends to suggest a bridged tap/High Resistance issue & a peak tends to suggest some sort of high capacitance.
Edited by deleted (Tue 05-Feb-13 19:59:09)
|
|
|
The ideal graph is a gently sloping (almost horizontal) & smooth graph with no peaks or troughs.
I'm not sure about horizontal - the ones I've seen seem to be a smooth descending line, that gently curves to be less steep as it descends.
The OP's Hlog graph, to me, looks fine. With your interpretation, it suggests there are no obvious line problems to note, right?
|
|
|
This is what I meant by ideal/almost horizontal:-
Almost flat Hlog Graph
& here is the pbParams data from that connection - ONLY 13.8dB ATTENUATION in the D3 band!!!
Apparently around only 60m from the cabinet.
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
| Retrain Reason: 0
Max: Upstream rate = 41318 Kbps, Downstream rate = 129700 KbpsPath: 0, Upstream rate = 10000 Kbps, Downstream rate = 39998 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783) DS: (32,859) (1216,1963) (2792,3939)
Medley Phase (Final) Band PlanUS: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939) VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 41318 kbps 129700 kbpsActual Aggregate Tx Power: - 8.6 dBm 13.3 dBm
============================================================================ VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 2.2 7.8 10.0 N/A 4.4 9.2 13.8 Signal Attenuation(dB): 0.0 N/A 7.2 N/A 4.4 9.2 13.8
SNR Margin(dB): 30.7 N/A 30.8 N/A 31.4 31.2 31.4 TX Power(dBm): -25.1 -128.0 -10.2 N/A 10.5 7.7 6.2 |
I agree. The OP's Hlog graph looks just fine.
Here's one before the bridged tap was removed:-
Bridged Tap
& the same connection after it was removed :-
Bridged Tap Removed
Edited by deleted (Tue 05-Feb-13 22:00:35)
|
|
|
your analysis is similiar to what I see on my line.
my D1 bitloading is similiar to lines with higher attenuation than mine in other words its underperforming. Indeed my D1 has very noticeable lower bitloading than when I had a 90meg attainable sync.
my D2 also took a noticeable hit.
my D3 didnt appear to make much of a hit and is almost the same as when I had the higher sync.
The upstream again similiar however with something more interesting.
U1 does not have increased QLN unlike D1 D2 and D3 and U2, however when I had a 90/36 attainable U1 was been fully utilised with high bitloading, now U2 is been used more and U1 has lower bitloading.
I concluded the same as what you have for this guy.
I think a longer line is crosstalking with me, openreach cutback my upstream power (they now have admitted this to me via my install engineer). However this cutback seemed to have had consequences on my downstream as well although I do have very high QLN on my D1 and D2. My QLN is the highest I have seen on any HG graph. The QLN is also high on D3 but seems to have affected D3 much less, my conclusion is when attenuation is higher crosstalk has less affect since signal is lost anyway due to the higher loop loss.
Seems clear to me vectoring is needed on BTs network the 40% or so loss is not a myth from my own conclusions.
Although also notice the slight change in attenuation (pair swapped?)
Before crosstalk
After Crosstalk
--edit--
I see Madpom has severe QLN like myself, so now I seen someone else with as bad. That QLN is pretty high in my view compared to the average.
BT Infinity 2 Since Dec 2012 - Estimate 65.9/20 - Attainable peak 110/36 - Current Sync 71/20
Edited by Chrysalis (Wed 06-Feb-13 00:16:55)
|
|
|
I guess I have a little issue with my line looking at shape of the Hlog graph? Here. 
Not that i'm really bothered because my line syncs at 73 Mbps.
|
|
|
I guess I have a little issue with my line looking at shape of the Hlog graph?
It looks that way.
At the speeds your connection is achieving though, it's probably not worth the effort to pursue resolving it.
|
|
|
|
@all
Thank you for the in-depth analysis and wonderfully-detailed explanations.
A few extra points:
Whilst I don't know exact cable routes in my area, using "worst case scenario" the longest possible line from my cab that could run parallel to mine (closer to the cab) would be 1.2km long. However only an idiot would have wired the estate that way...! More likely it would peak at 800m in length.
My phone line itself is ok, a little crackly.
Something I am aware of is the cable from the pavement to my property runs under my lawn but wasn't buried very deep. When I first moved in (12 years ago) I put a spade through it by accident - and noticed several joins in it already - before the BT guy came to repair it. I know joins add to attenuation, but would it be this significant? I've mentioned the cable to Openreach engineers in the past after every fault and because it's buried they always offer the same response that they wouldn't deal with it unless the phone failed completely.
I've reported it to BT via their Twitter/email contact form. I've given them the Wholesale speedtest screenshot demonstrating IP profile, not heard anything back since. To be honest I'm not getting my hopes up, the response I expect is "it's working, be grateful". Although if the reason is crosstalk as you all suggest then is there much they can do?
I'll update this thread with any response I get in-case anyone else is in a similar position and is interested.
Thanks all!
Rob
|
|
|
I think you have your line length about right based on your attenuation.
On crosstalk in the long term they can doa lot with vectoring.
In the short term they can try a pair swap or replace cables, the latter is pretty unlikely tho. Its also possible as stated there could be an issue making the crosstalk worse than it should be, but of course to find that issue openreach would have to believe it to be a fault first to look for it.
BT Infinity 2 Since Dec 2012 - Estimate 65.9/20 - Attainable peak 110/36 - Current Sync 71/20
Edited by Chrysalis (Wed 06-Feb-13 08:14:50)
|
|
|
If its not deep dig it up, it won't be buried then 
On the subject of buried cables, does anyone know if the metal amour on the phone cable was exposed, could it cause interference?
My cable was damaged by the builders about 8 years ago exposing just the amoured metal. It was then just buried again, without being insulated. But I read that if this shielding is earthed at two points it could cause curent to flow due to the potential difference between the two earth points?
|
|
|
I think if both ends are "earthed" by being in the actual earth the potential difference isn't anything to worry about. A pseudo-earth in a piece of kit may be a different matter.
--
Phil
MaxDSL - goes as fast as it can and doesn't read the line checker first.
MaxDSL diagnostics |
|
|
Thanks Yarwell, I won't dig it up and insulate it then
|
|
|
|
Quick update - BT called today and have arranged an Openreach appointment for me in the next few days. Fingers-crossed they can do something but still not getting my hopes up.
@Ronski
Is it just the outer insulation that is perished or is the copper of the actual pair wires exposed? Water ingress may be an issue which (and I may be wrong) can cause noise/increased attenuation on the line. In extreme cases (such as co-ax Satellite cables) water can enter the cable at the dish end (LNB) and travel down the cable eventually damaging the receiver.
|
|
|
It''s an armoured cable, it has an outer layer, which if I remember correctly was like clear PVC, then the armoured metal layer. It was only the outer sheaf that was damaged, the inner cables were not exposed.
Didn't think at the time to wrap some self amalgamating tape around it.
|
|
|
|
Openreach came out to me earlier today and spent a good while looking at the issue. Engineer was great and couldn't have been more helpful, and was really keen to figure it out.
Firstly in the junction box outside my house (where the line comes from under the lawn) a join was loose and came away in his fingers as he opened the box. After repairing that the speed went up by just 2mbps, so he looked further into it.
Turns out the street cabling is Aluminum which he described as being in "degraded" condition. After testing speeds on the cable at each access grid on the route he found the speed was ~45mbps at the nearest grid to my house, which is at the end of my street (100m from my property, ~500m from the cabinet). He found a spare pair between that grid and the cab so swapped my line over, bumping the speed up to ~60mbps at that point.
Back at my house in the junction box outside the speed was down to 45mbps and inside the house 40mbps, so he swapped the cable between junction box and the NTE5, and fitted a new NTE5 into the bargain. This got the speed up to 42mbps.
Unfortunately he believed this was as high as he could get it without digging the street up, which he said he wouldn't get approval for unless there was an physical/electrical fault with the cabling, though he encouraged me to report any further speed drops He said the cable under my lawn is copper and should be ok, but to replace it would require digging the street up (regardless of whether I dug my own lawn or not). As there's no grids closer than the end of the street he couldn't say for definite what improvement could be made.
When I get chance to connect to the modem and get updated stats off I will post them for reference. Thanks to all for the great feedback and I hope all this info can help anyone else if they too suffer a similar speed drop.
It's a shame the installation cost of FTTPoD is looking to be prohibitively expensive (if/when it becomes available), as I get the feeling over time this is just going to keep happening.
Rob
|
|
|
It does seem ali is quite widespread as on so many speed investigations a ali pops up been to blame, and given we both had similiar veyr high QLN I now suspect I am plagued by ali as well.
Did he say that pair he swapped to is now copper? or was it still ali but just a better pair?
BT Infinity 2 Since Dec 2012 - Estimate 65.9/20 - Attainable peak 110/36 - Current Sync 71/20
|
|
|
@Chrysalis
He didn't specify the type of pair he swapped me over to but I suspect it's just a better quality Alu wire. He was scathing of Alu cable and cited it as the cause of most problems he personally deals with, and reckoned if he could he'd get it ripped out and replaced with copper but it's too costly and wouldn't be authorised.
Here are my current line stats now I've had chance to grab them:
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 16545 Kbps, Downstream rate = 41892 Kbps
Path: 0, Upstream rate = 16668 Kbps, Downstream rate = 43138 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.6 6.0
Attn(dB): 0.0 0.0
Pwr(dBm): 13.1 6.8
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 64 64
R: 0 16
S: 0.1770 0.4543
L: 10845 4473
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 13528820 677019
OHFErr: 678 6
RS: 0 3750881
RSCorr: 0 95
RSUnCorr: 0 0
Path 0
HEC: 514 0
OCD: 0 0
LCD: 0 0
Total Cells: 3189242717 0
Data Cells: 83684726 0
Drop Cells: 0
Bit Errors: 0 0
ES: 4900 83
SES: 56 0
UAS: 7085 7085
AS: 38475
Path 0
INP: 0.00 0.00
PER: 2.83 7.26
delay: 0.00 0.00
OR: 73.42 31.91
Bitswap: 7290 4990
Total time = 1 days 23 hours 24 min 28 sec
FEC: 0 0
CRC: 57585 0
ES: 4900 83
SES: 56 0
UAS: 7085 7085
LOS: 38 0
LOF: 39 0
Latest 15 minutes time = 9 min 28 sec
FEC: 0 0
CRC: 2 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 23 hours 24 min 28 sec
FEC: 0 0
CRC: 4289 0
ES: 664 16
SES: 8 0
UAS: 17 17
LOS: 5 0
LOF: 5 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 53296 0
ES: 4236 67
SES: 48 0
UAS: 7068 7068
LOS: 33 0
LOF: 34 0
Since Link time = 10 hours 41 min 13 sec
FEC: 0 95
CRC: 678 6
ES: 236 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#
And this image is the resulting graphs from the scripting tools.
It's a modest improvement but sadly as good as I'm ever going to get now, and most likely it will fall over time as the Alu degrades and even more people in my area adopt FTTC.
Rob
|
|
|
your QLN on D1 and D2 is noticebly lower so it looks like the pair swap got you away from some of the crosstalk. Although still some there isnt as much now.
BT Infinity 2 Since Dec 2012 - Estimate 65.9/20 - Attainable peak 110/36 - Current Sync 71/20
|
|
|
Pages in this thread: 
Print Thread
MadPom
