ZEN's GEA backhaul ABNORMAL buffer bloat

SINCE my FTTC circuit was changed from TT wholesale's backhaul onto zen's GEA suppliers, my buffer bloat has increased massively ,Prior to this change to zen's backhaul topology this never occurred the max latency was 60ms when ds throughput was maxed out across ISP's So a limitation of the open reach supplied HG612

when maxing out my downstream throughput so much it could saturate the connection more so than the upstream , I have had vdsl2 since 2013, and the latency whilst maxing out the throughput has never risen beyond 60ms,

since zen's intervention it is now reaching over 200ms the upstream would and still only reached mid 100s ms

Zen's network is inferior to others ,or it;'s down to to how the numpties have my circuit configured, IMO? BTW,

Any ideas as to the reasons for this increase since they switched me to their network/backhaul are welcome,

Speedtest.net Result that SHOWS BUFFER BLOAT

Edited by tommy45 (Sun 08-Jan-23 21:49:33)

Nothing to do with inferiority of network or otherwise just how the Plexus network is configured and polices traffic.

If Bufferbloat is a problem for you there are plenty of options on your side that can help.

Such as ? Restricting my through put? no thanks, like i explained before this change never had any issues So not down to me to make changes apart from isp

In reply to a post by tommy45:

Such as ? Restricting my through put? no thanks, like i explained before this change never had any issues So not down to me to make changes apart from isp

Yep. Either you or they have to restrict the throughput to reduce the bufferbloat so that your line never maxes out. As soon as it maxes out you/they lose control. Zen are presumably trading bloat for packet loss: bigger the buffers the fewer packets get dropped waiting.

Well what ever this is It's not my doing, and they managed it just fine UNTIL they change the topology that's BT, WBMC and TT to their own inferior solution , So why Now? MISCONFIG is my GUESS or congestion I'm 'ONLY 80/20 fttc vdsl2 so god knows how much the full fibre customers are being shafted hey? I know who i wont be subbing to for full fibre

And BTW neither BTW or TTW showed any packet loss regardless of plus NOT or Zen ISP'S ONLY BTW SHAPING DUE IT's ARTIFICIAL IP PROFILE CAP on throughput THIS IS AN EXAMPLE OF THIS SUBSTANDARD OF SERVICE 200MS+ BUFFER BLOAT ON DOWNSTREAM THROUGH PUT

Edited by tommy45 (Mon 09-Jan-23 00:29:37)

I think you've just been very lucky so far, I always had to use local QoS to mitigate buffer bloat on Zen FTTC over TT, and in fact on every ISP I've ever used.

While I do wish ISPs would cap downstream properly as only they can properly manage that, IMO they rarely do. Overall its tricky as when you may sync at a different speed each time, with varying levels of error correction and line quality, trying to accurately track that and throttle accordingly is a pain. You can either be aggressive and the customer loses some speed, or be lenient and they suffer bloat.

The HG612 for example by default loses about 1Mbit off upstream to QoS, its one of the thing first things I turned off when unlocking it.

Edited by alexatkin (Mon 09-Jan-23 05:39:46)

Given my plans for the year I'll leave this one. Hope you can get it sorted to your satisfaction.

Mine is similar:

https://www.speedtest.net/result/14182392548

In reply to a post by XGS_Is_On:

Given my plans for the year I'll leave this one.

Good to see you're still on track

Bufferbloat is not necessarily bad, probably easier to manage via shaping, than if an isp has tiny buffers and chooses to drop packets instead.

Delayed packets are also a lesser evil vs dropped packets.

I found on DSL with my tests on UDP iperf, anything above about 20% utilisation I started getting dropped packets, it hit a level which would be real world affecting at only about 60% utilisation.

Whilst on 4G and cable, where buffer bloat seems more of a thing, the packets dont get dropped until almost 100% utilisation, which to me is much more preferable behaviour. Granted on gigabit cable the sheer size of the pipe helps, but 4g is still under 200mbit, and doesnt have the DSL packet loss problems I had. I prefer my ISP to keep the packets in transit rather than dropping if is local congestion and to manage the congestion myself.

Edited by Chrysalis (Tue 10-Jan-23 15:47:11)

Random thought …. your HG612, have you tried replacing it ? It is VERY old tech now.

There's not really anything better, depending on your line. If it was failing I'd expect lockups/sync drops rather than bloat.

The ECI tended to have caps go bad, the HG612 seems better built.

In reply to a post by Zarjaz:

Random thought …. your HG612, have you tried replacing it ? It is VERY old tech now.

Old tech or not, Why would i have the issues SINCE a Topology migration? Can you tell me how this " old tech," that may not be as used as you think it maybe ,is the culprit?
IMO change of backhaul provider is the problem, I bet i could arrange for a loan router /modem that zen supply and the buffer bloat when downloading multithreaded would be the same or similar , SIMILAR BECAUSE THEIR SUPPLIED CPE IS 1 GB MODEM The HG612 is only 100mb as is the EWAN on my Billion router , but has 1gb lan

and i have found that if i pause a download and start another straight away the buffer bloat is reduced to below the average of 60 ms , but start to download a new file and it returns up has high as +400 ms my upstream used to be the biggest buffer bloater, typically over 100ms, multithreaded ftp now that is around 60ms Me thinks config issue ZENS side

Edited by tommy45 (Thu 12-Jan-23 21:48:22)

Have you had a chat with technical support and are you actually noticing anything that is impeding what you are trying to do with your connection?

You can have too much information, if it's not causing you a problem, why worry?

If it is preventing you from doing something, ring them and have a calm chat, always found them more than willing to run tests and to help you narrow things down, one of the reasons I've been a customer for so long.

I have been in contact with support and after explaining a few times what the issue was Excessive buffer bloat whilst downloading , They set up monitoring of the latency but their graph didn't really show the detail needed , so i sent them snapshots of my tbqm and f8lure graphs and they agreed this was not normal,

so to rule out my equipment, they asked if i would mind if they sent me a fritzbox to rule this out , i set up the new router and tested to see if it had resolved the issue, which It had, so out of curiosity i swapped back to my old set up, and the problem did not re-occur, to the cause ???? maybe some kind of glitch with the DSLAM /line card or the modem that cleared as a result of connecting to a different modem ?

And the old hardware had had several re synchs following the network migration in April ,although it had increased since then , as a result i lost the full synch and 5db snr i obtained following a re-synch following a brief (under 30sec) power outage, But buffer bloat back to normal ,infact a slight improvement on upstream buffer bloat when several FTP threads are active

Edited by tommy45 (Wed 18-Jan-23 23:13:18)