Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: Ramino on March 15, 2016, 06:12:01 AM
-
You can use the following command:
xdslctl info --vectoring
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 37534 Kbps, Downstream rate = 93184 Kbps
Bearer: 0, Upstream rate = 11007 Kbps, Downstream rate = 55039 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Vectoring state: 1
VCE MAC Address: 0:10:fc:20:0:0
Total error samples Ethernet pkts sent: 131290
Total error samples Ethernet pkts discarded: 0
Total error samples statuses sent: 65645
Total error samples statuses discarded: 0
I don't know all state codes but on my line I saw this:
Vectoring state: 1 vectoring enabled
Vectoring state: 5 without vectoring (Without vectoring "VCE MAC" and "Total error samples" are all zero.)
Maybe codes 2,3 or 4 indicate vectoring friendly mode.
Hi. I'm just registered on this forum cause I hope you can help me to understard better whats happened to my line.
I live in Italy and some weeks ago after a disconnection the Zyxel VMG-8924 shows "G.Vector enable" but I haven't see any improvement in terms of SNRm or max attainable rate:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FLQeMc6L.png&hash=6841bc25d4ab324ae80115950b2c3b897cf7f734)
Through the latest version of DSLstats I see "1 [Vect_Full]" from Stats:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FewTnQPx.png&hash=e1173ad05572bcad3960339fe0f35e1bf187d1e7)
But in the Vectoring tab all the counter "total error samples" are always stuck to zero as you can see:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FBB1RX9h.png&hash=3e1ec05af3a7adbc469ae28e409a817b2c7b0f30)
So do you think that G.Vector is really working or not? How much improvement did you see on your line since Vectoring has been enabled?
Thanks to any comment. :)
-
@Ramino: Welcome to the forum. I've split your post into a separate topic.
We have very little experience of this subject in the UK, but it's of great interest, and others may have information to add.
-
@Ramino: Welcome to the forum. I've split your post into a separate topic.
We have very little experience of this subject in the UK, but it's of great interest, and others may have information to add.
Thank you roseway. :)
We have little experience here too, in fact we're waiting for the MOV [Multi-Operator Vectoring], some says that maybe will be ready for the end of 2016.
So, its not clear if some ISP are enabling vectoring somewhere before the MOV.
I wonder if the G.Vector is able to cancel the crosstalk completely or only the majority of it.
Anyway, its an interesting subject. :)
-
@Ramino what sync speeds are you expecting when G.Vector is up and running properly for you?
-
@Ramino what sync speeds are you expecting when G.Vector is up and running properly for you?
When I've been activated 2 years ago (first user on the cabinet, and there is only one cabinet at the moment) I had an higher "max attainable rate" (125mbit, now 110mbit) so I would expect to regain all the bitrate with G.Vector, but its not the case.
So I wonder if vectoring is really working or not, otherwise the loss of bitrate is due to other factors than crosstalk.
-
One possibility is that you do have G.Vector enabled but the modem isn't reporting the total error samples values. Do you have the latest firmware in the VMG8924?
-
One possibility is that you do have G.Vector enabled but the modem isn't reporting the total error samples values. Do you have the latest firmware in the VMG8924?
Yes the latest 13C0.
I've just tried with the Netgear D7000, same result, the error samples are all 0:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FvlwXFR6.png&hash=8082a3f0923a7f66a215412860496424eceefd3d)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FKjwFN0J.png&hash=1a292a30f96f83c963edec840fd7925fda9c10ca)
-
Is G.INP on the upstream set to enabled as standard in Italy ?
-
Is G.INP on the upstream set to enabled as standard in Italy ?
Yes
-
Is G.INP on the upstream set to enabled as standard in Italy ?
Yes
I thought so the UK must be the only country in the world that has it disabled as standard ::)
-
Haha, NewtronStar is thinking "Blooming Openreach!". Haha! I think Italy have it better than us by far! No line rate capping, vectoring and G.INP on Upstream...
-
Haha, NewtronStar is thinking "Blooming Openreach!". Haha! I think Italy have it better than us by far! No line rate capping, vectoring and G.INP on Upstream...
I think we are ALL jealous! Just look at those connection speeds!
-
So do you think that G.Vector is really working or not? How much improvement did you see on your line since Vectoring has been enabled?
It seems like it is enabled but I'm not aware why you don't see an improvement. If you post your qln-graph maybe someone can say something to the crosstalk on your line. Probably you don't have any disturbers or their hardware isn't vectoring capable and still generating noise.
On my line 2 weeks ago g.inp and vectoring was enabled and the speed increased a bit.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fabload.de%2Fthumb%2Fvect.speed3opay.png&hash=b1a9e2f07df6f3be382d91cb2bb7135eafc4f1cd) (http://abload.de/img/vect.speed3opay.png)
The improvement depends on how much crosstalk can get cancelled.
My ISP made tests to show how much speed can be recovered with vectoring.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fabload.de%2Fthumb%2Fvectoringlrr82.png&hash=f575860712cd1db65eb86a8b87c096e6c9f5a612) (http://abload.de/img/vectoringlrr82.png)
-
On my line 2 weeks ago g.inp and vectoring was enabled and the speed increased a bit.
Why have you not re-synced the modem to gain that extra sync if vectoring has been enabled on your line as your attainable is at 92644 Kbps ?
Or have you manually capped your sync
-
It is capped from the ISP side, maybe it gets higher after some time. I don't know if some sort of DLM is running here.
Unfortunately the line isn't very stable (overhead cable + moisture) so it's more reliable to have some additional margin.
-
Connection speed 107999 VDSL2 Profile 17a
As an aside I thought the theoretical max speed for VDSL2 was 100Mbps.
I was beginning to think I was being stupid, so I went and double checked. According to ITU G.993.2 specs (https://www.itu.int/rec/T-REC-G.993.2) it is indeed 100Mbps - max power 14.5dBm
but I haven't see any improvement in terms of SNRm or max attainable rate:
I wondered if you are lucky enough not to have any crosstalkers... then I saw this "I had an higher "max attainable rate" (125mbit, now 110mbit)".
Can you recall your sync speed when you had the 125Mbps max rate?
Out of interest what are your Band Plans (Medley) eg from the pbParams tab
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
-
Connection speed 107999 VDSL2 Profile 17a
As an aside I thought the theoretical max speed for VDSL2 was 100Mbps.
I was beginning to think I was being stupid, so I went and double checked. According to ITU G.993.2 specs (https://www.itu.int/rec/T-REC-G.993.2) it is indeed 100Mbps - max power 14.5dBm
I thought 250Mbps. Wonder where I got that from.
-
I thought it was 150 Mbps, didn't someone run some tests with their own equipment.
-
I thought 250Mbps. Wonder where I got that from.
Hmm, you're never not alone - I thought VDSL2 had a theoretical maximum of 250 Mbit/s as well..
-
Only theoretical though
The 17MHz VDSL2 profile (17a) uses 4095 tones, with an effective symbol rate of 4kHz. This gives the following total system capacity: 4000 DMT symbols/s * 4095 tones/symbol * 15 bits/tone = 246Mbps to be shared between the two directions.
-
Connection speed 107999 VDSL2 Profile 17a
As an aside I thought the theoretical max speed for VDSL2 was 100Mbps.
I was beginning to think I was being stupid, so I went and double checked. According to ITU G.993.2 specs (https://www.itu.int/rec/T-REC-G.993.2) it is indeed 100Mbps - max power 14.5dBm
In "Table 6-1 – VDSL2 profiles" of G.993.2, the 100Mbps for profile 17a is the minimum maximum speed that the equipment needs to be capable of (upstream+downstream).
-
Indeed whilst 17a may have a total of 4095 tones.. Its split between upstream & downstream and its the 'Annex' which defines which tones are used for what direction. (We dont use U3 and U4)
As with adsl, some tones arent in use at all. Prime example being the guard bands (eg 858-881 & 1194-1217 etc which are between D1-U1 & U1-D2 etc respectively).
Then theres also such things as PCB and PSD masks which ensure that it is impossible to load 15 bits at certain tones.
This is why I was specifically interested in seeing the Band Plan/Medley figures. I'd already checked the Annex (B) and profile (17a)
It would also be interesting to see a bit loading graph to see if there is any obvious power cut back at certain tones. Vectoring is supposed to help crosstalk.. and the main reason for PCB is to prevent crosstalk, so I wondered if made any difference.. although I doubt it as there will still be the likely-hood of other technologies such as adsl/adsl2+ being available in the same bundle.
-
the 100Mbps for profile 17a is the minimum maximum speed that the equipment needs to be capable of (upstream+downstream).
Thanks ejs. I had seen 100Mbps mentioned elsewhere too, which is why I had that figure in my head - such as wikipedia (https://en.wikipedia.org/wiki/Very-high-bit-rate_digital_subscriber_line_2#Profiles)
-
Is G.INP on the upstream set to enabled as standard in Italy ?
Yes
I thought so the UK must be the only country in the world that has it disabled as standard ::)
Why does the G.INp on upstream is disable by default in UK?
I remember there were some issues with Lantiq for the G.INP on upstream till the end of 2014, but now the problem has been fixed with the new xdsl driver. I got a Draytek 2860NPlus also, and the first firmware with G.INP fully operable came out on March 2015. ::)
Maybe some UK ISP are providing modem-router equipped with lantiq chipset?
So do you think that G.Vector is really working or not? How much improvement did you see on your line since Vectoring has been enabled?
It seems like it is enabled but I'm not aware why you don't see an improvement. If you post your qln-graph maybe someone can say something to the crosstalk on your line. Probably you don't have any disturbers or their hardware isn't vectoring capable and still generating noise.
On my line 2 weeks ago g.inp and vectoring was enabled and the speed increased a bit.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fabload.de%2Fthumb%2Fvect.speed3opay.png&hash=b1a9e2f07df6f3be382d91cb2bb7135eafc4f1cd) (http://abload.de/img/vect.speed3opay.png)
The improvement depends on how much crosstalk can get cancelled.
My ISP made tests to show how much speed can be recovered with vectoring.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fabload.de%2Fthumb%2Fvectoringlrr82.png&hash=f575860712cd1db65eb86a8b87c096e6c9f5a612) (http://abload.de/img/vectoringlrr82.png)
Hi, thank you very much for the respose.
These are my QLN and Hlog.
QLN: http://i.imgur.com/Uoakcq8.png
Hlog: http://i.imgur.com/rNwdh05.png
As for the hardware I think the majority of pepole here are using the modem provided by the ISP. Its a Technicolor equipped with the same broadcom chipset [BCM63168] as the Zyxel (with vectoring support).
Furthermore, I think that almost all devices would support G.Vector properly by now in 2016 , theoretically at least. :)
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.
Anyway I wonder what the "error samples" are reffering to. Samples of what? The condition of the line that serves the DSLAM to remove the crosstalk?
Connection speed 107999 VDSL2 Profile 17a
As an aside I thought the theoretical max speed for VDSL2 was 100Mbps.
I was beginning to think I was being stupid, so I went and double checked. According to ITU G.993.2 specs (https://www.itu.int/rec/T-REC-G.993.2) it is indeed 100Mbps - max power 14.5dBm
but I haven't see any improvement in terms of SNRm or max attainable rate:
I wondered if you are lucky enough not to have any crosstalkers... then I saw this "I had an higher "max attainable rate" (125mbit, now 110mbit)".
Can you recall your sync speed when you had the 125Mbps max rate?
Out of interest what are your Band Plans (Medley) eg from the pbParams tab
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
Hi, my Band Plans are the following:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FlkHWWyN.png&hash=a8d6b148ddc9c391aeb509960e9a51f19c0f1247)
What do you think about it? Are there some remarkable differences from yours or is it almost identical?
When I had 125mbit of attainable the sync speed was the same.
We have currently 2 profile: 50\10 and 100\20 and the bitrate respectively are: 54000*10800 and 108000*21600, so 108000 is the maximum for downstream. :)
Regarding the max speed, as someone already suggested in real pratice its a bit higher than 100mbit.
Anyway, someone knows the commad to disable the G.Vector with a broadcom modem? I would try to see which number I get without Vectoring.
I've tried xdslctl configure --vectoring off but it does not work.
[Moderator edited to adjust the links to the QLN & Hlog plots.]
-
Your Band Plans are definitely a Huawei MSAN and you are able to use all tone available to you as seen in the Medley Phase (Final) Band Plan you must be like 100 meters from the FTTC cabinet :-\
-
There seem to be a couple of significant differences regarding band plans, not least the use of the U3 band (although the QLN & Hlog graphs don't actually show any data for it).
UK ECI DSLAM:-
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
UK Huawei DSLAM:-
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
or:-
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3950)
Ramino (probably Huawei):-
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2783) (2784,3107)
DS: (33,859) (1216,1961) (3256,4071)
I wonder if any of Ramino's U0 band is actually used for bitloading. I thought that was mainly a UK thing to help with the typically longer distances from the cabinets.
-
Maybe some UK ISP are providing modem-router equipped with lantiq chipset?
Basically: YES!
-
Hi, my Band Plans are the following:
Thanks - a couple of different band plans than here in the UK.
The most notable differences are:-
- You have a U3 band (at tones 2784 - 3107) which isnt in use in the UK
- Because of this, your downstream D3 starts much later at tone 3256, whereas in UK its 2793/2795 depending on cab type
U0, U1, U2, D1 & D2 are the same.
We have currently 2 profile: 50\10 and 100\20 and the bitrate respectively are: 54000*10800 and 108000*21600, so 108000 is the maximum for downstream.
Thank you for that confirmation.
Our main two bit rates are 40000*10000 & 80000*20000. This means max throughput of around 76 Mbps
There was talk about raising it to 100Mb with vectoring but all seems to have gone quiet on that front atm :(
I still wouldn't mind seeing your bit loading.
Here in the uk due to PCB and PSD masks there are several tones that can never fully load. - see below for a couple of examples.
Note I had typed this last night as can be seen by the screen cap time... and must not have hit the post button before hitting my bed as it was still on my PC screen today. Apologies that BaldEagle has also said some of this since.
-
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 (http://forum.kitz.co.uk/index.php?topic=14361.1215) found some info which may give further insight into what the codes mean.
#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
Black Sheep (http://forum.kitz.co.uk/index.php/topic,15190.msg282700.html#msg282700) 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. :/
-
I think the xdslctl command does not recognise --vectoring for the configure sub-command. I don't think there's anything the DSLAM could do, besides not allow you to connect, if you set your modem to claim that it does not support vectoring. I don't know if or how to disable it, you're probably not supposed to want or need to.
-
@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 (http://forum.kitz.co.uk/index.php/topic,15190.msg282700.html#msg282700) 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 (http://forum.kitz.co.uk/index.php?topic=14361.1215) found some info which may give further insight into what the codes mean.
#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?
-
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.
-
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?
-
btw I just found this (https://www.alcatel-lucent.com/solutions/vdsl2-vectoring) 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.
-
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.
-
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.
-
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...
-
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.
-
@ 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.
-
Hi everyone,
I own a Tp-Link W8970 with OpenWrt on it. These are my stats:
/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.... ;D
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! :D
[attachment deleted by admin]
-
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.