Plusnet "current line speed" v2 - modem stats

In reply to a post by Brookzy:

Here's the first batch of stats

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:	0
Max:	Upstream rate = 15019 Kbps, Downstream rate = 57708 Kbps
Path:	0, Upstream rate = 15142 Kbps, Downstream rate = 58157 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783) 
DS: (32,859) (1216,1963) (2792,3971) 
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783) 
DS: (32,859) (1216,1963) (2792,3971) 
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 15019 kbps 57708 kbps
Actual Aggregate Tx Power: 7.4 dBm 13.9 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB):	 5.5	 25.4	 37.4	 N/A	 14.2	 31.2	 46.9	
Signal Attenuation(dB):	 5.5	 24.6	 36.7	 N/A	 14.2	 31.2	 46.9	
SNR Margin(dB):	 5.6	 5.7	 5.7	 N/A	 5.9	 5.9	 5.9	
TX Power(dBm):	 0.6	-17.9	 6.4	 N/A	 11.2	 8.2	 6.8

Can you also post the output with the "--stats" option? That will tell us what DLM has been up to.

Then just for comparison, here are my stats. Line between 350 and 400m.

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Last initialization procedure status:   0
Max:    Upstream rate = 25501 Kbps, Downstream rate = 82188 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
                  VDSL Port Details               Upstream                Downstream
Attainable Net Data Rate:           25501 kbps              82188 kbps
Actual Aggregate Tx Power:             6.9 dBm               13.1 dBm
====================================================================================
        VDSL Band Status                U0              U1              U2              U3              U4              D1              D2              D3
  Line Attenuation(dB):  4.3     21.6    32.5     N/A     N/A    11.3    27.1    41.3
Signal Attenuation(dB):  4.3     20.7    31.5     N/A     N/A    15.8    26.8    41.4
                SNR Margin(dB):  15.5    14.8    14.8     N/A     N/A    6.9     6.9     6.9
                 TX Power(dBm): -2.9    -21.7    6.5      N/A     N/A    9.8     7.9     6.9
#

Thanks for making a v2!!!

Here you go...

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:	0
Max:	Upstream rate = 14877 Kbps, Downstream rate = 57280 Kbps
Path:	0, Upstream rate = 15142 Kbps, Downstream rate = 58157 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.8		 5.6
Attn(dB):	 0.0		 0.0
Pwr(dBm):	 13.9		 7.4
			VDSL2 framing
			Path 0
B:		239		237
M:		1		1
T:		64		64
R:		0		16
S:		0.1313		0.5000
L:		14619		4064
D:		1		1
I:		240		127
N:		240		254
			Counters
			Path 0
OHF:		46885559		1878115
OHFErr:		682		110
RS:		0		1014017
RSCorr:		0		3590
RSUnCorr:	0		0

			Path 0
HEC:		1397		0
OCD:		0		0
LCD:		0		0
Total Cells:	2466201817		0
Data Cells:	251364723		0
Drop Cells:	0
Bit Errors:	0		0

ES:		470		107
SES:		0		0
UAS:		75		75
AS:		98911

			Path 0
INP:		0.00		0.00
PER:		2.10		8.00
delay:		0.00		0.00
OR:		91.36		31.00

Bitswap:	12421		10435

Total time = 1 days 3 hours 30 min 6 sec
FEC:		0		0
CRC:		682		0
ES:		470		107
SES:		0		0
UAS:		75		75
LOS:		0		0
LOF:		0		0
Latest 15 minutes time = 6 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:		2		0
ES:		2		1
SES:		0		0
UAS:		0		0
LOS:		0		0
LOF:		0		0
Latest 1 day time = 3 hours 30 min 6 sec
FEC:		0		0
CRC:		114		0
ES:		84		14
SES:		0		0
UAS:		0		0
LOS:		0		0
LOF:		0		0
Previous 1 day time = 24 hours 0 sec
FEC:		0		0
CRC:		568		0
ES:		386		93
SES:		0		0
UAS:		75		75
LOS:		0		0
LOF:		0		0
Since Link time = 1 days 3 hours 28 min 31 sec
FEC:		0		3590
CRC:		682		110
ES:		470		107
SES:		0		0
UAS:		0		0
LOS:		0		0
LOF:		0		0
#

