Print

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

[Ramino]

@Newtronstar , Bald_Eagle1 , Kitz

Thanks for the explanations about the Band Plans.

We use both Alcatel and Huawei MSAN, I'm attached to an Alcatel 7356 --> https://www.alcatel-lucent.com/products/7356-isam-fttb-rem
Anyway, this is my bitloading:

http://i.imgur.com/siZihuK.png

We have the DPBO [Downstream Power back Off] to protect the adsl\adsl2+ till the frequency of 2.2MHz (as you can see clearly on the DS1 Band). Seeing your screens probably you have it too.
Regarding the US3 (12MHz-14MHz) its not fully utilizable, maybe because of the UPBO [Upstrem Power Back Off]? Is it possible ?

Black Sheep also gave a little bit of info on the BT Openreach configurations

Vector (Full) = the modem is fully compatible with vectoring and on a DSLAM where vectoring is running it will synch in vectored mode and get a speed result based on that.
Vector (Friendly) = the modem is not fully compatible with vectoring, but can provide some information about cross talk to the DSLAM, this means the vector engine gets results from this which it can use to improve performance for those that are compatible, but this modem it’s self will get a standard VDSL speed.
Vector (off) = this is also known as not vector friendly, the modem is not able to support vectoring at all and provides no useful information to the DSLAM about cross talk, and it only gets standard VDSL speed.

At this point I had a horrible thought. What if your disturber was using a modem that wasnt compatible?
The vectoring engine needs information from both modems to be able to effectively cancel FEXT.  If a modem in the same bundle isnt at least vector friendly then the vector engine isnt able to do anything about the crosstalk from that particular line.  Interpretation from Blacksheeps post the disturber is penalised in that they wont get the higher 100Mb speeds.. but poor neighbour is also at a disadvantage and unable to recover any of the speed lost to crosstalk. :/

Concerning this, I've edited my previous post: 
"I would add another detail: with the Draytek 2860N+ I've tried to disable the G.Vector and I did notice that using some old modem codes I cannot even sync with the cab anymore, maybe because the modem its not recognized as "vectoring friendly". Instead, with some newer modem codes I can sync even without Vectoring.
So i think all the connected lines must be vectoring friendly at least, and consequently their crosstalk should be addressed."

So, it wont be a problem theoretycally. 

I've tried xdslctl configure --vectoring off but it does not work.

It is possible that this is over-ridden by the DSLAM.  The Service Provider has the ability to set certain parameters so they cant be over-ridden by configuration by the end user.

ejs found some info which may give further insight into what the codes mean.

Code: [Select]

#define VECT_WAIT_FOR_CONFIG  0
#define VECT_FULL             1
#define VECT_WAIT_FOR_TRIGGER 2
#define VECT_RUNNING          3
#define VECT_DISABLED         4
#define VECT_UNCONFIGURED     5


As for the Vectoring state, I wonder, is it possible that the G.Vector has been turned on for the DSLAM\MSAN only but not for the line profiles? Would the lines be able to sync in Vectored mode in this case, but without the cancellation of FEXT?

[kitz]

Anyway, this is my bitloading:

http://i.imgur.com/siZihuK.png

Thank you for that. 

Regarding the US3 (12MHz-14MHz) its not fully utilizable, maybe because of the UPBO [Upstrem Power Back Off]? Is it possible ?

Looks like there is Upstream PBO in U0 and in U1 - although your U1 PBO is less restrictive than it is in the UK.

If you look my graph below and the top graph I provided in my last post you can see that U1 PBO in the UK is quite harsh and therefore most of our upstream bitloading comes from U2 band.
Anyone who lives within about .5km from a cab never gets more than the 4/2 bitload in U1 as BT uses PSD masks based on distance from cab and distance from the exchange.

Much of the lesser bit loading in your U2/U3 could also possibly be down to the fact that you've already loaded sufficient bins to reach the 21600 bit rate.

[kitz]

I've tried to disable the G.Vector and I did notice that using some old modem codes I cannot even sync with the cab anymore, maybe because the modem its not recognized as "vectoring friendly". Instead, with some newer modem codes I can sync even without Vectoring.
So i think all the connected lines must be vectoring friendly at least, and consequently their crosstalk should be addressed."

Thats good.   I was beginning to wonder if it could be a neighbouring line without a vectoring friendly modem that could possibly be the reason why you'd not seen the improvement.   There are some vdsl2 modems available which do not support any vectoring (ie certain tp-link models). 

