Print

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

[gt94sss2]

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.

[Chrysalis]

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).

[WWWombat]

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/

[WWWombat]

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?

[NewtronStar]

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

[WWWombat]

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.

[Black Sheep]

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. 

[Chrysalis]

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.

[gt94sss2]

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

[gt94sss2]

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..

[NewtronStar]

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 

[Black Sheep]

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.     

[burakkucat]

(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". 

[Black Sheep]

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. 

[burakkucat]

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.)