OK, I can see the following about DLM:

- It has ordered no intervention for FEC or interleaving in either upstream or downstream.
INP=0 and delay=0.

- Interleaving is off in both direction
D=1

- FEC is off downstream, but turned on upstream
R=0 downstream, R=16 upstream

- The FEC overhead upstream is about 6%
(R=16, N=254, R/N=0.063)

- The error rate seems to be OK
CRC over last 24 hours is 568, and ES is 386

For comparison, the DLM settings are identical on my line (which is 80/20, but 82/25 attainable).

I'm currently getting the same rate of ES as you (averaging 400-500 per day over the last month), but it was averaging around 650 per day for the 2 months before that.

However, my CRC rate is about 10x the ES rate, which means that when I get errors, they come in bigger bursts. Thankfully, it appears to be the ES rate that DLM looks at.

Conclusion:
Those settings suggest that your line is running as fast as it can, so doing anything to the DLM profile, right now, would be pointless.

^{Edit: add conclusion}

Edited by deleted (Fri 28-Feb-14 11:09:42)

Thanks very much for your analysis.

I thought the CRC figures were a bit high but I guess not!

So DLM can be eliminated as a factor. Still disappointing that the BT Wholesale Availability Checker estimates up to 70 mbps (recently revised down from 72), yet realistically it is a good 25% slower than that.

Just out of curiosity, is it possible to "walk" your line, i.e. make a guess at actual line length back to the cabinet?
I have a line that is probably about 320m as you walk the route but the dsl checker isn't confident of full speed.
Have many people got estimated / accurate line length figures, checker estimates and corresponding real speeds for their own connections, would be useful to start a database for comparison.
flipdee

Hi Flipdee,

Here's a graphic showing a couple of routes I think the cable could take and distances taken from Google Earth
http://f.cl.ly/items/2V430X3G1V243Q0I1A1m/Phonecable...

I'd say my home line is about the same length as your worst case, maybe a tiny bit longer and I'm getting a stable 67.3 download 20Mbps upload.
Obviously two lines can't quite be compared side by side without a lot more details.
I'll see if I can dig out the line stats for my line.
Cheers,
flipdee

Edited by deleted (Sat 01-Mar-14 00:04:24)

Hmm... Just picked up the landline phone and noticed a bit of noise. So did a quiet line test and there seems to be some sort of interference.

Here's a four second recording of the sound. It's quiet, but I didn't want to boost the volume as it would distort its comparative loudness on the phone.

(Download link for browsers that do not play the file automatically. Approx. 30 KB.)

Okay,

Line 1:

Text
1 23 45 67 89 1011	VDSL2 framing                         Path 0B:              239             237 M:              1               1T:              23              42 R:              0               16S:              0.0956          0.3781 L:              20080           5374D:              1               1 I:              240             127N:              240             254

Text

1 23 45 67 89 1011 12

Max:    Upstream rate = 22919 Kbps, Downstream rate = 74432 Kbps Path:   0, Upstream rate = 19999 Kbps, Downstream rate = 79891 Kbps         VDSL Port Details       Upstream        DownstreamAttainable Net Data Rate:      22919 kbps         74432 kbps Actual Aggregate Tx Power:        7.1 dBm          14.1 dBm============================================================================   VDSL Band Status        U0      U1      U2      U3      D1      D2      D3  Line Attenuation(dB):  4.3     22.5    33.4     N/A    11.8    27.2    42.3 Signal Attenuation(dB):  4.3     21.5    32.4     N/A    11.8    27.2    42.3        SNR Margin(dB):  14.5    13.7    13.7     N/A    4.5     4.4     4.4          TX Power(dBm): -1.7    -20.7    6.5      N/A    11.6    7.7     7.1