As for the Vectoring state, I wonder, is it possible that the G.Vector has been turned on for the DSLAM\MSAN only but not for the line profiles? Would the lines be able to sync in Vectored mode in this case, but without the cancellation of FEXT?

Not sure.   My interpretation of the BT documentation provided by Blacksheep is that in the UK  :-
 - G.Vector will be switched on the DSLAM
 - Full vectoring modems will get a vectoring profile (speed increase). 
 - Both the vectoring friendly and non vector modems wont get a vectoring profile (VDSL2 only)
 - Full vectoring modems will benefit from reduced FeXT coming from both full vectored and vector friendly modems - but FeXT could still be there from non vector modems.
 - Vectoring friendly modems will send FeXT information to the DSLAM but not be able to benefit from FeXT cancellation
 - Non vectored modems will sync, but not in vectored mode.


 - What Im unsure about is whether vector friendly modems sync in vector mode or not.   I'm guessing that it may do because it needs to be able to send FeXT information, but because it cant perform cross-talk cancellation, it just wont get any sort of profile.    Thoughts from ejs/wombat etc?

[kitz]

btw I just found this from Alcatel-Lucent.

Alcatel-Lucent's "Zero-Touch Vectoring" speeds vectoring deployments by eliminating the need to upgrade legacy CPE to vectoring friendly mode.

Just one non-vectoring compliant CPE operating in a vectored cable can create cross talk, which drastically reduces gains on vectored lines. Until now, service providers needed to upgrade all of their existing VDSL2 CPEs to vectoring or vectoring-friendly mode to prevent this cross talk from reducing gains.

Alcatel-Lucent's unique "Zero-Touch Vectoring" solves this problem by automatically handling all legacy VDSL2 CPEs. Firmware upgrades are not required, so legacy VDSL2 CPEs will be vectoring-friendly without needing to be touched. Only those CPE that are being used to provide higher bandwidth vectoring services will need to be upgraded. This provides a quick and easy way for service providers to introduce vectoring in their network, without having to worry at all about legacy VDSL2 CPEs.

[ejs]

I've been reading and trying to understand the ITU-T G.993.2 (VDSL2) and G.993.5 (vectoring) documents.

I'm not really sure if there's any such thing as a "vectoring profile" exactly, I think it would be more accurate to say that the line speed gets improved by the vectoring (or not).

There are two different vectoring friendly modes, Annex X and Annex Y, in the 2015 edition of G.993.2 (which got released to the Internet fairly recently).

Annex X is the simplest one for the CPE, there seems to be very little for the CPE to do, besides indicating its support for Annex X to the DSLAM, I think it mainly needs to just ignore the different vectoring-related signals the DSLAM might send down the line. G.vector lines can cancel the crosstalk from Annex X lines for the downstream direction only, not upstream.

Annex Y, "full friendly" operation, allows G.vector lines to cancel crosstalk from the Annex Y line for both downstream and upstream. The CPE needs to do more things to support Annex Y than Annex X, in fact I think it says Annex Y requires everything in G.993.5 except for sending those error samples.

This has led me to the conclusion that in order for the vectoring engine at the DSLAM to cancel the crosstalk on your line, and give you a speed boost from vectoring, it needs the error samples from your line. So for Ramino's line, if the zero error samples sent counters are reliable, then I think that indicates that Ramino's line isn't currently benefiting from vectoring.

[kitz]

I'm not really sure if there's any such thing as a "vectoring profile" exactly,

From Ramino's question, when talking about profiles I was assuming it may be related to how it could affect any DLM profiles.    I was going to try doing some reading up but never got around to it.. so thank you for trying to look into it.

[WWWombat]

Thoughts from ejs/wombat etc?

I've only just caught this thread. And unfortunately, I've let my search for vectoring knowledge lapse somewhat since BT went somewhat cold on the idea, so I've little to add.

My early thoughts, back at the beginning of the thread, were that the data could be showing that the modem has G.vector support enabled, but that the DSLAM hadn't made use of it yet - which would fit with the lack of error samples being moved around - so vectoring wasn't occurring. However, the explanations that go alongside the state values seem to tell a different story. I'd love to see the state diagram that goes with those state values.

As @ejs found some new specs released, I'm going to have to educate myself further with those before I can add any useful input...

[krypton]

My early thoughts, back at the beginning of the thread, were that the data could be showing that the modem has G.vector support enabled...

The stats at the first page come from my device. After a new vectoring capable DSLAM was installed the state code changed from 5 to 1. G.vector support was already enabled on the modem before. I don't think the codes only indicate if the modem has G.vector support enabled/disabled.

