Kitz Forum
Announcements => News Articles => Topic started by: ejs on September 22, 2017, 08:55:47 PM
-
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga03117.do
This briefing is to inform all CPs that we'll be carrying out a Proof of Concept from 20 October 2017 to apply XdB to a subset of GEA-FTTC ECI lines.
So we've heard nothing further about retransmission on ECI FTTC, but now Openreach have announced when an XdB SNRM test will start.
----
Admin edit - Topic Merge. Acknowledges ejs as original poster re NGA031/17
-
Nice.. wouldn't this need g.inp to work properly ?
-
I think it's a case of it would work better with G.INP, after all we've all seen lines which have re-synced quickly after a power cut and hung on well to a lower SNRM without G.INP
-
True but lines with high es will be a real mess if it's not carefully controlled 😃 (like mine)
-
It will be interesting to see how kitz' and Chrysalis' circuits behave with a lower target SNRM.
-
Haha, this is amusing, I wonder how many lines would possibly support this without G.INP. Not many I imagine, mine in its current state certainly wouldn't.
-
Proof of concept is an interesting phrase to use, to me that implies perhaps a trial or partial roll out rather than full roll out for all? Why didnt they use the word trial?
I wonder how many lines would possibly support this without G.INP. Not many I imagine, mine in its current state certainly wouldn't.
It will be interesting to see how kitz' and Chrysalis' circuits behave with a lower target SNRM.
Theoretically mine should. Its run perfectly fine in the past for for several weeks at 3dB after resyncing before my crosstalker(s) without it causing an increase in the error rate. What currently upsets the apple cart on my line is the morning blip of errors that sometimes gets stuck until I perform a manual resync. If I don't catch it quick enough DLM spots it.
3dB should take my line back up to near 80Mbps sync. If it wasn't for that daily blip I'd be fine. I ran at 3dB for many years on BE* without issue.
True but lines with high es will be a real mess if it's not carefully controlled 😃 (like mine)
If DLM was working how it should then, it should back off back to 4db > 5dB > 6dB. However they did a botch job of capping after ASSIA, which doesnt appear to like backing down again even if the line is stable.
The DLM process needs a total review on the steps it takes, the original NGA process seemed to work OKish. The botch job on NGA after ASSIA and a a further botch for G.INP has complicated things. As Ive said before, unfortunately I dont see them doing any review whilst the 2 [cab type] systems have different processes.
The main difference with the NGA system process is that it uses capping to a much greater extent than the 20/21CN systems. It is clear from the court case documentation that ASSIA's main complaint was with the NGA DLM and reading between the lines there was suggestion that it may be with the ILQ, which in turn infers how it returns back to normal.
If they ever get G.INP on ECI and they do start using 3dB, then IMHO it would be best if they abandoned capping and returned to the tried and trusted target SNRM which works fine on 21CN. 3dB also works fine for many lines on 21CN, the mess with NGA is that lines get stuck with a cap far too easily.
-
I think "proof of concept" comes before a trial or deployment.
-
It will be interesting to see how kitz' and Chrysalis' circuits behave with a lower target SNRM.
mine wont do anything given I am already at the cap set for my line (thankfully).
If this is rolled out without g.inp I can see it been a bit messy.
-
https://www.ispreview.co.uk/index.php/2017/09/openreach-test-xdb-speed-boost-eci-fttc-fibre-broadband-lines.html (https://www.ispreview.co.uk/index.php/2017/09/openreach-test-xdb-speed-boost-eci-fttc-fibre-broadband-lines.html)
Some users of Openreach’s (BT) ‘up to’ 80Mbps capable Fibre-to-the-Cabinet (FTTC / VDSL2) broadband lines, specifically those stuck on troublesome ECI based street cabinets, may soon benefit from a speed boost when OR attempt to adopt a default target downstream noise margin of 3dB.
The SNR (Signal to Noise Ratio) of a standard VDSL2 or ADSL based broadband line (most consumers in the UK have one of these two) reflects the balance (measured in decibels) between the useful information coming down a line (good signal) and unwanted interference (bad signal / noise).
The default target downstream (download speed) noise margin on Openreach’s VDSL2 (FTTC) lines was previously set at 6dB, but by dropping this to 3dB you could deliver a free speed boost to stable copper lines (especially very short ones). Speed increases of up to 9Mbps have been spotted on some shorter lines, although not all lines will benefit.
-
Cue, fault levels rise. ::)
-
Nice.. wouldn't this need g.inp to work properly ?
The desirable outcome for BT is that they get both G.INP and XdB working. This might be a way to overlap the two trials, and fastrack that outcome.
I could envisage an XdB PoC going on in parallel with a G.INP trial, with lines qualifying for XdB only after proving to behave on G.INP.
-
Let's hope openreach get it right this time.... ???
-
Let's hope openreach get it right this time.... ???
In all honesty I think you really mean ECI . . .
-
https://www.ispreview.co.uk/index.php/2017/09/openreach-test-xdb-speed-boost-eci-fttc-fibre-broadband-lines.html (https://www.ispreview.co.uk/index.php/2017/09/openreach-test-xdb-speed-boost-eci-fttc-fibre-broadband-lines.html)
Topics merged to give ejs credit as original author and person who disclosed this info.
I'm aware Mark follows (no prob with that), but no further info in that which hasnt already been covered on here.
Thanks Bowden, as you may not have been aware this was previously under discussion. :)
-
Cue, fault levels rise. ::)
Hopefully it shouldnt.
Which is why I raised the question about Openreach using the term 'proof of concept' - which ejs explained is pre-trial.
If that is the case then I doubt it will be anything that most ECI cab users see anytime soon .
I'm actually quite sad about that, as I feel my own line would have benefited.
TBH if it is problematic, then I do believe even the crippled NGA system should back off in a few days & before the average bod would notice - See discussion here (http://forum.kitz.co.uk/index.php/topic,20346.msg355077.html#msg355077)
-
In all honesty I think you really mean ECI . . .
Them as well ;D
-
Let's hope openreach get it right this time.... ???
TBH I dont forsee too much of a problem. It is only proof of concept. Shorter lines could benefit.
Its already in use on 21CN (which doesnt have G.INP) without any issue. If the line experiences issues and generates more errors, then in theory it should back off in a day or two. 3dB has been in use by other ISP DLM systems for >10yrs.
6dB is needed for ADSL1, but advancements in dsl algorithms since ADSL2(+) has lowered this to 3dB for stable lines - which means that if a line doesn't have more than a 1dB daily swing and drop below 2dB, then hopefully they should be fine. ***
The fly in the ointment with NGA DLM is its over zealous use of capping. :/ ... and the ECI inability to do vectoring and upstream g.inp.
---
ETA
Whilst I am unhappy about lack of g.inp (& vectoring) on the ECI's - and how things do keep getting delaying for retransmission... perhaps because this keeps getting delayed then why should it stop them pre-trialling something which could benefit some ECI users.
In an ideal world it would be nice if ECI users could get vectoring and g.inp, and as such those users are getting an inferior service, so why not at least see if the XdB could at least benefit some lines.
***
reg member Kondrado who is on adsl 2+ quite often pushes his line to below 2dB without any undue consequences.
Ive even tried it myself when on BE* a few times but cba to keep tweaking after every reboot, but I do know it ran ok several times at 2dB or less after a crosstalker came online. The caveat with doing this on NGA and pushing a line to its max, is that damn cap.
-
kitz how come u hate banding? u prefer interleaving? or is it just the stickyness you hate?
-
How it sticks.
Personally I dont like interleaving and if I had the option I would choose speed reduction, but each to their own and most people dont notice INP.
I sincerely dislike how the NGA system banding seems impossible to remove, so yes in the likes of your case I can fully understand anyone who self caps.
-
Thanks kitz, I think this has came about as openreach want one system to please everyone, they need to add some control that CPs (or their users) can overide.
I dont like a DLM that flaps a line, but others are ok with it if it means eeking every bit of performance out their line.
My gut feeling is in line with wombat, I suspect this is happening alongside a g.inp test.
-
Interesting comment on tbb forum. Eci g.inp supposedly being reintroduced from 25th september rolling out to 600k lines by Dec and whole estate by March 2018..
Fingers crossed...
-
Topics merged to give ejs credit as original author and person who disclosed this info.
I'm aware Mark follows (no prob with that), but no further info in that which hasnt already been covered on here.
Thanks Bowden, as you may not have been aware this was previously under discussion. :)
I don't mind. I didn't see the original information that ejs put out, so all credit to him.
As long as us on ECI cabinets start getting some good news then its all welcome! :)
-
Interesting comment on tbb forum.
Yes . . . but from whom? :-X
-
Yes . . . but from whom? :-X
AndyHCZ
Thread is here (http://forums.thinkbroadband.com/fibre/f/4566444-nga03117-xdb-proof-of-concept-on-gea-fttc-eci.html)
He often has decent OpenReach info. A number of things he's said about ECI G.INP in the past have been incorrect though, including that it's gong to work on the upstream.
His 2 posts conflict with each other, so I'd take what he says with a pinch of salt.
I don't see why OpenReach would put an update out to CP's to tell them the trial is delayed, for it to start 2 weeks later. The previous update had only said Autumn I believe, so I'm sceptical about it starting on 25th September.
-
AndyHCZ
Thread is here (http://forums.thinkbroadband.com/fibre/f/4566444-nga03117-xdb-proof-of-concept-on-gea-fttc-eci.html)
He often has decent OpenReach info. A number of things he's said about ECI G.INP in the past have been incorrect though, including that it's gong to work on the upstream.
His 2 posts conflict with each other, so I'd take what he says with a pinch of salt.
I don't see why OpenReach would put an update out to CP's to tell them the trial is delayed, for it to start 2 weeks later. The previous update had only said Autumn I believe, so I'm sceptical about it starting on 25th September.
A further comment from AndyHCZ
"I missed the updated briefing, hence the conflict.
The retransmission trial will start tomorrow to be loaded on to lines"
Could be an interesting day tomorrow..
Not sure why it's a trial. Last thing or said was that gi.np had been fixed....
"The ECI RETX fix has been delivered and extensively tested. It is being included in a full update to the network and this full release is under test"....
-
I'm a little behind the G.INP news. But is G.INP in action now on ECI cabinets?
I'm not sure how going down from 6dB to 3dB isn't going to cause problems, unless DLM is having its programming updated also to be more relaxed.
I know I've never lost sync through being too low dB. It's always been DLM sticking its boot in :oldman:
-
I'm a little behind the G.INP news. But is G.INP in action now on ECI cabinets?
I'm not sure how going down from 6dB to 3dB isn't going to cause problems, unless DLM is having its programming updated also to be more relaxed.
I know I've never lost sync through being too low dB. It's always been DLM sticking its boot in :oldman:
Not seen any enabled yet. Perhaps we might some this week...have to wait and see
-
It feels like people would be complaining if they don't get XdB, and will also be complaining if they do!
-
No complaints from me. As said above, its worked on other DLM systems for years without g.inp. :)
-
AndyHCZ
Thread is here (http://forums.thinkbroadband.com/fibre/f/4566444-nga03117-xdb-proof-of-concept-on-gea-fttc-eci.html)
Ahh.. one cab. Now I understand why they didnt say trial and ejs was correct when he said pre-trial.
-
The details from AndyHCZ still look to me like BT are trying to chase one trial with another, and the PoC is just step 1 in that process.
I have no skin in the ECI game, but I have my fingers crossed that this rollout goes OK. It certainly looks like BT want this done and sorted ASAP ... but that is also a sign that perhaps ECI (the company) has managed to regain some trust.
-
If a G.INP rollout does start tomorrow at a rate that should hit 600k lines by December, then it shouldn't be too long before we see lines on MDWS showing enabled.
I'd be very very surprised if we see anyone on the xdB PoC if it really is a single cabinet.
-
If a G.INP rollout does start tomorrow at a rate that should hit 600k lines by December, then it shouldn't be too long before we see lines on MDWS showing enabled.
I'd be very very surprised if we see anyone on the xdB PoC if it really is a single cabinet.
Not sure how reliable the cabinet detection is though on mdws so that will screw the results also. Quite a few people in the past have reported it is wrong requiring manual setting and it doesn't seem to update itself if you move cabinet/house.
-
it's perfect. It detects the use of tones that varies between the 2 vendors. It does need manually changed but it's not often people move or change cabinet.
It's right at the moment. The ECI user with g.inp does indeed have it.
edit: might not detect the tones actually but I know it is accurate and only needs manually changing if you switch DSLAM
-
Upload user "ayeaye" never had eci g.inp disabled from the last time. I wonder if his cab firmware type has changed at all recently.
-
it's perfect. It detects the use of tones that varies between the 2 vendors. It does need manually changed but it's not often people move or change cabinet.
It's right at the moment. The ECI user with g.inp does indeed have it.
edit: might not detect the tones actually but I know it is accurate and only needs manually changing if you switch DSLAM
Thank you for the kind words :)
Actually it's perfectly capable of updating when it detects a DSLAM change but this tends to occasionally flap about on a user with a poor line so it's currently turned off.
For anyone interested, MDWS does use the tones from the Bits/Tone data that is uploaded to work out what the cab is. Fortunately as noted there are differences in the bandplans between the two vendors that allow a reliable detection in the majority of cases. So certain tones are only used by a particular vendor. For instance Tone 32 is only used by Huawei and Tone 6 by ECI. They are a couple of the obvious ones and just because they are not used in a particular case doesn't offer a definitive answer - they could just be missing. So you have to look at all sorts of tone combinations. There are 12 sets I use at the moment and this gives a 99.5% accurate detection of the cab type.
For an ECI DSLAM:-
US tones are 6 to 31 882 to 1193 & 1984 to 2770
DS tones are 33 to 857 1218 to 1959 & 2795 to 4083
For a Huawei DSLAM:-
US tones are 7 to 32 871 to 1205 & 1972 to 2782
DS tones are 33 to 859 1216 to 1961 & 2793 to 3970
There is just one user that eludes me and he is currently marked as Huawei - but the detection says he is ECI. You can often tell just by looking at the Bits/Tone graph - the Huawei's tend to have very small visual gaps between the start and end of the U/S and D/S blocks. ECIs tend to have bigger gaps. The one in question also has bigger gaps making it likely an ECI. BUT it has G.INP enabled which at the moment is probably unlikely for an ECI - but maybe the owner isn't aware of his true cab type! And so on. Until I can sort this I have the change detect turned off.
I've asked the owner for confirmation of the cab type from the DSLStats data (this isn't uploaded currently but might look at doing so later).
Also if the cab is wrong on a decent line, the graph will have BLACK (should only be red and green) bars in places between U/S and D/S where the Tone number isn't in the band plan for the cab type. But depending on the line there may not be any black bars even if the wrong cab type was detected.
The mails that go out notifying G.INP changes can be copied to someone if and when they start on ECI if they want to be the first to know - say j0hn / skyeci? I had no trouble at all when it was enabled on my ECI - got an extra 9 meg though!
-
Thank you for the kind words :)
You're very welcome. I think the whole concept/implementation is excellent!
The mails that go out notifying G.INP changes can be copied to someone if and when they start on ECI if they want to be the first to know - say j0hn / skyeci?
That would be fantastic ;D
-
so aside from the end of D3, it looks like hawuei cabs are able to handle smaller gaps between the DS and US bands so have effectively more useable tones for bandwidth?
I remember the same on adsl, with BTw. They have two different vendors and the one that used texas instruments which I think was broadcom based was also able to use more of the tones in close proximity to the US which resulted in a more stable connection on my line.
-
so aside from the end of D3, it looks like hawuei cabs are able to handle smaller gaps between the DS and US bands so have effectively more useable tones for bandwidth?
That's certainly how I'm reading those ranges. The Huawei has more tones available for almost every band with only D3 having many more tones at the far end on ECI.
With only short lines being able to use these frequencies and the U.K product being capped at 80Mb, they either aren't needed or can't be made use of.
-
I havent checked the figures, but iirc Tony got those figures from the DMT page (http://www.kitz.co.uk/adsl/adsl_technology.htm) as I have a vague recollection of a convo a few years back about me having no probs with him using info which can help MDWS users as at the end of the day, we are both trying to help EU's where we can.
Anyways, if so, its definitely not about them being able to 'handle', it's more about what they decide to set. Different DSLAM manufacturers have always set very slightly different bandplans. As long as they are centered around the same stop-band then there is no issue. They know what the stop-gap is as defined in the TR [whatever # it is] and its up to them to decide how many tones to leave on each side in case of bleed - its more about line stability.
The most over zealous manufacturer I can think of is the manufacturer of BE MSANs (mental block atm for name), whose MSANs where also in use in other European countries and who decided to block certain HAM tones - even though they werent an issue in the UK.
So what that ECI decided to block an extra tone each side of the stop gap - its about 8 tones in total. Even if the line was fully bitloaded on those tones (which they arent because of other things such as PCB and PSD) then youre talking at max 448 kbps.
In reality even if you have a short line its more like 228kbps, (longer lines will be even less) and I'm ignoring the end tones they could make use of which could give a bit back.
Srsly even though I'm on an ECI, I can think of much worse things to complain about rather than something that averages out somewhere in the region of about 150kbps - or less for short lines. ::)
-
Just a note that the user I detected was on an ECI cab has confirmed he is - he knows since he says 'I put the tie cables in' :)
He is user DSL34 on MDWS...
-
I havent checked the figures, but iirc Tony got those figures from the DMT page (http://www.kitz.co.uk/adsl/adsl_technology.htm) as I have a vague recollection of a convo a few years back about me having no probs with him using info which can help MDWS users as at the end of the day, we are both trying to help EU's where we can.
Quite correct, thanks.
-
user DSL34
Something odd about that line according to stats. Capped at 20/10. Attainable 54/18
-
I don't recall seeing user Semmy who is now showing as g.inp enabled too...
-
I don't recall seeing user Semmy who is now showing as g.inp enabled too...
They definitely weren't showing earlier.
Interleaved depth of 1, INP 48.
Definitely G.INP on an ECI cabinet then.
They've been uploading for the past 5 days so no idea why they didn't show up earlier. G.INP has been on for the full 5 days showing in MDWS so not a new activation.
-
Sorry - looking at the log he was fixed early yesterday after some mods to the detection system so correct, he's an existing user for some time.
Correction: he was detected as ECI as I said but it wasn't implemented until 23:00....
The automatic emails for the two previously mentioned are now set up but nothing yet.
-
I just read the ispr article and they seem to have made a glaring error.
There is a claim that this would not help very long lines and that the shortest lines would be the most to benefit.
However my view is the opposite, most people are on 40/10 or 55/10, Most lines under 600m should be hitting the 40mbit speed cap. As such it doesnt matter if the target margin is 3db or 6db, the 40mbit cap still applies. Very short lines (under 200m) will also likely be hitting the 80mbit speed cap on the 80/20 product as well.
However very long lines are unlikely to be hitting a speed cap unless they banded, meaning those lines will soak up a lower snrm fully.
-
most people are on 40/10 or 55/10
Yes indeed.
I did some work to estimate the speeds of different market segments earlier this year, and as part of that, tried to break down the FTTC market.
At the time, it was roughly:
- One third on 40 Mbps products (I didn't differentiate between 40/10 and 40/2)
- One half on 55/10 Mbps products
- One sixth on 80/20 products
-
Speed cap aside (good point Chrys btw), I would think those that will benefit most are those who perhaps started off at 80/20 but lost speed due to x-talk.
It may also give a bit more to those who were say previously syncing at say 30Mbps on the 40Mbps products.
Re the long lines, I doubt they would 'soak it up' as such. DLM should only attempt the lower target after a period of stability (ILQ green). The longer lines tend to get more errors therefore it would have to be stable green before attempting 5dB. It would also require ILQ green again before going down to 4dB, even if its amber that should cause a no action. If ILQ red, then it should back off.
Time frames for XdB may be different to the INP status - I don't know as I dont have those details, but if it does use an ILQ status similar to INP, then time frames definitely do get extended to stop lines flapping.
For INP I have observations written down somewhere, but from memory its 1 day, 10 days, 14 days and so on. So first time it tries it, it could go down quite rapidly, but next time it will be more cautious.
When they first brought xdB out on the Huawei's I saw mention from a couple of ISP {TT} reps that it may cause problems and increase in fault rates, but that hasn't happened. The ILQ system seems to take care and back off as soon as MTBE goes red. Whilst I appreciate that BS said he saw some errors when it was trying it on his line and he reset DLM himself as mentioned in that thread I suspect DLM would have noticed anyhow and backed off the next day. BS has an advantage that he could reset line himself which takes immediate effect rather than wait until next day to take action.
3dB works perfectly fine on adsl2+ lines without G.INP. It only gives it to lines that are ILQ green. There are plenty that just dont get it at all because their lines are either ILQ amber or ILQ red. Although XdB has been available for quite a while on GEA-FTTC-Huawei, there are still plenty of lines still running at 6dB because they dont meet the ILQ requirements.