This line, when it was the first connection on the cabinet, had attainable rates of 98020 kbps downstream and 29421 kbps upstream, it has had a single resync since then to the numbers above. That's the impact of 4 full cards worth of crosstalk.

Line 2:

Text
1 23 45 67 89 1011	VDSL2 framing                         Path 0B:              239             237 M:              1               1T:              21              42 R:              0               16S:              0.1044          0.3781 L:              18384           5374D:              1               1 I:              240             127N:              240             254

Text

1 23 45 67 89 1011 12

Max:    Upstream rate = 21650 Kbps, Downstream rate = 71544 Kbps Path:   0, Upstream rate = 19999 Kbps, Downstream rate = 73133 Kbps         VDSL Port Details       Upstream        DownstreamAttainable Net Data Rate:      21650 kbps         71544 kbps Actual Aggregate Tx Power:        7.1 dBm          14.1 dBm============================================================================   VDSL Band Status        U0      U1      U2      U3      D1      D2      D3  Line Attenuation(dB):  4.7     22.7    34.1     N/A    11.8    27.5    42.3 Signal Attenuation(dB):  4.7     21.8    33.3     N/A    11.8    27.5    42.3        SNR Margin(dB):  14.6    14.1    14.2     N/A    5.5     5.5     5.5          TX Power(dBm): -1.9    -20.7    6.5      N/A    11.6    7.9     7.0

So essentially a 25% loss in attainable downstream. Staggering.

Come on BT... get the vectoring rollout going!

I wonder how effective vectoring is? Does it wipe out the crosstalk or only mitigate it?

It should pretty well wipe it out. Unless there are a few non-vectoring modems on user premises .

Didn't Plusnet say is wasn't as effective as they had hoped, I'm sure there is a thread about the trials on their forums.

Here's a four second recording of the sound.

Good luck with reporting that one !

I think you need to fully undo, temporarily at least, that botched master socket extension in order to see what effect it's having.

Brookzy had all that sorted out, the installation is now pukka.

Hi Zarjaz.

Is that the case (I may have missed the relevant posts)? I know the bridge tap was removed, but I thought the rest was left intact (ie extension from original master to new master via unknown cable, unknown length, crimped by someone now known to be incompetent, possibly with secondary wiring coming back in cores within the same cable, and a master socket supplied by this person also).

No back ending AFAIK, as he no longer uses the extension wiring.

Just to clarify, the current setup is as follows:

Drop wire ---> Internal wiring ---> Location of "old" master socket location ---> Jelly crimps ---> Internal wiring ---> Location of "new" master socket; all extensions isolated

The engineer saw and aknowledged this.

Yep, so just a single pair all the way in. As nature intended.

Well the strange thing is that the wire enters the premises on a blue pair, and arrives at the new master on an orange pair. So the crimps join the blue and orange pairs. Hopefully this isn't creating a slowdown.

I'm pretty sure I can say the lower than expected speeds are due to crosstalk.

In reply to a post by Brookzy:

So essentially a 25% loss in attainable downstream. Staggering.

Even more of a loss up. Good isn't it?

Hopefully Openreach will lay down the law service agreement and ensure only approved modems are used!

In reply to a post by Brookzy:

So essentially a 25% loss in attainable downstream. Staggering.

Yup.

I wonder how effective vectoring is? Does it wipe out the crosstalk or only mitigate it?

The Broadband Forum (industry group) has this description of vectoring. Figure 6 shows their figures for the difference between vectoring (red circles) and non-vectoring (blue crosses and, worst case, blue triangles).

Note for those blue crosses: My current BT estimate gives two speed ranges for my 350m line. The best estimate is 60-80 - which maps to the region covered by the bottom 50% of the blue crosses, while the lower estimate is 41-70 - which is from the lowest blue triangle to the lowest blue cross.

Vectoring, in theory and in limited practice, can make a huge difference. Whether it will work well live in BT's network depends on both BT's network, Huawei's (and ECI's) implementation, and the other interference left after crosstalk is removed.