Hopefully the vectoring data will be available at MyDSLWebStats someday to compare with other lines and find out what these codes actually mean.

[Ramino]

@ kitz, ejs, WWWombat , morphium
Thanks for your hits\assumptions

I've been reading and trying to understand the ITU-T G.993.2 (VDSL2) and G.993.5 (vectoring) documents.

I'm not really sure if there's any such thing as a "vectoring profile" exactly, I think it would be more accurate to say that the line speed gets improved by the vectoring (or not).

There are two different vectoring friendly modes, Annex X and Annex Y, in the 2015 edition of G.993.2 (which got released to the Internet fairly recently).

Annex X is the simplest one for the CPE, there seems to be very little for the CPE to do, besides indicating its support for Annex X to the DSLAM, I think it mainly needs to just ignore the different vectoring-related signals the DSLAM might send down the line. G.vector lines can cancel the crosstalk from Annex X lines for the downstream direction only, not upstream.

Annex Y, "full friendly" operation, allows G.vector lines to cancel crosstalk from the Annex Y line for both downstream and upstream. The CPE needs to do more things to support Annex Y than Annex X, in fact I think it says Annex Y requires everything in G.993.5 except for sending those error samples.

This has led me to the conclusion that in order for the vectoring engine at the DSLAM to cancel the crosstalk on your line, and give you a speed boost from vectoring, it needs the error samples from your line. So for Ramino's line, if the zero error samples sent counters are reliable, then I think that indicates that Ramino's line isn't currently benefiting from vectoring.

Your analysis are really interesting and I think what you said might be true.

I think that the CPE are really using the G.Vector but maybe something DSLAM-side is not properly configured to bring the vectoring fully operable yet.

[numero53]

Hi everyone,
I own a Tp-Link W8970 with OpenWrt on it. These are my stats:

Code: [Select]

/etc/init.d/dsl_control status
ATU-C Vendor ID:                          Broadcom 176.199
ATU-C System Vendor ID:                   Broadcom
Chipset:                                  Lantiq-VRX200 Unknown
Firmware Version:                         5.7.5.5.1.7
API Version:                              4.16.6.3
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:                                    B
Line Mode:                                G.993.5 (VDSL2 with down- and upstream vectoring)
Profile:                                  17a
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 65639
Errored seconds (ES):                     Near: 0 / Far: 1028
Severely Errored Seconds (SES):           Near: 0 / Far: 35
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 4
Unavailable Seconds (UAS):                Near: 139 / Far: 139
Header Error Code Errors (HEC):           Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency / Interleave Delay:               Down: Interleave (0.13 ms) / Up: Interleave (0.0 ms)
Data Rate:                                Down: 31.173 Mb/s / Up: 3.112 Mb/s
Line Attenuation (LATN):                  Down: 7.6dB / Up: 8.8dB
Signal Attenuation (SATN):                Down: 7.6dB / Up: 8.1dB
Noise Margin (SNR):                       Down: 24.5dB / Up: 26.2dB
Aggregate Transmit Power(ACTATP):         Down: -21.-4dB / Up: 12.2dB
Max. Attainable Data Rate (ATTNDR):       Down: 87.405 Mb/s / Up: 29.116 Mb/s
Line Uptime Seconds:                      268891
Line Uptime:                              3d 2h 41m 31s
As you can see my VDSL2 profile is 30M/3M and vectoring seems to be enabled.
However (as Ramino said before) vectoring is not enabled here (I am Italian too). Probably it only indicates that both CPE and DSLAM are at least vector-friendly...

In the attachment there are other info about my line (DPBO seems to be active... look at the hole near the 450th tone). I've done these graphs with google spreadsheet that's why they are so ugly....

P.s. Thanks to this forum I managed to enable G.INP in Upstream some months ago (it wasn't enabled by default because of the Lantiq chipset). So thank you a lot! Now I can write you 4ms earlier!

[attachment deleted by admin]

[burakkucat]

Welcome to the Kitz forum. 

As you can see my VDSL2 profile is 30M/3M and vectoring seems to be enabled.
However (as Ramino said before) vectoring is not enabled here (I am Italian too). Probably it only indicates that both CPE and DSLAM are at least vector-friendly...

Yes, I would agree with that assumption. The equipment is capable but software-wise the mode has not been enabled.

In the attachment there are other info about my line (DPBO seems to be active... look at the hole near the 450th tone).

That certainly looks like DS PBO. It has the right sort of shape.