Kitz Forum
Announcements => News Articles => Topic started by: WWWombat on March 29, 2016, 12:15:52 AM
-
http://forums.thinkbroadband.com/fibre/t/4473275-re-eci-fttc-cabinets-still-dont-support-ginp.html
Rumour - FTTC trial - making SNRM variable?
-
Ohhh nice find. :)
It sounds like 3dB Target SNRm to me too.
-
PS Off topic but something else I noticed in that same thread, re the HH5A not using G.INP.
According to Openreach's Chief Engineer (http://www.kitz.co.uk/adsl/ginp-retransmission.htm) both the ECI modem and HH5A performs retransmission in the downstream direction only.
I specifically asked about the ECI modems & HH5A's. Ian surely would not have been prepared to put his name against something if it wasn't correct. - See Question 3 here (http://www.kitz.co.uk/adsl/ginp-retransmission.htm)
The whole reason I got something in print is because certain people were sceptical when I said the G.inp Mk1 issues were specific to the VRX-268 chipset in that it only supported downstream g.inp. We had also been saying since Jan 2015 (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1)that if the modem couldnt at least partially support g.inp, then it wouldnt be able to connect to the Internet. BT rolled out f/w during 2014 to make the ECI modem g.inp compatible in the downstream direction. Unfortunately that fact was often misinterpreted too. :(
Ive no idea how we, as EU's can say if it is or not, because the HH5A doesn't give sufficient information from its stats.
1) You cant use sync speeds as a base - For example on my own line the VRX-268 chipset gives me 3Mbps less than the BCM6368 which in turn gives me 3.5Mbps less than one using a BCM63168. It's a known fact that most lines will see speed differentials based on the type of chipset in use.
2) The 0.9669/0.9679% IPprofile method doesn't work for those routers performing downstream only g.inp. We've proved this is the case for both ECI and Huawei cabs.
-
Question is does ECI get something first this time :)
Seems great for lines like mine who's SNR only varies by 0.1dB, what are the odds of this rolling out in 2016?
Question is however will it be on only downstream on ECI and will Huawei be capable of this on both up and down?
-
Who knows with BT's trials :shrug2:
However, they are already aware of the fact that after application of G.INP, most lines run error free.... plus they know its already in use and working on ADSL2+ lines.
This isn't brand new technology, so if the trial is successful, I can't foresee any reason why rollout should be delayed.
Question is however will it be on only downstream on ECI and will Huawei be capable of this on both up and down?
Its simply setting a configuration parameter, both types of cabs are capable of doing it both upstream and downstream, so highly unlikely it will be cab specific.
I'm undecided how they will apply this. IMHO the easiest way for them would be to make it like 21CN DLM as a param. But it entirely depends on how much they want to keep the speed cap.
1) They could replace the speed cap with a variable target SNRm and reserve capping for lines seeing high error levels.
OR
2) They could adjust the existing cap levels to fit 3dB. Ive observed that rate limiting seems to more or less follow 6,9,12 dB, so that also would be fairly easy for them to do.
At one time BT were paranoid about users over-riding Target SNRm - they specifically saw (& cited) DMT-tool as bad in their eyes, because it easily allowed users to play with SNRm... which is why they currently use rate limiting rather than a variable target SNRm. So it depends if this is still a concern to them & if it is, then I suspect they will go with option 2.
-
Its also worth citing wombats post here too.
old rule-of-thumb data I had calculated a year ago...
My rule of thumb for what an extra 3dB of noise margin is worth in the downstream direction:
- For speeds around 20Mbps, 3dB is worth 3Mbps
- For speeds around 40Mbps, 3dB is worth 6Mbps
- For speeds of 60Mbps or more, 3dB is worth 11Mbps.
The figures comes from using the 3dB to buy one extra bit on each tone. If that can happen across all downstream tones (about 2750 tones), it buys 11Mbps.
-
Just hope that we get to see a few real world examples when the trial starts :D
Is there any charts that show the speed vs distance at 3dB on 17a?
-
A guy on TBB who I assume has access to the BTw reports given to SP's has revealed its not long before some users will be part of a small (trial?) rollout of 3db SNRM.
Its logical to assume this will be on hauwei cabinets since they have had not very long to collect data on ECI lines.
-
A slightly off topic question.
What happens to SNR on FTTP? Does it exist, and if so is it higher than FTTC's SNR?
I'm assuming if there is SNR on FTTP then it would be higher. So when G.fast comes out, which could be seen as a hybrid between FTTC and FTTP i.e. bringng an FTTP line closer to the persons house, would this mean all our SNR stats will go up?
I guess my question is, are BT looking at SNR as they are looking for a new standard, 6dB being the FTTC standard.
Looking at WWWombat's figures in kitz post, imagine dropping the dB on a higher sync G.fast line, how many Mbps would that be worth?
-
Really? Oh, yes baby! 40 Mbps here we come! We may all get a reset as well! :D
-
So, I'm about to get a 3 dB SNR Margin? This is brilliant news! Any chance they can allow users to select the SNR Margin as well?
-
good news
though me wonders what the %age the threshold of line impact acceptability will be set at. Eg, if 1 in 10 trial users who are moved to 3db end up being switched back up to 6 due to issues, will that be an acceptable figure for general public use? BT have to think of support, tickets, complaints etc when speed drops from a high level to a lower level - even if that is a level that still within the service speed of the product. that would be perceived by users as a negative aspect of the product. I guess we will never know but lets hope that the results benefit us consumers in a positive way.
-
Surely, the SNR Margin of 3 dB will only be enabled if DLM feels that the line is stable enough? Even if the 1 in 10 user gets the opportunity to experience the SNR Margin drop, DLM will only change it if the line is stable enough.
-
You're getting ahead of yourself, William. This is only a trial, and we don't know much about it yet.
-
The method of the switch isn't really relevant from a biz or consumer POV. The consumer will see drop in throughput, be it DLM or BT manually changing it. As part of the trial I think BT will be looking for how often those events happen. Most lines stable out eventually, though some stable out in a way that most of us folks in the know here would find unacceptable (the dreaded latency).
Look how much complaints crosstalk brought in - when it started to become a real issue and people saw their throughput dropping, the complaints started going up.
For the average user, the throughput dropping is nearly always noticed. If they have a service which does Xmbps and then later does less at Y mbps.
Sorry I'm probably being confusing, I'm going down into product viability and impact testing when really I should have the pom moms out and be cheering the fact the the sync on my line will rocket.
Now... if only BT did a service faster than 80/20..... :angel:
-
I have to say, I do notice the latency and throughput difference with my lower speed now DLM has banded my line... Maybe, this new SNR Margin will reset everyone's DLM? :D
-
What happens to SNR on FTTP? Does it exist, and if so is it higher than FTTC's SNR?
I'm assuming if there is SNR on FTTP then it would be higher. So when G.fast comes out, which could be seen as a hybrid between FTTC and FTTP i.e. bringng an FTTP line closer to the persons house, would this mean all our SNR stats will go up?
I guess my question is, are BT looking at SNR as they are looking for a new standard, 6dB being the FTTC standard.
Looking at WWWombat's figures in kitz post, imagine dropping the dB on a higher sync G.fast line, how many Mbps would that be worth?
FTTP isnt xDSL, so no need to worry about SNR as it connects at the given speed. Also no DLM :)
FTTdp still involves copper, but because its shorter the attenuation will be lower and SNR higher. It will still use a Target SNR though, 6dB is the default for most types of rDSL, but it can be set to whatever the SP wants (ie 3dB/6dB etc)
-
Who knows with BT's trials :shrug2:
However, they are already aware of the fact that after application of G.INP, most lines run error free.... plus they know its already in use and working on ADSL2+ lines.
This isn't brand new technology, so if the trial is successful, I can't foresee any reason why rollout should be delayed.
Question is however will it be on only downstream on ECI and will Huawei be capable of this on both up and down?
Its simply setting a configuration parameter, both types of cabs are capable of doing it both upstream and downstream, so highly unlikely it will be cab specific.
I'm undecided how they will apply this. IMHO the easiest way for them would be to make it like 21CN DLM as a param. But it entirely depends on how much they want to keep the speed cap.
1) They could replace the speed cap with a variable target SNRm and reserve capping for lines seeing high error levels.
OR
2) They could adjust the existing cap levels to fit 3dB. Ive observed that rate limiting seems to more or less follow 6,9,12 dB, so that also would be fairly easy for them to do.
At one time BT were paranoid about users over-riding Target SNRm - they specifically saw (& cited) DMT-tool as bad in their eyes, because it easily allowed users to play with SNRm... which is why they currently use rate limiting rather than a variable target SNRm. So it depends if this is still a concern to them & if it is, then I suspect they will go with option 2.
sorry I made a new thread earlier didnt see this one.
I expect the most likely way this will be done is they will adjust the SNRM target of the open profile, but any banded profiles will remain as is.
Lines on 3db exceeding ES thresholds, its harder to predict what will happen, a SNRM bump to 6db? or change to interleaving, or both. Banding seems to not be the first choice very often.
-
A guy on TBB who I assume has access to the BTw reports given to SP's has revealed its not long before some users will be part of a small (trial?) rollout of 3db SNRM.
Its logical to assume this will be on hauwei cabinets since they have had not very long to collect data on ECI lines.
Merged the two topics. As stated last night, I cant see the cabinet type making any difference.
If I had to guess at anything, then I'd place a bet they had been considering this for a while.. but didnt want to roll it out to DLM until they were more certain about g.inp applied across the whole network.
However, they are already aware of the fact that after application of G.INP, most lines run error free.... plus they know its already in use and working on ADSL2+ lines.
This isn't brand new technology, so if the trial is successful, I can't foresee any reason why rollout should be delayed.
Its simply setting a configuration parameter, both types of cabs are capable of doing it both upstream and downstream, so highly unlikely it will be cab specific.
---
ETA
Oops our posts crossed.
-
Cabinet type on a technical level shouldnt make a difference but I think they will want to be sure first that ECI cabinets are providing consistent drops of ES as are huawei, openreach generally are not aggressive in rollouts.
Then again when I made this comment on the TBB forum the guy's reply indicates I am wrong.
-
Based on the last convo I had with Ian Lawrence, he seemed pretty confident that G.INP mk2 would work fine on the ECI's. Obviously I dont know for sure, but from what he said the delay was not down to the ECI cabs themselves or EU equipment.. but stability of Openreach Field Test equipment with the ECI DSLAMs.
They seem to start pretty slow with the roll out (possibly indicating they added say 100 cabs as a test and wanted to see how they performed). For the past week or so, things have been moving much faster.
Pure speculation on my part- but it seems likely BT are now happy with the new firmware for their field test equipment... they were confident g.inp would work fine with the ECI cabs but as a precaution added 'x' amount of cabs and monitored for 2 weeks.. then started rolling across the board.
I should think that so far they will be able to see that G.INP is a success on the ECI cabs, so can now progress to a lower SNRM across their whole estate.
-
Now they just need some new firmwares for the HH5A and ECI modems so that they can do G.INP in both directions. ::)
-
:-X
-
I made a mock up graph on what I think 3dB may look like, based on WWWombat's rule.
-
I made a mock up graph on what I think 3dB may look like, based on WWWombat's rule.
It would certainly be good if they do this :)
This weekend one of my friends said to me "I got a speed increase a couple of days ago - any idea why this is?"
Now he's on Infinity (HH5A) so no definite proof it was G.INP, but he noticed the difference going from what used to be 53/54Mbps up to 58Mbps.
Speed bumps make people happy.
-
And unlike Virgin Media they are not followed by a price increase lol
On a serious note if the snrm drops to 3db across the board could BT lift the cap so people who can get higher than 80mbit where the line allows it are able to do so or will they going by WWWombat's graph simply allow more people to obtain higher speeds at longer distances away from the cabinet?
I guess the best case would be both so people get both the higher speeds of up to 80 and others who's line supports it get 80+.
-
Considering BT were on about not changing the cap for a vectoring rollout I don't think they will.
-
They wont change the cap with this, this will be to just improve the speeds for those who sync below the cap.
Not to mention 80mbit is enough for what 99% of everything out there.
A game changer would be something like 4k streaming with no compression or something along those lines.
-
I don't think BT will increase the top package speed of 80/20 through this. As mentioned, they saw the benefit of vectoring as a way of making speeds more consistent rather than faster - and vectoring probably has more potential for speed gain than a variable SNRM. I should reiterate that it doesn't have to be a 3dB target. Changes of 1dB are plausible too, just resulting in less of a gain.
I'll add a note that I was first inspired to calculate the speed equivalent of 3dB when Eircom turned on vectoring, and it still looked like BT would be too. Eircom don't use DLM, and turned on both G.INP and Vectoring at the same time, but left their standard SNRM target as 9dB.
It'll be interesting to see what mechanism they use to deploy and vary the settings.
-
A game changer would be something like 4k streaming with no compression or something along those lines.
Uncompressed video tends to use an infeasible amount of bandwidth:
width × height × bits per pixel × frames per second
(3840 × 2160 × 24 × 24) = 4,777,574,400 or approx. 4.8 Gbps
-
A game changer would be something like 4k streaming with no compression or something along those lines.
Uncompressed video tends to use an infeasible amount of bandwidth:
width × height × bits per pixel × frames per second
(3840 × 2160 × 24 × 24) = 4,777,574,400 or approx. 4.8 Gbps
Say more along the lines of blueray quality I know some of my 1080p Bluerays use >50mbps.
So 4K streams could be less compressed and run at higher rates such as 60-120mbps, 8K seems more likely however as I'm pretty sure you need 140mbps to stream it even with h.265.
-
I am sure that someone will have the stats to hand but as most end users are relatively close to the cabinet in the UK, this should mean lowering the target SNRM will enable many more to get higher speeds/80MB - though if they do, then Crosstalk may become a bigger issue than it is today increasing calls for Vectoring..
On the demand for bandwidth - ISPReview recently did an article on what a big impact compression made to reducing the bandwidth needed - and with further improvements expected
H.264 / AVC MPEG4 720p [MKV]
Video File Size: 987 MegaBytes
Time to download at 2Mbps = 1 Hour 9 Minutes
Time to download at 24Mbps = 5 Minutes 44 Seconds
H.265 / HEVC MPEG-H 720p [MKV]
Video File Size: 243 MegaBytes
Time to download at 2Mbps = 17 Minutes
Time to download at 24Mbps = 1 Minute 24 Seconds
NOTE: We could have compressed the H.265 copy even more and made it just 160MB in size, but this would have lost just a little too much quality.
Full article: http://www.ispreview.co.uk/index.php/2016/03/the-importance-of-video-compression-to-broadband-isp-speeds.html