Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: digitalis on May 18, 2016, 12:17:24 PM
-
My bosses connection just dropped, it's come back up with the highest sync ever seen (66mb) and the draytek says Vectoring active
-
In a bit of a rush so I'll add more details later, but look below. I don't think it's a bug on the draytek because Vectoring certainly wasn't there before the line drop
(https://i.imgsafe.org/d643401.png)
-
G997 is a strange one?
Line stats
ATU-R Information
Type: VDSL2
Hardware: Annex A
Firmware: 05-07-06-0D-01-07
Power Mngt Mode: DSL_G997_PMS_L0
Line State: SHOWTIME
Running Mode: 17A
Vendor ID: b5004946 544e0000
ATU-C Information
Vendor ID: b5004244 434da48c [BDCM]
Line Statistics
Downstream Upstream
Actual Rate 66294 Kbps 18660 Kbps
Attainable Rate 65666 Kbps 18661 Kbps
Path Mode Fast Fast
Interleave Depth 1 1
Actual PSD 7. 7 dB 13. 9 dB
(https://i.imgsafe.org/20c2244.png)
[Moderator edited to remove multiple blank lines.]
-
Is it a BDUK cabinet?
-
Yes.
-
Makes sense it was always on the cards that BTs implementation of Vectoring was going to be very limited and only really used to help meet BDUK targets for the time being.
If only they'd fully roll it out. :'(
What improvement did vectoring give this line?
-
Went from 52mb pre-G.INP to 60mb G.INP, then a further boost to 66mb with Vectoring
-
Oooh... that's certainly the right symptom to be looking for.
Can you tell if you're getting more or less errors? With G.INP active, you'd be looking at the FEC rate and the retransmission-transmitted counter.
Knowing the distance and attenuation can help too. However, I know very little about the Drayteks. I'm not sure which of the two attenuation figures we should use as the Downstream attenuation. If it is the 26dB value, then that's a good speed. If it is the 18dB, then it is merely decent.
G997 is a strange one?
Power Mngt Mode: DSL_G997_PMS_L0
Line State: SHOWTIME
G.997 is all about the mechanisms for network management of a DSL physical link - which is the mechanism by which the link behaviour can be altered (such as setting the line profiel by DLM) or be manipulated (eg, by forcing a diagnostic mode).
PMS is likely to be a "power management state"; L0 likely means full showtime, with everything transmitting.
-
Not sure, I forgot to set up remote management so will have to check again tomorrow.
Is Vectoring a new thing or am I just late to the party? Can't find much info on it.
-
Vectoring technology per-se is not a new thing ............ having it applied to the UK DSLAM's is. :)
-
There are a few bits of it out there for sure, was announced a few months ago that it was going to be applied hither and thither on a 'tactical' basis.
It's not getting fully rolled out. Lots of expense for very little gain.
-
Does it actually cost any extra on a Huawei cabinet though? In that as I understand it, those line cards already support vectoring so it's largely just a config change?
Of course, those on ECI cabinets wouldn't be so happy not if Openreach did this.
-
Does it actually cost any extra on a Huawei cabinet though? In that as I understand it, those line cards already support vectoring so it's largely just a config change?
It needs install of a Vectoring Engine Board.
If it were just config it'd already be rolled out.
-
There are a few bits of it out there for sure, was announced a few months ago that it was going to be applied hither and thither on a 'tactical' basis.
It's not getting fully rolled out. Lots of expense for very little gain.
TBH, it's actually very little expense for OR to make a vector-capable Cab 'live'. The gains are mainly between 10-16% of extra bandwidth, so I suppose the decision lies with the EU as to whether the gain is worth it ...... for free ??
-
The VEBs do cost a few quid and a few tens of thousands of them add up, especially when it's being done for absolutely no commercial benefit to Openreach.
Useful alongside LR-VDSL to hit BDUK and USC targets definitely. No real point in putting them into cabinets like the ones covering me.
-
Current projections are for less that 900 Cabs to have vectoring deployed. I won't quote the figure for the vectoring engine cards, but they are very cheap for the gains they will bring to both the EU, and/or the commercial targets BTOR have been given.
Just my humble opinion. :)
-
I would have thought rolling out vectoring would be an advantage in that by removing crosstalk it would encourage some on existing cabinets who can't get 55/80mb to upgrade to faster speeds and increase data usage - as well as more stable lines (less faults?)
Of course, one shouldn't also forget the expected benefits of introducing a 3db profile where BT expect:
100% average increase of 10%
90% average increase of 15%
50% average increase of 17%(i.e.the median increase expected)
-
What value does it bring to CPs though, beyond maybe fewer faults, although crosstalk rarely has them raised from what I can see?
CPs don't want higher data usage. They would be quite happy with people paying and not doing anything :)
-
The benefit would largely fall to Openreach who would benefit from the higher data usage (+ less demand for engineer visits) and to the end users who get the higher speeds.
You are right it would be of less direct interest to CP's though they may sell some more expensive retail packages and fewer support calls - unless it comes down to the need to offer higher speeds to compete with cable. (Edit: and of course their CPE already supports the technology)
Of course, with something like vectoring, it's Openreach's decision if they want to roll it out - the CPs don't have much say..
-
unless it comes down to the need to offer higher speeds to compete with cable.
There is no competition with cable in terms of higher speeds. G.fast will be left behind on headline speeds immediately. Speaking with some CPs they accepted that headline speed competition isn't going to happen a while ago.
Higher usage isn't really of much benefit to Openreach either. They may sell an additional Cablelink here and there but it's not like a BT Wholesale usage based billing arrangement.
-
TBH we would be better off with a SNRm of 3dB profile than Vectoring as it costs nothing & no hardware needed and has the same result or even better than vectoring
-
Both would be better still.
Neither and G.fast or FTTP would be yet better. FTTC / VDSL is last decade regardless of vectoring or SNR margins.
-
I do think ignition is been a bit harsh/cold in his opinion. Even black sheep see's a benefit in rolling this technology out.
The problem is how BT are looking at the value of the technology. Sadly they seem to be adopting VM's method of thinking now.
In terms of value in the following areas, the benefits of vectoring are huge, this is further amplified by the fact that g.fast will not be available to many in the forseeable future meaning vdsl2, is the best BT will be offering.
Customer Satisfaction
Line stability
Fault Reports - yes many faults are complaints about loss speed due to crosstalk. also that even if a disturber doesnt affect line speed, they can affect error rate which in turn can trigger DLM.
Speed of line, even the modest gains from openreach data (which are low compared to trials) of 10-16% is enough for user's to be grateful.
My line as an example, when I first got this pair I had circa 0-3 ES a day on my US and about 120-150 a day on the DS. Even tho my US speed hasnt really dropped the error rate is now about 30-80 a day and the DS about 150-300 a day (with the DS losing about 2mbit of sync speed in the time period).
Also the cost of the cards in the grand scheme of things is actually small for a company with BT's turnover. The problems is their accountants obsess over "every" cost whether small or big, and have probably very coldly only looked at what marketing gain vectoring brings, which sadly is none. Its all about marketing these days, not customer satisfaction or reduced level of faults. I suspect if openreach wasnt behind a shield of CPs (dealing direct with consumers) things may be a different story. To put into perspective, vectoring cards will definitely be cheaper than deploying g.fast cards and benefit almost everyone, but the latter offers something new to market hence been approved.
-
I suspect you strongly overestimate how much the people for whom broadband delivers the Netflix in Netflix and chill are really bothered about such things.
-
yeah but those people wont care for g.fast either to be fair, vdsl2 is enough for them to watch netflix without issues.
-
True, though it makes for good marketing.
If it were really such a big deal for end users and hence CPs they would be climbing all over Openreach for vectoring - they aren't.
-
Sadly there's only a very small percentage of EU who know anything about broadband, that's probably why there's not more complaints. I for one would like vectoring, especially if it was to improve my upstream which has halved since I've had FTTC.
-
Well of course everyone would want vectoring if it's going to make things better and not cost you any extra.
If there are going to be endless complaints about how it's unfair that some people have got vectoring but they don't, I'd rather no-one at all had it, then they'd be less complaints about the unfairness of the situation.
-
Most people don't know much about many of the services and products they consume.
There aren't more complaints because most people have far better things to do than worry about a service that, from their point of view, serves their needs.
Given how this forum has become dominated by posts on G.inp I dread to think what would happen were Openreach to set about a large vectoring programme - Huawei would inevitably get it first as it's just a line card, and people here would be jumping up and down raising complaints with everyone from their ISPs to Ofcom to their MPs to whichever, if any, deity or deities they worship.
EDIT: Amusingly I write this in full knowledge that if a vectoring deployment were to happen I'd probably be at the back end of it due to needing node level.
-
There aren't more complaints because most people have far better things to do than worry about a service that, from their point of view, serves their needs.
Not really, I know someone who's been complaining for a long time that his broadband is slow, he's still on 8Mbps ADSL when he lives pretty much on top of his FTTC cabinet. He did get as far as phoning his ISP who said his connection was going as fast as it could :wall: I've no idea why they didn't suggest upgrading to FTTC as it is available. There must be loads of people who'd benefit from better speeds but just aren't savy enough to sort it out.
-
'Most'.
-
I think it is fair to say that BT were fully behind vectoring. Right up until the point that it totally disappeared off the radar. Not coincidentally, BT announced their G.Fast plans at the same time.
It was a technology that was considered worth introducing, in the strategy that BT were following at the time. The changes were even being introduced in the back-office systems; this was no mere decision that vectoring was not worthwhile.
It has suffered from a change in strategy. Someone in BT has put together a G.Fast strategy that has become compelling to the men with the money, and as a side-effect has jettisoned vectoring. Perhaps the G.Fast strategy needed the money being allocated to vectoring. Perhaps the G.Fast strategy needed the boost in take-up that would come from NGA users on lower, crosstalk-induced speeds. Perhaps the G.Fast strategy needs space in the existing DSLAMs that prevents vectoring-capable cards being added. Who knows?
Whatever the reason, it is fair to say that the strategy shift has won out over the possible gains from vectoring, save some limited cases that are beneficial to BT rather than end users.
I don't see much point in harking after it.
-
All i will say is i have gone from a Sync of 65Mb down to 46Mb the majority of which is down to crosstalk, Now I don't care what is used be it Vectoring, Gfast or pixie frigging dust but it would be rather nice if i Could get the speed I once had back after all i'm still paying the same price for 20Mb less is it really asking that much, i'm sure if you asked everyone that has lost speed due to crosstalk if they wanted it back to where they were they would say yes.
-
Openreach SNR 3dB profile on FTTC is more than welcome for a very long distance from the street cabinet. But, as for vectoring, not sure about this roll out as BT are pushes for g.fast rolled out next summer in 2017.
-
To me it's very annoying to see money being put into this project with testing an so on and then put in the bin because something better is on the horizon this G.FAST thingy which won't help anyone on a long line.
-
I doubt the amount of money spent testing/introducing this has been that large.
Openreach (and other firms) have a long history of testing technologies which they don't introduce for various reasons. For instance, on ADSL, Openreach never introduced SRA or g.inp despite testing them both.
As WWWombat suggests it's obvious that g.fast has already far exceeded what was originally thought possible and will continue to improve causing a rethink about a number of issues - such as the size and speed of a FTTP rollout and the introduction of profile 30a - not just vectoring..
-
That sounds fine yet G.Fast is of no use to users on longer lines 700 meters + so to me G.FAST is just directed for short lines IE citys large towns & highly populated suburban areas and we are left with this old 40 Mbps VDSL2 tech, they should be rolling out the all in one cabinets no less than 300 meters from any household
And then rollout G.FAST :)
-
I doubt the amount of money spent testing/introducing this has been that large.
Openreach (and other firms) have a long history of testing technologies which they don't introduce for various reasons. For instance, on ADSL, Openreach never introduced SRA or g.inp despite testing them both.
As WWWombat suggests it's obvious that g.fast has already far exceeded what was originally thought possible and will continue to improve causing a rethink about a number of issues - such as the size and speed of a FTTP rollout and the introduction of profile 30a - not just vectoring..
again its all down to what helps marketing. Something me and ignition both are in agreement on.
Sadly vectoring wont push extra sales, g.fast might. I would be surprised if the cost of vectoring is that big, but the problem is just because its not big it doesnt mean it doesnt need approval. Every investment expense has to be approved by the people with the purse strings.
g.fast will have also killed any possible profile 30a I think, they want the performance gap between vdsl and g.fast as big as possible, profile30 would reduce it.
-
yet G.Fast is of no use to users on longer lines 700 meters +
You're assuming too much for something already touted to be a decade-long rollout.
BT know that, if g.fast is going to be truly at the core of their network ambitions, then they need to put nodes further out in the network. They openly say this themselves.
Who knows when it will happen? Day 1? Phase 1? Or Phase 27 some 4 years down the line? But it will be happening.
-
g.fast will have also killed any possible profile 30a I think, they want the performance gap between vdsl and g.fast as big as possible, profile30 would reduce it.
If an advance were going to be selected today, you'd choose profile 35b instead, retaining more compatibility with 17a.
However, migration options afterwards would be limited. Choose 35b, and the next step is FTTP. Choose g.fast instead, and the next option becomes the next varieties of g.fast before FTTP. But 35b pretty much precludes g.fast as an option.
-
You're assuming too much for something already touted to be a decade-long rollout.
10 years seem a long time to wait yes it's supposed to start in the summer of 2017 i'll be an old man in his sixty's by the time it gets to this line or the grim reaper engineer will have made a end-users premises visit :ouch:
We just wanna see VDSL2 SNRm 3dB profile and Vectoring soon as OR are so slow in development & deployment by the time it's rolled out it has become old technology :(
-
10 years seem a long time to wait
Yup. Some lucky blighters will be at the right end of the decade, some at the wrong end. I seem to have been at both ends in different rollouts (very early in ADSL, very late in ADSL2+)
On the other hand, my last house was one of those places built just after VM (NTL at the time) stopped bothering to build their network. Over 20 years on, and it remains a pocket of unserved properties surrounded by cable coverage. The rollout lottery isn't just a feature of BT!
I just calculated, and figured I was on ADSL for 6 years, ADSLmax for 5 years, and have been on FTTC for 5 years. I suspect I won't be too worried if I continue on FTTC for another 5 years - I'm sure the speed will be enough.
-
I just calculated, and figured I was on ADSL for 6 years, ADSLmax for 5 years, and have been on FTTC for 5 years. I suspect I won't be too worried if I continue on FTTC for another 5 years - I'm sure the speed will be enough.
I was on the up to 256 Kbps 2005 then 512 Kbps 2006 and then ADSL 4Mbps 2007 and now 35Mbps with VDSL2 2012 so by 2027 i'll should be getting 304 Mbps :)
-
We just wanna see VDSL2 SNRm 3dB profile and Vectoring soon as OR are so slow in development & deployment by the time it's rolled out it has become old technology :(
Openreach just can't win. Either they take the time to test things and are told they are slow at rolling things out or As with the ECI g.inp upgrade are blamed for not testing things enough.
As it is, with g.fast I understand BT are ahead of the curve with their deployment plans and given the rate the technology is progressing, those who are slightly later in the rollout will benefit from much better/mature kit.
On the other hand, my last house was one of those places built just after VM (NTL at the time) stopped bothering to build their network. Over 20 years on, and it remains a pocket of unserved properties surrounded by cable coverage. The rollout lottery isn't just a feature of BT!
Yes, we are in one of these areas. Videotron, as was, covered about 10% of the properties on our street and the rest have never been done. They don't even have the excuse if it being a new build area..
-
As it is, with g.fast I understand BT are ahead of the curve with their deployment plans and given the rate the technology is progressing, those who are slightly later in the rollout will benefit from much better/mature kit.
But are the end-users modems ready for the G.Fast deployment I know my Broadband kit is not G.Fast compatible and here we go again
Just a cut&paste
In the home environment the main approach will function in a not dissimilar way to the current VDSL based FTTC service, which means that you will need to plug your phone cable into a special G.fast equipped modem or a combined modem + router device (ignore the bottom end-user ONT in the diagram below as that’s more for the FOD2/FTTP part of BT’s trial).
-
But are the end-users modems ready for the G.Fast deployment I know my Broadband kit is not G.Fast compatible and here we go again
It doesn't need to be given that Openreach will be providing modems as part of the install process (as they did in the early days for both ADSL and FTTC).
I suspect it will be some years before we see 3rd party affordable g.fast modems.
-
Openreach just can't win. Either they take the time to test things and are told they are slow at rolling things out or As with the ECI g.inp upgrade are blamed for not testing things enough.
As it is, with g.fast I understand BT are ahead of the curve with their deployment plans and given the rate the technology is progressing, those who are slightly later in the rollout will benefit from much better/mature kit.
Yes, we are in one of these areas. Videotron, as was, covered about 10% of the properties on our street and the rest have never been done. They don't even have the excuse if it being a new build area..
The ECI upgrade is not how long they tested but rather "how" they tested.
Picking random customers to test, then not informing them and having no clue what devices they using is not the way to go.
Regarding technologies yes thats a mixed beast, but openreach are not some innocent entity here which is powerless, they made business decisions to skip certain technologies and to also not extend fiber on the initial g.fast rollout. They have also made a business decision when they did the FTTC rollout to do no network rearranging which led to a inefficient network layout in terms of distance to cabinet. Of course finally the dual vendor issue which has bited them more than once. (yes on adsl max one vendor was better than the other, but was less pronounced).
-
I suspect it will be some years before we see 3rd party affordable g.fast modems.
It is interesting to see Sckipio proposing a different model for this - where the end user's router no longer connects to a separate 3rd party standalone modem. Instead, they propose that the modem is in the form of a pluggable SFP - rather like pluggable optics for enterprise and telco switches and routers.
They see G.Fast modem hardware as developing fast for the next few years, so worth keeping separate from the router.
And it raises the prospect of one router format that can adapt to many gigabit-capable WAN interfaces.
http://www.sckipio.com/cp1020sfp-evm-g-fast-cpe-reference-design/
-
Picking random customers to test, then not informing them and having no clue what devices they using is not the way to go.
Was that the first testing they did? Or the only testing?
they made business decisions to [...] also not extend fiber on the initial g.fast rollout.
Did they? Where? When?
They have also made a business decision when they did the FTTC rollout to do no network rearranging
Did they? What does EO upgrading count as, then? What is the AIO being used for? A seat for garden gnomes?
Of course finally the dual vendor issue which has bited them more than once.
The downside of multiple vendors is always this: one is more capable, and one suffers different faults from the other.
Yet the upside is multiple vendors must exist too - because it has been happening for decades and decades, across all forms of telco, not just BT.
Everyone is scathing of BDUK for choosing a single vendor. What's the lesson?
-
That's a good point Chrysalis if BTOR is going to run random tests on end-users lines for G.Fast then the results are going to be hit in miss if the modem is incompatible it is not going to be very good correlation basis to work from.
I think your correct these random tests are doing more harm than good, the tests should be done under a controlled environment with know hardware that works .
Sure what do I know even Roseway puts out a Beta of his DSLstats software and we test it and if there is an issue we can communicate with him with are findings and get a fix that is the normal way for hardware & software developers is it not
-
That is indeed normal for software, but 'beta' testing is also quite a late stage in the testing cycle ... roseway likely tests his software a lot before anyone else even sees it.
For telco-vendor testing, there are usually considerably more test phases than just alpha/beta.
In cases like the ECI rollout, the vendor-customer relationship is ECI-Openreach, not you, the end-user. ECI software developers will run tests before the software is ever included in a product. They will have integration testers running tests (in their labs) to show the whole hardware-software combination works, and interworks with as many 3rd party chipsets as it can, in as many combinations as it can. When a product is to be released to Openreach, a suite of acceptance tests will be run, testing feature combinations that are important to Openreach. When an upgrade is released, more acceptance tests will be performed on the new/changed/fixed features, while selected regression tests will be run on the unchanged features.
It is unlikely that Openreach will be content with ECI's internal testing. They will take the product into their own labs, and run their own acceptance and regression tests, with the hardware that is important to them. They will conduct their own integration tests against their own management and control systems too.
Once signed off against testing in the lab, the upgrade will be allowed onto the live network. It will still be tightly reined in, though - with an initial upgrade done in a friendly environment - perhaps still a DSLAM within Adastral park. More of the acceptance and regression tests will be run with real, live systems in control. In an upgrade like this, those tests will include a wide gamut of modems and DLM settings - especially as it is the way that modems and DSLAMs respond to new methods of interworking with the DLM system.
Once this has shown stability, it will be extended to a few more DSLAMs that are used by the public, and things left to run for a while, with close monitoring. This part is the closest that an end-user would feel to a 'beta' test, but as can be seen, it is a very late stage.
If the change is somewhat controversial, or all-encompasing, I can imagine this phase would slowly grow from the order of ten sites to the order of hundred - a bit like vectoring testing progressed. As the scope increases, the monitoring process swaps from watching how individual lines and modems respond, to monitoring the total statistics. What is seen in the total ES, FEC and CRC statistics? Is quality improving? Is anyone suffering outages?
Once happy with those results, comes the final step: a wide rollout. Monitoring will be statistical, ensuring that the widespread results mirror the final beta tests phase. A rollback at this stage will be a damaging, costly affair ... and all previous testing will be designed to avoid it being necessary.
Don't let @Chrysalis' blunt cynicism fool you into thinking his description is the way things happen.
Something devastating went wrong with the rollout, but it won't be because Openreach only bothered testing with a few random end-users.
Written from the persectve of a software engineer/architect, whose products sit in telco's operational networks, and whose code goes through testing cycles as described, often. It is an unpleasant experience to be hauled in front of a telco when some aspect of a rollout is going wrong; I've had that happen over one or two serious operational problems, but nothing bad enough that a network-wide rollback was necessary.
-
That's the never-ending problem with these kind of forums, W3 .......... people who believe they know what's going on and corrupting the minds of those who are prepared to listen.
Fact will always win through, but meanwhile ......... have you heard ?? ......... tests have been carried out that show wet-string can carry 1Gig speeds over 10km distances. You heard it here first. :)
-
Wombat if you are part of BT or contracted with them and you know different, dont hide it and actually say what you suggesting happens instead of been sarcastic.
I am completely baffled at your sarcastic surprise at the initial rolling out of g.fast having no nodes given that you yourself have been in multiple conversations about this and we have a quote from a BT executive saying they wont be doing the rollout to remote nodes on the first part of the rollout, he didnt even say it will happen later, but there is a conensus that it is logical it will be done after all the low hanging fruit is done.
Regarding testing yes, there will have been initial smaller trials, pilots and what not and staff only testing would have been testing when they knew the end user devices, but at the same time that staff testing would probably have just been openreach issued devices, possibly also BT retail devices and thats it. The CP based trials, where they inform CPs certian postcodes are been put on a product trial is more or less how I said it. Or are you going to tell me that CPs do contact every customer on a trial and ask them to inform them of what device they are using?
Regarding multiple vendors, it might be common practice to have standby supplier, but thats not the same as actually using 2 suppliers at the same time.
Regarding lab trials, they are not really relevant, I am talking about field trials done on live infrastructure that is subject to decay, damaged joints, crosstalk etc.
So looking forward to your detailed reply explaining exactly how its done. Specifically how both the hauwei and the ECI rollouts got cocked up. Since you think openreach's testing is not to blame, I am very interested in what you think was to blame.
To clarify, I have read your previous post, not once did I suggest that was the first part of any testing, obviously there will be earlier steps in the process, however its that part of testing on the public network that is flawed. Just monitoring stats without been in dialog with the end users and knowing what devices they use is flawed.
-
Picking random customers to test, then not informing them and having no clue what devices they using is not the way to go.
Further to Wombat's reply, one of the purposes of the MCT process is that the modems correctly identify themselves to Openreach's equipment - so they should know what the majority of end users are using - even though we are not their direct customers
-
It is interesting to see Sckipio proposing a different model for this - where the end user's router no longer connects to a separate 3rd party standalone modem. Instead, they propose that the modem is in the form of a pluggable SFP - rather like pluggable optics for enterprise and telco switches and routers.
Yes, I have also seen suggestions of having a combined unit but with a modular caddy for the modem to make it easier to upgrade.
Of course, in the UK the big ISPs are likely to want no Openreach branding either..
-
thankfully I have very logical way of thinking most of the time and get as much info on the subject before attempting to air my thoughts as I'm not as clued up as you guys in the internal workings of the Openreach tech department .
We get all the news flashes about new OR technology coming are way and then find it's been binned or never got to the full stage rollout or when it does finally go live it's got bugs after all the testing and then remove it to do more tests.
I am not an Openreach basher in fact have admiration for them just whish they would stick to a project like vectoring and see it though to full deployment then go onto the next project like VDSL SNRm 3dB target margin roll it out fully then start the G.FAST project
Just to me they seem to have an uncertain path or direction they want to take which leaves me kind of wary with any new OR tech projects I see these days, I'll believe it when it goes live on this line ;)
-
That's the thing, NS ......... and this is made with the greatest of respect (as I know Ronski gets upset about it too, but it's jack-sh1t too do with the average man on the street what Openreach decide to implement, trial, bring to market, etc .... !!
It's maybe because they are too transparent that feelings run amok. As far as I'm concerned, the technologies they are working on should be known to them, the ISP's and Ofcom .......... if a trial is warranted once a decision is made, then so be it. If the decision is then rolled-back, then so be it.
Whatever the feeling, please do not go down the avenue of making blind statements based on nothing other than 'What someone's brother told my neighbours dog' type of cr5p (not that you do, NS). It should be obvious by now on kitz which members make factual comments (or constructive criticisms based on experience), and others who would rip a cheque for £1M if Openreach's CEO were to present them with it.
Believe me when I say that BTOR are 100% about giving the EU what they want but IT HAS to be done with good business acumen. Some of the tosh I read on forums are from folk who think we're running a corner-shop with a dozen customers who all live in a 2 up- 2 down, with a small front garden and have 1.8 children. The demograph, geography and sheer size and scale of running such a large project, is way beyond the vast majority of people.
Just saying. ;)
-
(Not looking in any particular direction or at any one person's posts in particular . . . )
I would like to remind all contributors that this thread's subject is "I seem to have Vectoring active on an Huawei". :)
-
Ha ha ........... point taken ;)
To bring the topic back on point, I was actually working on a Huwaei vectored Cab today, no drama's or anything wonderful to report ...... just needed a 'Lift & shift' to repair the fault.
But ...... they are out there. :)
-
But ...... they are out there. :)
I presume it was a Huawei MA5603T equipped cabinet? :-\
(To date, I have not seen any information -- or evidence -- of the MA5616 equipped cabinets being fitted with a subsidiary back-plane and card-cage, thus allowing a vectoring engine card to be installed.)
-
Alas, I didn't take any notice B*Cat ................ too busy sweating buckets in the heat, and trying to get the EU back on-line.
-
Ah, so then I prescribe a bottle of some cool, soothing, throat embrocation as the day ends. ;)
-
Thank you, Doctor ..................... advice I prescribed myself at approximately 1800 tonight. ;) ;D
-
Black Sheep would not need to access the FTTC cabinet or even to peak in for interest while doing a lift and shift his concentration will be inside the PCP cabinet :hmm: :phew:
-
Further to Wombat's reply, one of the purposes of the MCT process is that the modems correctly identify themselves to Openreach's equipment - so they should know what the majority of end users are using - even though we are not their direct customers
Thanks for this info, I am interested in this because with the ECI g.inp issues it seemed openreach were unable to only filter out bad modems because only the chipset is identified to the dslam not the router manufacturer/model.
As a side note in this hot weather, I guess not too pleasant working up poles etc.
-
Thanks for this info, I am interested in this because with the ECI g.inp issues it seemed openreach were unable to only filter out bad modems because only the chipset is identified to the dslam not the router manufacturer/model.
I can't recall where I first saw it but if you look at A.4.2.2.13 on Page 65 of SIN 498 (http://www.sinet.bt.com/sinet/SINs/pdf/498v7p1.pdf) it tells you what vendor information the modems need to supply to DSLAMs to pass MCT
And as we have covered elsewhere, it's the MCT hardware/firmware that Openreach do their network testing against
-
To gt94sss2 I think I was on the VDSl2 3db profile test a month or so ago it went well for 4 days until I manually resynced the modem would that show up as a Pass or fail on the MCT ?
-
I should stress for the avoidance of any doubt that I don't work for Openreach but the MCT is a standardized test.
If you look at p45 of SIN498, it shows they test modems against their target SNRM of 6dB but have a minimum/maximum of 0/31dB.
Table 6 on page 55 also mentions SRA and gives an lower/upper threshold margin of 3/9 dB for that which makes me wonder if they are using SRA at all for their 3dB trial.
Are you sure you were on the trial? I wouldn't have thought a single resync would cause its removal..
-
@chrysalis
Taking due note of @b*cat's post, I'll leave my initial public response here in words of zero syllables.
But don't worry ... a response will be winging its way later.
-
Are you sure you were on the trial? I wouldn't have thought a single resync would cause its removal..
At the time, I think the belief was that the trial was - for any single line - a one-off affair. The trial would stop at the next resync, no matter the cause of that resync.
That would limit the negative impact of the trial, to any one end-user, to 2 resyncs. The first to start the trial, and the second that would end it - whether it is triggered by instability after 30 minutes, or by a power cut weeks later.
-
Just confirmed I've got it here too. BDUK Huawei cabinet. Increased my sync from around 50Mbps to over 60!
No affect on the upstream though unfortunately :(
-
Just confirmed I've got it here too. BDUK Huawei cabinet. Increased my sync from around 50Mbps to over 60!
No affect on the upstream though unfortunately :(
Nice result there GigabitEthernet. I am quite jealous :'(
[Moderator edited.]
-
Hi
Have you got some stats please :) Its a bit hard to see any speed increase on MDWS from when you last used it.
May
Max attain = 63275
Sync = 60146
SNRM = 7.8 dB
(G.)INP = 48
Today
Max attain = 60444
Sync = 58976
SNRM = 7.4 dB
(G.)INP = 49
-
I haven't got any stats apart from those from today. I've not been monitoring the router at all in the last few months.
It was around the April timeframe I think when suddenly the speed increased. I assumed it was due to Summer coming. I only realised today that's what has caused it.
-
Am I right in saying that if I have a resync, vectoring will be removed from my line?
-
Am I right in saying that if I have a resync, vectoring will be removed from my line?
Highly unlikely.
Vectoring is a thing that only works if everyone on the cabinet is included, so it is only ever likely to be removed if it goes from everyone at the same time ... though there will be a resync at that time.
The STIN for "LR-VDSL" being trialled by BT shows they are planning to use vectoring in those trials (so perhaps your cabinet is one of the cabs in the "secret" list), and that all lines (including the lines that aren't eligible for the long-range variant) will be vectored. The only exception is for modems that aren't compatible with vectoring, which will be removed by "rogue line control".
No affect on the upstream though unfortunately :(
That STIN indicates they aren't using vectoring on the upstream, perhaps adding to evidence that your cab was enabled for part of this trial.
Edit: Added response to upstream behaviour
-
No point in vectoring some lines but not others so wouldn't surprise if everyone on the LR-VDSL cabinets is vectored.
Good to see this crystalising the earlier comments about deploying vectoring where it would be of most benefit in getting lines into the >24Mb range.
-
No point in vectoring some lines but not others so wouldn't surprise if everyone on the LR-VDSL cabinets is vectored.
not just wouldn't be surprised, it's an absolute must have.
2.5 Vectoring Vectoring (i.e. “real time” crosstalk cancellation [3]) is required to ensure that the LR-VDSL signals do not adversely impact the existing VDSL2 signals. Vectoring shall be applied in the downstream direction starting from 138kHz . No vectoring is applied in the upstream direction. Modems which cannot support vectoring will be manually removed from the vectoring group.
anyone on those cabinets using an incompatible modem will definitely get a chap at the door from OpenReach. don't know if they'll enforce MCT approved modems only though.
-
I thought there was some document somewhere which showed vectoring working surprisingly well with vectoring only enabled on some lines but not others in the bundle. What does "removed from the vectoring group" actually mean? Only that they will disable vectoring on the lines with modems that don't support support or have enabled vectoring?
-
What does "removed from the vectoring group" actually mean? Only that they will disable vectoring on the lines with modems that don't support support or have enabled vectoring?
I think it likely means it will disable vectoring for that line. Then, depending on the level of non-support, the rest of the group has to figure out how to deal with the rogue line. Earlier research suggests it has less impact to the vectored lines if you deliberately slow it down (eg banding to half-speed) ... which could be a step taken by "rogue line control". More recent research suggested better ways to cope, but I've forgotten the details.
-
Just disable their lines then when they ring up and get an engineer out charge them for not using the correct gear >:D
-
:lol:
-
I suppose it might also depend on if the non-vectoring modem is vectoring friendly, in which case the crosstalk it causes to other lines can be cancelled, but it won't have its own speed improved by the vectoring. However, for something like the TP-Link TD-W9980, I think it doesn't support vectoring and it's not vectoring friendly either.
-
I would imagine "Modems which cannot support vectoring will be manually removed from the vectoring group" means the EU will be made to use a compatible modem. certainly during any trial they would enforce this, otherwise it would impact the trial and affect the results.
what exactly is non-vectoring, vectoring friendly (edit: genuinely asking, not trying to come across as a twat). wouldn't any modem that doesn't support vectoring continue to cause crosstalk? I thought vectoring only worked if all modems supported it.
I thought there was some document somewhere which showed vectoring working surprisingly well with vectoring only enabled on some lines but not others in the bundle.
Was it this by any chance? Managing Unvectored Lines In A Vectored Group - TMCnet (http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2013/8629-alcatel-lucent-managing-unvectored-lines-a-vectored-group.pdf)
That suggests what WWWombat said, that it's only effective if the non-vectored lines are capped. It uses the example of dlm setting maxSNRM and maxPSD to mitigate the effects of the non-vectored lines.
Seems like more work configuring dlm to work around the very few who have purchased their own incompatible modem. Much easier to enforce MCT approved kit, or at least working vectoring.
-
Depends if they decide to use something like Zero-Touch technology.
I don't know if there is an equivalent for the Huawei based cabs.. but if there was, then this could in effect should put non vectored modems into a vector friendly state.
Obviously the non-vectored modems wont see any benefit from vectoring, but it means that one non-vectored modem wont ruin it for all.
See previous discussion on the subject in this thread (http://forum.kitz.co.uk/index.php/topic,17258.msg316707.html#msg316707) for more info.
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.
Also vid @ 1:10
[youtube]https://www.youtube.com/watch?v=LouQqdNtMtI[/youtube]
>> manually removed from the vectoring group
Earlier documentation may have mentioned being given a 'vectoring profile' I cant recall now why I would have said profile and am not able to dig any deeper atm.
Other alternatives are spectrum management, PCB or as already mentioned capping the speeds of the non vector friendly lines. iirc though to be of real benefit some fairly harsh capping may be involved.
Belgacom has their own MCT similar to Openreach's.... and a clause of shutting down lines with non compliant modems. However iirc they got quite strict and are rate limiting non vector friendly modem lines to adsl1 speeds.
-
what exactly is non-vectoring, vectoring friendly
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.
The amusing thing is, that this means that BT could have all lines running in vectoring full friendly mode, and then only enable vectoring on certain lines that the DLM or something decides need it. Then the few lines that get G.993.5 vectoring would still get as much of a speed boost from the crosstalk cancellation as they would if all the lines were doing G.993.5 vectoring. Then we could have the usual watching DSL stats for weeks, hoping the DLM decides to enable something. :P
-
Thanks kitz/ejs. I just spent the best part of an hour reading up on this. Do we know what vectoring friendly mode OR use? I would guess Annex X as it's the easiest to implement, and only works on the downstream.
Then we could have the usual watching DSL stats for weeks, hoping the DLM decides to enable something. :P
sounds like g.inp all over again!
-
It was all just speculative, hopefully it won't be done like that, all modems should fully support vectoring anyway. But it appears the technology could allow it to be done that way.
-
I was under the impression that vectoring on FTTC was shelved by OR and only the current test sites still had it running and is not to implemented any further into their network until G.FAST has started in 2017 :-\
-
I thought they were using it on selected BDUK cabinets to meet targets.
-
Do we know what vectoring friendly mode OR use?
Isn't it more a matter of what compatibility the modem firmware has?
From OR's perspective, the DSLAM ought to be able to cope with CPE of any flavour.
-
I was under the impression that vectoring on FTTC was shelved by OR
BT shelved the idea of a general rollout of vectoring nationwide, and went for G.Fast instead. But...
I thought they were using it on selected BDUK cabinets to meet targets.
Yes, @IgnitionNet reported that BT intended to make use of vectoring in specific cabs, where it will increase the number of properties that can achieve the "superfast" threshold. That obviously would help reach their BDUK commitments. My previous calculations were that vectoring would increase range for the 25Mbps threshold from 1200m to 1400-1500m (of 0.5mm copper).
However, the latest trials by BT *also* make use of vectoring.
As described in STIN 522 (http://www.btplc.com/sinet/sins/pdf/STIN522v1p0.pdf) (the link will likely stop working when BT publish a new version), the trial of "Long Range VDSL" makes use of vectoring for all lines on a cabinet. Only certain cabinets are taking part in the trial, and even a full live deployment will likely be restricted to a small percentage of cabinets (because of LLU compatibility issues).
It could well be that, in the long run, the use of vectoring that @Ignition reported is precisely the same as we are now seeing in LR-VDSL trials.
-
the trial of "Long Range VDSL" makes use of vectoring for all lines on a cabinet. Only certain cabinets are taking part in the trial, and even a full live deployment will likely be restricted to a small percentage of cabinets (because of LLU compatibility issues).
Well I'm your man for this cabinet trial 1000 meters and no LLU :fingers:
edit not under BDUK bugger that then :(
-
Can they meet BDUK targets by upgrading cabinets not built specifically for BDUK?
I've given up completely on me ever getting vectoring at this point, I just hope I don't get the 'ECI' of G.Fast.
I can't see them rolling out much LRVDSL until they have to meet a 10mbps USO, I don't know how they're going to do this with the ECI cabs though.
-
I expect the LRVDSL areas will be hauwei only like they done with BDUK.
-
I expect the LRVDSL areas will be hauwei only like they done with BDUK.
I thought the BT rollout started Huawei-heavy, then became ECI-heavy in the middle, but the later portions (particularly BDUK-funded) have been all Huawei. That should allow LR-VDSL to be a workable solution in BDUK areas
Can they meet BDUK targets by upgrading cabinets not built specifically for BDUK?
Excellent question!
I think the answer is ... it depends.
BDUK phase 1 projects seem to have been uniformly bad at giving themselves flexibility in the definition of the intervention area. Once defined, it could not be changed. Phase 2 seems better, with areas able to change status.
On top of that, some projects look to have defined their areas in terms of whole postcode, and possibly whole cabinet areas. Certainly my county (North Yorkshire) had a definition that included a number of properties as both "commercial" and "sub-25Mbps"; such definitions, with an inflexible contract/project means the answer is no: upgrading commercial cabinets would not help meet the target.
However, projects seem to be adding both flexibility in the definition of the intervention area - moving parts in/out as necessary and flexibility in the rules. Some projects are taking areas down to individual premises. In these cases, premises outside the range of superfast speed on a commercial cabinet would be valid targets for BDUK, so an improvement could well include them.
On the other hand, BDUK demands a "step change" improvement to qualify, as well as meeting the superfast threshold ... so an upgrade from 23Mbps to 28Mbps might not qualify.
I can't see them rolling out much LRVDSL until they have to meet a 10mbps USO, I don't know how they're going to do this with the ECI cabs though.
Conversely, BT are saying their USO plans could be self-funded, while BDUK upgrades are subsidised. BT might be incentivised to make these changes as part of BDUK, rather than waiting for the USO. Less outlay that way...
-
I'm either banded, or something strange is going on with Vectoring and SNRM.
On the DS, whenever I sync my SNRM seems to be around 7dB. It never, ever is at 6dB anymore.
This 1dB of room is good I'm sure but it seems strange. Unless I'm banded but really hard to say?
-
Hmm, just put on the Zyxel VMG8324 and Vectoring isn't working with it :(
Still, looks I'm not banded.
Edit: put the latest firmware on it and Vectoring is now working :)
-
Vectoring is a very curious technology.
Every few weeks, my line seems to have its SNRM increase and so the maximum speed increases. I've gone from actual sync speeds of 58Mbps, to 62Mbps, to 64Mbps and now my maximum speed is up to almost 68Mbps.
What is happening here?
-
Totally guessing, but I suppose it's plausible that people using modems that won't support vectoring are replacing their equipment, or any devices that somehow aren't doing vectoring very well are being fixed with firmware updates.
-
I wonder if it will ever stop. Imagine 70Mbps on a 750m line!
-
Hmm, just put on the Zyxel VMG8324 and Vectoring isn't working with it :(
Still, looks I'm not banded.
Edit: put the latest firmware on it and Vectoring is now working :)
Where do you see on a Zyxel that Vectoring is active?
-
hope this helps...
-
Ah cool, now that youve shown it I remember seeing G.Vector Enable on one of our customer routers
-
Can they meet BDUK targets by upgrading cabinets not built specifically for BDUK?
Yes. I don't think they can claim gap funding for obvious reasons, although I could well be wrong, but BDUK targets coverage at x Mbps across the local authority as a whole, not just the intervention areas.
-
I've just noticed after installing DSL stats on a RPI that g.inp and vectoring is enabled on my line. I think this was done about 3 months a go and the line speed went from 34mbps to 43 with a max attainable rate of 50mbps.
The cab I'm on is in a small village and I'm about 900mtrs from the cab (following paths and poles).
Here's the stats:
Stats recorded 24 Jan 2017 20:31:05
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 4 days 19 hours 59 min 38 sec
Resyncs: 0 (since 23 Jan 2017 19:08:59)
DownstreamUpstream
Line attenuation (dB): 23.80.0
Signal attenuation (dB):Not monitored
Connection speed (kbps):439996435
SNR margin (dB): 9.36.4
Power (dBm): 12.82.3
Interleave depth: 161
INP: 45.000
G.INP: EnabledNot enabled
Vectoring status: 1 (VECT_FULL)
RSCorr/RS (%): 0.11570.0212
RSUnCorr/RS (%): 0.00000.0000
ES/hour: 0.050.63
I guess this trial is going national?
-
I guess this trial is going national?
Only on some BDUK huawei cabinets that was on the first trial
-
I believe vectoring is used on certain cabinets to help meet targets, real shame they don't enable it on all compatible cabinets.