Kitz Forum
Broadband Related => Broadband Technology => Topic started by: re0 on August 22, 2019, 02:09:02 AM
-
I had a resync at approx. quarter past midnight. I had investigated it since I have been having some weird spikes recently, some that have knocked out connectivity. In this case, nothing prior to the resync - just 1 as the Retrain Reason.
What I did notice was a sizeable increase in downstream attainable, going from 347 Mbps to 383 Mbps.
Before:
Max: Upstream rate = 67849 Kbps, Downstream rate = 347559 Kbps
Bearer: 0, Upstream rate = 50016 Kbps, Downstream rate = 335116 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.7 8.8
Attn(dB): 31.5 0.0
Pwr(dBm): 0.0 4.0
After:
Max: Upstream rate = 67037 Kbps, Downstream rate = 383312 Kbps
Bearer: 0, Upstream rate = 49976 Kbps, Downstream rate = 328995 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.9 9.1
Attn(dB): 29.2 0.0
Pwr(dBm): 0.0 4.1
10% would be a lot if no variables had changed, so there must have been a reason - and there was:
Before*:
Discovery Phase (Initial) Band Plan
US: (368,1927)
DS: (368,1927)
Medley Phase (Final) Band Plan
US: (368,1808)
DS: (368,1674)
After:
Discovery Phase (Initial) Band Plan
US: (348,1802)
DS: (342,1666)
Medley Phase (Final) Band Plan
US: (348,1800)
DS: (342,1666)
It seems they have adjusted the Band Plan for Downstream so it starts 1345.5 kHz lower, and 1035 kHz lower for the Upstream (this is based on 51.75 kHz spacing). The initial plans have changed, too; the Downstream is 13506.75 kHz less at higher frequencies, and Upstream is 6468.75 kHz less.
If we look back to end of May this year, ISPreview had posted some news here (https://www.ispreview.co.uk/index.php/2019/05/openreach-work-hints-100mbps-at-500-metres-on-g-fast-broadband.html) about G.fast co-existence. While options have been considered to improve speed and coverage, it seems reducing the start point for G.fast to approx. 17.7 MHz is what has been taken - at least for now.
19.044 ((368 * 51.75)/1000 - previous G.fast start point, in MHz) minus 1.3455 equals 17.6985 MHz, which is only a little above 17.664 MHz (bandwidth for VDSL 17a). While I could be a little bit off, this would still suggest that the start point has been reduced.
In conclusion, it seems Openreach may be now rolling out these changes nationwide to improve coverage (and bring existing users a speed boost). I am not aware of the exact changes made, so I am going on the information I have from my own connection and comparing historical data.
If anyone has access to their G.fast stats, it would be appreciated if you could take a look to see whether your connection has been subject to these changes yet.
*This was not directly before the resync since DSLstats had not been logging pbParams, but these stats are still applicable having checked bitloading from the last snapshot.
Edits:
22/08/2019, 12:48: Clarified some information, fixed a mistake.
-
Most interesting, I don't have access to detailed stats via my mt992 (and I'm in Vancouver at the moment) but your post inspired me to check my line data on the Zen portal.
I seem to have had a resync on 22nd August at 0:07 which is my first resync in a couple of months and I've seen a downstream increase from 229mb to 244mb which would be the highest ever for my line. There is no change to my 35mb upload.
It will be interesting to see if other people have seen something similar.
-
Interesting. Thank you for reporting your findings. Nice little speed boosts there :thumbs:
-
https://www.ispreview.co.uk/index.php/2019/08/band-plan-change-boosts-speed-on-some-uk-g-fast-broadband-lines.html
Info taken from and linked to this thread.
Positive change from OpenReach. Pointless having such a large gap in spectrum if it's not needed.
-
I was contemplating not posting about this, but I am glad I did now.
A free speed boost is a good speed boost. Even though us closer-to-the-cab people can't benefit from speed, it gives a nice margin. :)
From the article:
We have asked the operator and are awaiting their feedback, so at the moment this is not confirmed.
Would be interesting to know whether there have been other changes I haven't picked up on, and whether this is nationwide yet.
-
Maybe Openreach has finally listened to my complaints few months ago over poor estimated speed on G.fast 114/9 but still not good enough. Hoping for FTTP to come along from this ISP Exascale
-
Same here @re0.
I'm not at home so don't have full access to my line stats but a live view can be seen at http://stats.browni.co.uk/
-
Would this imply that the distance reach for G.Fast has extended slightly?
-
I'm not at home so don't have full access to my line stats but a live view can be seen at http://stats.browni.co.uk/
I see a change in your downstream pattern that may suggest the change is in effect for you. You could probably tell from an Attenuation drop (which appears to be applicable from a previous post of yours), but most reliable way of looking at pbParams since it would outline the Band Plan. Note: At least on my Zyxel and DSLstats v6.5, pbParams doesn't update automatically so it may be necessary to run with --pbParams parameter in telnet or SSH.
Would this imply that the distance reach for G.Fast has extended slightly?
Very slightly. Though I would guess the biggest sync speed (note: NOT attainable) gains for those with approx. 240m line length since it should bring them close to 330 Mbps downstream. For upstream, I have not seen anything convincing yet to suggest any improvement to speed so far.
-
re0 will these see slight change in dsl checker estimated speed range?
-
re0 will these see slight change in dsl checker estimated speed range?
Not seen any yet, but still early days. I presume that the estimates will be updated after few days following these changes.
-
It's been a few weeks, and I thought I should drop an update stating that I have seen no changes to the DSL checker estimates for G.fast following this Band Plan change. I thought there would be a slight increase, but perhaps they are going to be conservative with the estimates or it isn't prime time yet.
-
Thanks for checking and letting us know. Please do tell if they do update.
-
it isn't prime time yet.
It doesn’t look like G.fast will ever see prime time.
-
It doesn’t look like G.fast will ever see prime time.
Sure, talking about it in general. :D But I was referring to it being prime time for changes to the estimates. :)
-
Had to power down the modem for a few hours a couple of days ago while reorganising some stuff, and when I reconnected in the evening I had a crazy attainable of just over 400 Mbps:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 65611 Kbps, Downstream rate = 401360 Kbps
Bearer: 0, Upstream rate = 49967 Kbps, Downstream rate = 329035 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 7.9 8.7
Attn(dB): 29.7 0.0
Pwr(dBm): 0.0 4.0
It's settled now, so mostly sitting in the high 390's. But I am pretty sure this change has made it so quite a few more properties locally would be almost guaranteed to be able to max out on the 330/50 package now.
-
I think my cabinet has been done, since I had about 30 minutes downtime on the 2nd around 1am. When it came back, my upload had jumped a few Mbps, sitting at 48965, according to Zen’s customer portal. I have the Huawei modem, so I can’t say for sure whether this has happened. my download hasn’t changed at 303034.
-
Had to power down the modem for a few hours a couple of days ago while reorganising some stuff, and when I reconnected in the evening I had a crazy attainable of just over 400 Mbps:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 65611 Kbps, Downstream rate = 401360 Kbps
Bearer: 0, Upstream rate = 49967 Kbps, Downstream rate = 329035 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 7.9 8.7
Attn(dB): 29.7 0.0
Pwr(dBm): 0.0 4.0
It's settled now, so mostly sitting in the high 390's. But I am pretty sure this change has made it so quite a few more properties locally would be almost guaranteed to be able to max out on the 330/50 package now.
That crazy 400Mbps down and 65Mbps up. Do Openreach plan to have 400/65 product soon for your G.fast? ;D ;D We only wish!
-
It's actually a real shame since VDSL in areas where vectoring is possible could have their spectrum reduced and vectoring enabled to have the same range of speeds while the G.fast start frequency could be reduced further. No overlapping necessary.
I'm probably grossly oversimplifying the situation because I cant remember vectoring densities and prerequisites, but G.fast doesn't need to die so young. It could be quite possible to do 550/75 Mbps at approx. 150m (which matches the FTTP package available from OR) if they could get the starting frequently to 15 MHz. I could probably achieve max. 450/75 at 200m with the same parameters.
-
It's actually a real shame since VDSL in areas where vectoring is possible could have their spectrum reduced and vectoring enabled to have the same range of speeds while the G.fast start frequency could be reduced further. No overlapping necessary.
I'm probably grossly oversimplifying the situation because I cant remember vectoring densities and prerequisites, but G.fast doesn't need to die so young. It could be quite possible to do 550/75 Mbps at approx. 150m (which matches the FTTP package available from OR) if they could get the starting frequently to 15 MHz. I could probably achieve max. 450/75 at 200m with the same parameters.
No, they'll never change it -330/50 and 160/not sure the upload - is what has been ratified and I doubt it'll ever change from that.
-
No, they'll never change it -330/50 and 160/not sure the upload - is what has been ratified and I doubt it'll ever change from that.
I doubt that too. It was just more of a thought on how G.fast could make a bit more sense for an in-the-meantime solution especially since according to this (https://www.thinkbroadband.com/news/8589-40-more-exchanges-with-some-g-fast-coverage) ThinkBroadband article:
- There are 8,330 pods
- Those pods cover 3,312,664 premises
- 1,978,816 premises total have G.fast available
I understand there may be some minor inaccuracies here and there, and it is a case where this is based on what they "know about" so there could be more premises and pods. But given those figures, ~60% of premises connected to a cabinet with a pod have the service available - though it is not clear whether this is based on old 100 Mbps or new 120 Mbps minimum; I think it still may be the former, so %'age may be even less - perhaps closer to 50%.
Being able to reduce the existing VDSL2 spectrum and have a lower start frequency for G.fast makes sense to increase the potential amount of properties that can get the service. Though there would still be challenges with subscriber densities (from what I remember, it is still 48 per pod with 96 being a target) which means it cannot be a long-term solution for everybody to have access. And there is the issue of existing VDSL hardware in some locations that cannot be vectored easily (ECI), or the case where there are multiple DSLAMs for the same PCP.
Perhaps it really doesn't make sense for expenses. But it doesn't need to - I just wanted to write a little bit about it. There are more premises that can get G.fast than ports on my cabinet - probably up to 3-4x as many premises as there are ports can get 120+ Mbps as there is anyway.
-
Oh, wasn't trying to rubbish it. I do think they could have been a bit more liberal with the offerings, same goes for plain old FTTC too.
-
It's cool, I understand. The potential is not really exploited. Even OR FTTP is lacking symmetrical speeds (which is not really exploiting fibre), but hopefully "trials" should change that.
-
I wonder if there was another set of changes last night?
I had the re-sync on 22nd August in the early hours where I gained an extra 14mb ish (229713 to 244198) and that has been stable and no further resyncs until one in the early hours of this morning (1.52am to be precise) where my sync has now gone to 258217 and the upload from 35 to pretty much 40.
Anyone else get anything similar last night?
-
Not seeing anything on my end. Doesn't imply no further changes, but it may be your local conditions have changed (perhaps interference has reduced or target SNRM has changed).
If any there are any noteworthy changes, I'll update it here when I become aware.
-
Thanks for getting back to me. Sadly, I only have the Zen portal to rely on for sync changes and that doesn't have SNR or other info.
I will make use of my extra speed over the weekend though!