Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: bottlerocket on January 12, 2022, 07:35:12 PM
-
Hi. I've been on g.fast for a little under 18 months. Downstream sync speeds up until last month were around 150000. Early December the sync rate started to drop. It's now sitting at around 100000. I've contacted my ISP who have said they can find no fault and Openreach don't consider it a fault as their speed checker gives around 102Mb as the max line rate. When I checked www.broadbandchecker.btwholesale.com I get a rate range of 128-154Mb, which is the speed I was told when I signed up with ISP.
ISP have said to try a new filter and master socket, which I'll do when I get a new filter. That the ISP say the line isn't capable of more than I'm getting indicates to me this probably won't help.
Is this sort of rate drop within what I should expect from g.fast?
-
AFAIK g.fast shouldn't reduce dramatically unless there is a problem as those frequencies are only used for other g.fast customers and all lines have vectoring. Will defer to others on the forum who know better though.
-
Trying to interpret what you was told by the ISP, it would mean either the openreach estimate is only 102mB, or that their own tools have never logged a sync speed higher then that, I have observed on FTTC, sync speeds only seem to get logged when a GEA test is carried out, which is why when I was syncing at 80 I deliberately ran a GEA test to get it logged. Whether g.fast is the same absolutely no idea.
Hopefully someone better can give you an answer, but I think with vectoring there is no crosstalk excuse to hide behind anymore and such a sharp drop in speed suggests either new external interference or a fault.
-
Welcome to the forum, Bottlerocket, by the way!
-
ISP in question logs the sync rate seemingly each connect. I can see from the log 150000 was common for the first 16 months, it’s only got worse in the last month.
What the ISP have said is that Openreach can and do vary the expected line rate and it could be due to more users connected to the cabinet or the original estimates being wrong. However the line was happily given 14MB/s via fast.com for 16 months. It’s now down to 100MB/s or just below. Upstream is also worse (23 vs 27).
What i do t understand is why openreach are apparently given them one set of figures and the bt wholesale is given a different set - the wholesale values seem current as it is showing the seen max bandwidth as todays date.
I changed the filter today and as expected no better sync rate.
I rather feel like I’m being fobbed off.
-
That's because you likely are being fobbed off.
When you signed up you were provided an estimated speed range and a guaranteed minimum.
If you are below the guaranteed minimum quoted to you at the time of sign-up (or your most recent renewal) then the ISP are free to ask Openreach to come try and increase the speed.
Some providers will happily arrange for Openreach to try bring your speed back up. If the line is below the figures mentioned above then this isn't a chargeable visit for the provider.
If Openreach fail to bring the speeds back above the minimum guarantee then you are free to leave your contract.
Many providers won't even try this process and will simply refuse to arrange an engineer. They will simply allow you to leave your contract.
The profit from you as a customer is less than it cost to provide the support to fix your issues so some just don't bother.
The estimates on the BT Wholesale checker are irrelevant. They do indeed change over time and can be lower now than when you initially joined.
The only important figures are your contractual figures that you agreed and signed up to.
I would be pressing the provider to try get them to arrange an Openreach engineer to increase the speeds on the line.
What was the guaranteed minimum quoted to you when you signed up/last renewed?
Who is the provider?
-
I had an estimated 122200-160000 typical 160000. I didn’t not get a guaranteed minimum that I can find now. ISP is Zen.
-
Ask for an escalation of the support case. The engineer found there was a profile on the line which they have requested be removed. :fingers:
-
@Chrys - what’s a GEA test ?
-
@Chrys - what’s a GEA test ?
Generic Ethernet Access:
Generic Ethernet Access (GEA) is an entry-level, Ethernet based technology, utilizing existing copper infrastructure to provide an efficient and cost-effective leased line internet connection.
-
@Weaver A GEA test is run by CPs as a general sanity check on FTTC and G.Fast lines. It gives a range of information and can report major errors.
Below is the text from a GEA test on the Plusnet forum, there are many examples there.
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0000
Description GEA service test completed and no fault found .
Main Fault Location OK
Sync Status In Sync
Downstream Speed 42.1 Mbps
Upstream Speed 9.9 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Pass
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Estimated Line Length In Metres 682.9
Upstream Rate Assessment Reasonable
Downstream Rate Assessment Reasonable
Interference Pattern Regular Interference Observed on Week Days
Service Impact Retrains Observed
Interference Duration Longest Occurrence From18:00to18:15
Interference Location Customer Premise
Interference Observed In Days 4
Home Wiring Problem Not Detected
Technology VDSL
Current 15Min Bin Retrains 0
Last 15Min Bin Retrains 0
DP Type External
Profile Name 0.128M-49M Downstream, Retransmission High - 0.128M-20M Upstream, Error Protection Off
Time Stamp 2022-01-01T10:30:00
Parameters MIN MAX AVG
Down Stream Line Rate 43.9 Mbps 48.9 Mbps 46.1 Mbps
Up Stream Line Rate 9.7 Mbps 10.0 Mbps 9.9 Mbps
Up Time 532.0 Sec 900.0 Sec 898.3 Sec
Retrains 0.0 5.0 0.0
Current and Last 15 Minute Bin Performance
Parameters Last Traffic Count(Upto 15 mins) Current Traffic Count(Upto 15 mins)
Start Time Stamp 2022-01-14T10:05:18Z 2022-01-14T10:20:18Z
Ingress Code Violation 1 0
Egress Code Violation 0 0
Errored Seconds 0 0
Severely Errored Seconds 0 0
Unavailable Seconds 0 0
-
@RealAleMadrid That’s really interesting, thank you! I’ve never heard of that, not having VDSL2. Can an end user get hold of the report easily / routinely through their ISP ? (if the ISP is any good)
-
@Weaver, all good ISP should provide.
-
@RealAleMadrid That’s really interesting, thank you! I’ve never heard of that, not having VDSL2. Can an end user get hold of the report easily / routinely through their ISP ? (if the ISP is any good)
AAISP has a button on the control panel to run it. However the report that comes back isnt the full report, it omits the DLM profile and I think one or two other bits.
-
> AAISP has a button on the control panel to run it.
Ah. I don’t see that button because I don’t have VDSL2. The layout of the control panel is variable per line type. My lines changed from BT 20CN to 21CN and that made the controls change, with more options available.
-
Zen did a profile reset. Sync went up to 144849 which is what it typically was for the first year of service. 3 days later it's now 114681.
A resync happens every few days mostly during the early hours of the morning.
Contract period is coming to an end, so I may just get rid of the g.fast. Or maybe I wait for FTTP which apparently will be coming in the next few months.
-
Yeah G.fast are not bad for my property. I am going back to FTTC in May when my contract has finished.
-
Update time :)
Sync rate dropped below 100Mbps and Zen agreed to send out Openreach. Engineer attended, replaced face plate and cable and reset the line profile. Got the best sync I've ever had on the line for a few days. Then the same problem started again and the sync rate dropping gradually over six weeks to a little under 90Mbps. New case raised with Zen who want me to plug a new filter into the master socket and maybe replace the router.
I have never noticed any drop outs on the line other than the resync in the early hours of the morning as the sync speed drops.
-
Kinda silly to want you to use the test socket when the face plate has just been replaced, but gotta follow the script I guess.
The router on the other hand is definitely worth a try.
-
Better go back to fttc if your gfast below 100 meg.
-
Second engineer could see a sync at around 160. Couldn’t find any other issue. Replaced the modem and Ethernet cable. Resetting the line profile put it back up to 140.
I’m beginning to wonder if the QoS on the router may be having an affect but I don’t understand why that could be - router is running openwrt. Can the layer running over the PPPoE affect sync? I had assumed it was entirely down to lower layers than that.
Went back to Zen after the engineer visited to ask for a regrade to vdsl2. They want me to plug the modem into the test socket again!
-
That's stupid of zen support team asking you to plug into test socket I suggest you tell them no I want downgraded to vdsl or I leave with no fault of mine. Zen only want your money. That's all they care about.
-
Isn't it a bit soon to ask for regrade if you just replaced the modem and had a profile reset?
-
Two engineer visits, new modem new cables new face plate. Profile gets reset slowly degrades over 6-8 weeks. Don’t want to pay £15/month for bandwidth I’m not benefiting from.
I could look at the router but I don’t see how it’s involved. It’s over Ethernet across the house but I don’t see how that would affect it.
Really I’m bidding my time until fibre I feel at this point. I don’t want to switch from Zen as their network has been reliable. I could switch back to A&A and save a fiver I guess.
I’ve switched QoS off on the router any way and will have a poke around with it.
-
On my gfast Openreach modem giving sync of 181/27 because I believe it got QoS enabled. I use my own gfast router and turned off QoS as the sync rate went to 241/41.
QoS enabled does affect gfast with poor sync rate.
But mind you I do not have gfast anymore.
-
I could look at the router but I don’t see how it’s involved. It’s over Ethernet across the house but I don’t see how that would affect it.
Okay, I'm intrigued.
Are you forcing full duplex gigabit over this connection or are you setting it to auto?
-
I’m beginning to wonder if the QoS on the router may be having an affect but I don’t understand why that could be - router is running openwrt. Can the layer running over the PPPoE affect sync? I had assumed it was entirely down to lower layers than that.
I also can't think how the sync rate could be affected like that, but there are far more learned members who will doubtless explain.
-
A bit more info on my set up:
* Line sync speeds are taken from Zen's portal.
* When downstream is high (150Mbps), upstream sync to around 25Mbps. When the downstream drops, upstream increases up to near 30Mbps.
* OpenWRT 21.02.1 on Linksys WRT3200ACM. QoS is Cake via the peice_of_cake.qos setup script. Bandwidth caps are set to about 10% less than results from fast.com. Packet overhead is set to 34. MTU is 1500 on the PPPoE link, with 1508 (I think, maybe higher) on the Ethernet port and switch ports. IPv4 (single) and IPv6 (via delegation) are used.
* Router is attached via Cat5/6 to a rj45, then trunking under the floor, to a patch panel and then a Unifi switch. MTU is at 1508 on the switch ports
Line is solid, I can't recall the last drop out that wasn't in the early hours of the morning. Speed test are always consistent. QoS works well, causing less latency on a loaded link and better bandwidth sharing.
QoS enabled or disabled doesn't affect the line speed on a quiet line - enabling QoS doesn't suddenly cause the line speed to drop.
I'd love to figure this out if it is something my side :)
-
Since last update, Zen replaced the router with a FritzBox. It didn't help. Line sync dropped as low as 61000 in July.
I nearly gave up on Openreach and started the process of moving the Virgin Media, but found after the initial sales call the level of communication from Virgin was dismal (cancelling the contract in the cooling of took 4 calls and a total of 3 hours on the phone...)
Anyway, since then, the speed has started improving, and I'm now sitting at a sync of the package max and getting speeds of 150Mb/s on fast.com - 140Mb/s was the previous top I'd seen.
Coincidentally an Openreach contractor installed new cabling down the street last night, so hopefully they're upgrading the area the FTTP and in doing so fixed the issue I was having.
-
Further update. I switched to OpenWRT with Codel Cake QoS and sync rate dropped. I switched back to the Fritz box without QoS and,after a few weeks, sync improved. Coincidence? I had been assuming so, not I am not so sure.
Ping has also dropped in half - used to be around 18ms, now see as low as 7ms, which I guess is exchange work for FTTP.
-
QoS is an upper layer traffic mechanism - it will have no bearing on the sync rate.
-
Ping has also dropped in half - used to be around 18ms, now see as low as 7ms, which I guess is exchange work for FTTP.
If you're still on Zen its more likely you were on Manchester gateway and randomly ended up on London.
AFAIK FTTP backhaul is completely different to FTTC, so upgrading for FTTP should make zero difference to FTTC.
-
QoS is an upper layer traffic mechanism - it will have no bearing on the sync rate.
Yes, and, as I noticed last night, the cheap fixed line phone handset has been unplugged, which seems a more likely culprit! :blush:
If you're still on Zen its more likely you were on Manchester gateway and randomly ended up on London.
This seems to be the case - traceroute shows transit via london routers after leaving my router. A nice bonus.
-
Is the change in ping time to do with G.INP parameters changing? Can you see those stats?
-
AFAIK FTTP backhaul is completely different to FTTC, so upgrading for FTTP should make zero difference to FTTC.
Did you mean to say that? It's different so makes no difference?
It depends on the backhaul provider but generally the backhaul is identical between FTTC & FTTP.
The only difference in latency between the 2 is what is added by the DSLAM.
Is the change in ping time to do with G.INP parameters changing? Can you see those stats?
G.INP adds no delay.
It's INP+Interleaving that adds a minimum 8ms on FTTC.
-
Yes, and, as I noticed last night, the cheap fixed line phone handset has been unplugged, which seems a more likely culprit! :blush:
Ah yes, a far more likely candidate indeed :)
-
Did you mean to say that? It's different so makes no difference?
It depends on the backhaul provider but generally the backhaul is identical between FTTC & FTTP.
The only difference in latency between the 2 is what is added by the DSLAM.
I must be confusing something else, I was thinking FTTP and FTTC have their own backhaul. I was likely thinking of some other part of the chain that I can't think of the name of right now.