In reply to a post by R0NSKI:

Didn't Plusnet say is wasn't as effective as they had hoped, I'm sure there is a thread about the trials on their forums.

There was indeed a thread, and the quote gave numbers lower than we would have liked (of the order of 10 Mbps IIRC), but the author seemed quite happy with the effect and the quote itself was (it seems) fairly rough-and-ready. On going away for more details, I imagine the author was told not to reveal anything more until BT were ready.

It could have been that Huawei's implementation isn't ready for the limelight yet, and it could have been that the chosen sites were a particular problem (chosen, IIRC, for the expected impact of external RFI).

BT have been very quiet on the results of the trial. I wonder when we'll hear?

BTW, I've seen that a BT engineer is due to talk about the results of their G.fast trial in April in Paris. Surely we'll hear about vectoring before that one!

Interesting report. Added to the reading list.

Figure 6 - DS Rates Profile 17a, 26 AWG, -136 dBm/Hz noise, 80 users, and 47 cancelled

So crosstalk will still exist among the other 33 then? Makes the improvement even more impressive.

Judging by their data my current 58 Mbps sync could be increased to beyond 70 Mbps with vectoring.

Without wanting to be Captain Hindsight, BT's omission of vectoring from the outset seems a bit myopic!

In reply to a post by Ignitionnet:

Even more of a loss up. Good isn't it?

Were the "before" figures using FEC? Both the "after" figures are using 6% of the bandwidth for error correction, even though no interleaving is in use.

(R=16/N=254)

Vectoring is too young to have been deployed before now.

VDSL2 was standardised in 2006, while vectoring was only approved in 2010. The chipset manufacturers are still ironing out interworking problems at plugfests.

As for the 80 users vs 47 cancelled, I agree... but it is probably more complicated than that. Often a cable has its pairs broken down into groups, known as binders. The 47 that are cancelled are probably within the same binder as "ours" (total 48), which is the same set of wires that twist around each other. The other 32 will be in different binder(s) in the cable.

Pairs in the same binders are the ones that are likely to have the biggest impact.

Note too that the graph is for 26AWG cable, which is 0.4mm. Our D-side is more likely to be 0.5mm. Adtran reckon that the extra 0.1mm improves range by a factor of 1.3

This Adtran presentation shows more. Page 35 has something on binders, while page 42 shows the importance of cancelling every other line.

Excellent post WWWombat,
By that reckoning, would going up by 0.3mm nearly double the distance?
What would the largest cross sectional area of twisted pair cable be feasible?
There doesn't seem to be a huge selection of heavy gauge twisted pair cable.
The other thing I don't see much mention of is how adsl on adjoining cables effects vectoring?
Obviously the adsl signal will have a degree of separation.
Cheers,
Flipdee

Edited by deleted (Wed 05-Mar-14 06:25:48)

some other news?

earlier this week openreach and plusnet decided to fix my issue by reducing my speed estimate, brilliant.

Openreach acknowledged that in multiple engineer visits engineer's ignoring failing HR tests and failing to even swap out faceplate/NTE5 was a fail, but they otherwise insist a 40+% loss of dsl signal is perfectly within parameters.

Basically senior openreach management have now admitted to me as long as the remote tester unit tests ok there is 'zero' justification for doing any manual physical checks on 'any' part of the line. Quality control and pride doesnt mean anything in that corporation.

Im not convinced my speed loss is all down to crosstalk its much more than what most people report.

to rub salt into wounds my neighbour was activated also within the past week and he has a decent margin on a full 80mbit sync, is in same building as me.

I'd get a new line provision with fttc, wait till full 80Mbps on it, then tell them to stick their original line and fttc connection up their proverbial.

I believe it wont fix crosstalk caused by things such as split and damaged pairs. In other words it doesnt fix a physically broken network.

If BT ever do rollout vectoring I predict we will see various people not getting their speed back because of this as openreach seem in denial with the state of their network.

Flogging a dead horse comes to mind, conveniently able to use a quantity of public money to buy the whips.

I am sure BT announcement of vectoring for all FTTC roll out in this April (next month) or probably October this year.

if its too young how have others had it deployed already?

there is commercial products on the market both dslams and modems that have the technology, its not something thats still in the labs only.

Simply its BT just been slow again and trying to rollout FTTC on the cheap. I think they skipped over it because originally they were expect a decent FTTP rollout to go along with it and perhaps planning to migrate FTTC to FTTP as well, but their FTTP problems probably means FTTC is more long term than originally planned and now because of that they started looking into vectoring, thats my view only of course.

already going ahead, install due late march.

The problem been tho they may use the same dropwire and as a result not even touch the pole or junction box to do the install so if either of those 2 is the issue then it will still be issue on the new line.

My neighbour because he is round the back has his own dropwire and not using my junction box.

Edited by Chrysalis (Wed 05-Mar-14 08:56:00)

In reply to a post by WWWombat:

Were the "before" figures using FEC? Both the "after" figures are using 6% of the bandwidth for error correction, even though no interleaving is in use.

(R=16/N=254)

I took those stats the day after the install, I'm pretty sure FEC was in use at that time and was activated overnight.

sorry missed your post, looked for it when you mentioned 25%

98mbit down to 74mbit?

not as bad as me but still brutal.

Expect to be told 80mbit is the max attainable so that will wipe out 18mbit of your loss and then probably after that be told 74 is excellent so nothing to worry about

if its any hope to you, on my own line most of the loss occured in the first 3 weeks. After that further drops of speed were in small amounts. So I went from 110 to 72-73 in 3 weeks, then it took a further year to get me down to 65. I was down to 62 but I got 3mbit back by swapping out my NTE5 as incompetant engineers failed to diagnose a broken NTE5 (was causing drops of upstream snrm during calls, showed up on their testers but they ignored).

Also you are far from the exchange like me, so the adsl power cutback I expect on your line is probably heavy. Seems to be lighter for people close to the exchange meaning distance from the exchange does still have 'some' bearing on FTTC speeds.

Edited by Chrysalis (Wed 05-Mar-14 09:11:05)

I agree, God help us when take up hits levels where "super fast" becomes "super slow"

I may get a second line when my contract expires, as I'm sure something is wrong with mine. I don't seem to have been hit by cross talk, and if anything my speed has improved.

I probably should have canned this line when I moved to plusnet and did a new line order then, but I was worried the new line would be worse.

Always a possibility, but at least a new provision involves pair quality testing and if your on the ball, hopefully you can be "pushy" in the right areas.

Will be interesting to hear how your new line performs. Take it your going to have two connections for some time then. My 18 months is up, but I have line rental saver which runs until October, and having had a think about it I wonder if it's worth the hassle for me.

yes will have 2 lines.

decided will ask for the socket to be at the back of my flat, making it easier for the engineer to use the other dropwire than my existing one.

Now that's a very good idea, hope it works.

I'm not sure they'll use a pair from someone else's dropwire.

He's in a flat, I'm sure they wouldn't use a separate drop wire for each flat would they?

Good point. I don't know. I wouldn't be surprised if they do - what if there's a fault from the pole, or at the pole?

Edited by RobertoS (Thu 06-Mar-14 18:53:35)

my existing dropwire is already shared with a neighbour.

This is a house converted to 3 flats.
My dropwire is for mine and the flat above me, guy round the back has another dropwire.
Assuming is at least 4 pairs in the other dropwire I think they can share it.

Sounds good then .

In reply to a post by flipdee:

By that reckoning, would going up by 0.3mm nearly double the distance?

The ratio of resistance for copper wire of 0.4mm, 0.5mm, 0.7mm and 0.9mm is

150:100:50:30

That gives you a rough idea of how the distances would factor too, though obviously inversely to that ratio

Obviously capacitance and inductance play a part too, but in more complicated ways. I can only cope with ohm's law!

What would the largest cross sectional area of twisted pair cable be feasible?

Take a look in this (large) PDF, pages 90-92. That suggests 1.1mm for BT drop wire, to a variety of "CWxxx" standards.

The other thing I don't see much mention of is how adsl on adjoining cables effects vectoring?
Obviously the adsl signal will have a degree of separation.

ADSL from the exchange is often described as an "alien disturber" which can't be cancelled. That means that vectoring won't be useful at those frequencies, though the actual frequencies will vary from cabinet to cabinet depending on the distance to the exchange. I suspect that one of the things the trials are meant to show BT is how they have to configure vectoring at each cabinet so it doesn't bother trying to work on the frequencies where ADSL is still active.

In reply to a post by Chrysalis:

I believe it wont fix crosstalk caused by things such as split and damaged pairs. In other words it doesnt fix a physically broken network.

It ought to be able to fix any crosstalk (ie signal from other lines) that behave in a predictable, constant manner. But it can't fix noise from any other source (arc'ing, intermittent contact or RFI), whether that is "normal" noise, or noise from a fault.

So if the failure makes a line susceptible to crosstalk in general, vectoring will work. If this additional impact varies over time (such as when the wind blows), then vectoring can't have much effect.

If the failure makes the line susceptible to other forms of noise, with sources other than crosstalk, then vectoring isn't in a position to help at all. That still has to be left to the existing forms of DLM.

So, does a line fault tend to generate its own noise, or magnify crosstalk specifically? I don't know the answer, but I suspect it is the former.

In reply to a post by Chrysalis:

if its too young how have others had it deployed already?

The technical leader in vectoring is Alcatel-Lucent, and they do have some equipment deployed, particularly in Belgium. But it isn't really in full-blown use yet - with the first area going live 2 weeks ago.

The Belgians aren't going to tax it too strongly at first - with "up to 70Mbps" their first aim.

Swisscom should be going live around now, with Germany later this year.

Other vendors are behind the curve on this one - Huawei a little behind and ECI further behind. This impacts the operators they have sold to, such as BT.

It is unfortunate, for us, that BT have chosen suppliers who aren't quite up to speed.

there is commercial products on the market both dslams and modems that have the technology, its not something thats still in the labs only.

Both are out there for sale, so it is definitely past the "lab-only" stage.

But, while the plugfests started up 18 months ago, and the vendors were added into the schedule a year ago, they are still going on (next one in April).

Presumably, the vendors such as Alcatel are taking a punt that their hardware is up to scratch, and any fixes can be handled with firmware changes alone.

Simply its BT just been slow again and trying to rollout FTTC on the cheap.

Well, BT started to plan the FTTC rollout in 2008, and actually had equipment out in 2009. The main project was running in 2010, with 1.5m premises passed in the summer. By the end of 2011, they'd passed 7m premises, with around 19,000 cabinets.

Meanwhile, vectoring was approved by the ITU in April 2010, when BT were already in flow.

By the end of 2011 (when BT had 19k cabinets rolled out), the chipset manufacturers had just held their second plugfest, but the system vendors hadn't had any inter-operability tests at all.

Could they deploy faster? Certainly... they could have deployed untested equipment which had no certainty of working in the field. However, BT are certainly too conservative on that front. But I don't think that has held anything up so far.

Of course, they might yet choose to delay things *after* the vendors are ready.

I suppose they could have held back, and not deployed any cabinets at all.

I think they skipped over it because originally they were expect a decent FTTP rollout to go along with it and perhaps planning to migrate FTTC to FTTP as well, but their FTTP problems probably means FTTC is more long term than originally planned and now because of that they started looking into vectoring

I suspect that is a conspiracy theory too far.

Certainly, BT were touting vectoring as the way to get >50% of premises to 100Mbps in Jan 2012... and in the same meeting, were still talking about FTTP as being the "large-scale" deployment. The cutback hadn't happened at that point

In reply to a post by Ignitionnet:

I took those stats the day after the install, I'm pretty sure FEC was in use at that time and was activated overnight.

I guess it is hard to tell, because this upstream usage of FEC doesn't appear to be triggered by DLM.