Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bogof]

Touchwood so far I have not had any issues with zen after 2 years on fttc and now on fttp (900). It would be nice to know wether I am on zen's own gea or not but probably will never know unless an order goes through. I am following the various posts with interest.

Your TBB doesn't seem to have the same furry characteristic as mine does, with the min/avg/max latency all being very distinctly visible as lines... And your speedtests seem good too.  I don't think there is much point worrying about it unless one or both of those change.  It's not like you can pre-emptively do much about it.  The only thing I would say would be of benefit would be if possible to have some history of speed test results to fall back on if it changes. 

[craigski]

I'm confused. What exactly is the specific 'performance' issue some users are experiencing? Is it ping times to a specific IP address? Is it speedtest results on a specific speedtest site? Is it issues with TBB ping results?

[bogof]

I'm confused. What exactly is the specific 'performance' issue some users are experiencing? Is it ping times to a specific IP address? Is it speedtest results on a specific speedtest site? Is it issues with TBB ping results?

My speed tests aren't what they should be, Zen's own server never hits line rate, whereas it has almost always, prior to my current situation.
The ping results changed markedly at the point of the GEA migration to Zen's service.  These seem unlikely to be unrelated coincidences.

While the ping results themselves don't seem very bad - about 3ms min / 4ms avg / 5ms max - there is a marked difference to how the line behaved pre-migration, where it was pegged at 5ms for all, in all but the most extreme usage.  To be clear; I don't care about the variation in ping times, I merely think it gives some insight into what may be going on leading to poor throughput performance.

In the case of @skyeci they have neither of the characteristics I've observed, so seems unlikely they're affected by anything I might be seeing.

[j0hn]

Just to be clear, does that mean the info posted that I originally quoted from you must be incorrect or out of date?  You posted with some authority, which lead me to believe that I might be on an exchange with one or several Gb links but not a 10Gb link.

The info I posted is correct. They have exchanges where they only have 1Gb GEA cablelinks.
On those exchanges with 1Gb cablelinks any customers with over 330Mb/s need provisioned on BTW or TTB.
They do not put 1Gb customers on 1Gb links.

If Zen have moved your to their own GEA platform and you have gigabit then Zen have 10Gb GEA cablelinks in place.

That's what I said previously.

Zen have 1Gb GEA cablelinks in some Headend exchanges but no 10Gb cablelinks so anything above 330Mb/s would need to be over BTW or TTB.

[bogof]

The info I posted is correct. They have exchanges where they only have 1Gb GEA cablelinks.
On those exchanges with 1Gb cablelinks any customers with over 330Mb/s need provisioned on BTW or TTB.
They do not put 1Gb customers on 1Gb links.

If Zen have moved your to their own GEA platform and you have gigabit then Zen have 10Gb GEA cablelinks in place.

That's what I said previously.

OK, I see what you meant now, the order of your sentence I think left it ambiguous, hence my question.  I read it that "Zen have no 10G cablelinks".

[craigski]

My speed tests aren't what they should be, Zen's own server never hits line rate, whereas it has almost always, prior to my current situation.
The ping results changed markedly at the point of the GEA migration to Zen's service.  These seem unlikely to be unrelated coincidences.

To be clear; I don't care about the variation in ping times, I merely think it gives some insight into what may be going on leading to poor throughput performance.

OK, lets ignore the pings for the moment. Can you be more specific about the speed tests? My experience is they are at best a 'guesstimate' on the higher speed products, use 4 different speed test sites/servers you will get 4 different results. (see my post a few days ago in this thread)

I'm also of an opinion that there is some marketing 'fluff' of the products, eg the Zen 900 residential package says '900Mbs Average Download' I think that is open to interpretation, my interpretation is that is a maximum speed of the product.

[skyeci]

Not seeing any issues on my 900 product currently. I appreciate that could change but so far so good.

[Alex Atkin UK]

I'm also of an opinion that there is some marketing 'fluff' of the products, eg the Zen 900 residential package says '900Mbs Average Download' I think that is open to interpretation, my interpretation is that is a maximum speed of the product.

That is correct, as it would only take two customers on the same PON pushing Gigabit to more-or-less max it out, so it cannot be guaranteed.

However I would argue that is irrelevant to the topic, as the problem is the behaviour changed between backhaul providers, so clearly not a PON issue.

[bogof]

OK, lets ignore the pings for the moment. Can you be more specific about the speed tests? My experience is they are at best a 'guesstimate' on the higher speed products, use 4 different speed test sites/servers you will get 4 different results. (see my post a few days ago in this thread)

I'm also of an opinion that there is some marketing 'fluff' of the products, eg the Zen 900 residential package says '900Mbs Average Download' I think that is open to interpretation, my interpretation is that is a maximum speed of the product.

The speed tests are done from the Speedtest.net CLI tool in the case reported above, to Zen's own and Swish Fibre's servers.  These are the same test servers as you can access at www.speedtest.net, and they do perform as you would expect in the presence of an unencumbered internet connection and a home network that is so capable.  I used the command line version as it was easy to script and run repeated tests over and over, but you get basically the same results from the web browser.  @skyeci has already shown his connection now is performing how mine was prior to the Zen GEA migration event (ie achieving over 900mbps to Zen and Swish fibre servers).  I am unable to get those kind of results since I was taken off BT's backhaul from our exchange to Zen, and put onto Zen's own backhaul from our exchange to Zen.  The change is absolutely coincident with the very characteristic change in the ping graphs.

The average is clearly not the maximum speed of the product.  It's frequently possible to achieve in excess of the 900Mbps, and I have most of the time via those speed tests.  For it to be an average, unless everyone achieves bang-on 900Mbps, literally the definition of average means that some will be above 900Mbps to counterbalance those below, hence it could never be a maximum. If some are going to be achieving just 450mbps per the speed guarantee, for the average to hold, most will need to be above 900mbps.  For every one person at 450mbps you would need 45 people at 910mbps to hold an average of 900mbps (I was usually at 912 or 913mbps), or 22.5 people at 920mbps, or 450 people at 901mbps, etc etc.  You get the picture.

--

I'd be flabbergasted if it turned out to be a PON issue give that the change was coincident with the backhaul change and the visible step change in TBB graphs indicating some significant change in the network between me an the TBB servers thanks to that change.  Not only that, I'm pretty sure there is max one other person on this PON at the moment (I can see all the CBTs), and you'd be very unlucky for 1) that person to also be on 900mbps and 2) be constantly maxing out the connection.  Of course there are other PON possibilities like a rogue ONT on the PON, but again the circumstance of these changes just seems to make such things very unlikely causes.

[Alex Atkin UK]

Besides that, given a PON is 2.4Gbit down, I'd expect it to take three heavy users before PON congestion would even kick in at all.

[bogof]

Besides that, given a PON is 2.4Gbit down, I'd expect it to take three heavy users before PON congestion would even kick in at all.

Precisely.
Given that the performance varies so much depending on what gateway you end up on and what the PPPoE client is, it seems even less likely that the PON is implicated.
Anyway, I've kicked it back to Zen now.  Given they've instigated an obvious change on my account (witnessed by the silent order for the GEA migration) I've asked them to revert it or release me from the contract as the change has put me at "significant disadvantage" (words from their T&Cs).  We'll see which way that goes, but I can tell I'm at the moment just going to get progressively more frustrated by being asked to do the same tests over and over.  Might be shopping for a new provider soon.

[Alex Atkin UK]

Its really sad because we know mistakes happen and this seems to be beyond Zens control.  They could easily have turned this into a positive customer experience by offering alternatives quickly once they knew this was hitting more than one customer over more than one headend.

If they want to diagnose it then EVERYONE impacted needs to be offered either free service until its sorted (if the customer agrees), migrating back to a working backhaul (if the customer does not accept option 1) or as one person got, a second line fitting on alternative backhaul while the problem is investigated.

Expecting a customer to just "put up with it" while they investigate is really unacceptable.

[bogof]

Expecting a customer to just "put up with it" while they investigate is really unacceptable.

I don't want to over-egg it, as clearly my connection does seem to be functioning better I dare say than many.  I think from reading back in that TBB thread that the two main people there having issues they noted were much worse impacted than I am, which may mean they're not the same issue, or that this is just a less extreme version of what they see.  Either way, it looked like their services were well below the Zen minimum in many conditions, whereas mine for much / most of the time is above it.  Though as I said to the last person I spoke to on the phone; I don't think the minimum is a target above which all's good.  I don't think it's unreasonable to expect you should hit line rate sometimes.  Though I have some sympathy with the frontline staff as it sounds that unless I can show results consistently under the guarantee I get the feeling they're limited in what escalation they can do; it seems maybe if it was more broken I might have a greater chance of a timely resolution.

Just to give you an idea of the frustration, I rebooted the router yesterday, ended up on what I assume was a different gateway (I didn't note what I was on prior to reboot, but for future reference I note this one now is lo0-0.bng2.ixn-lon.zen.net.uk).  Instant more than +100Mbps on download results, and an obvious step change in the ping behaviour.



550Mbps vs 680Mbps in a speed test - neither is terrible, of course, but nor is it particularly good.

[Moderator edited to insert a blank line between the text and the image.]

[craigski]

Any thoughts folk? 

You You BQM says UDM, I assume Ubiquiti? This is running PPPoE on Linux, check what firewall settings you have, as it may not perform at full line speed using PPPoE, especially if you are running IPS etc.

https://community.ui.com/questions/ETA-on-bugfix-for-UDM-Pro-bad-PPPoE-performance/9119aa98-412f-41c7-9188-a30036c2e4c2

Maybe turn of some of the services on the UDM briefly and run speed test(s) again.

[bogof]

You You BQM says UDM, I assume Ubiquiti? This is running PPPoE on Linux, check what firewall settings you have, as it may not perform at full line speed using PPPoE, especially if you are running IPS etc.

https://community.ui.com/questions/ETA-on-bugfix-for-UDM-Pro-bad-PPPoE-performance/9119aa98-412f-41c7-9188-a30036c2e4c2

Maybe turn of some of the services on the UDM briefly and run speed test(s) again.

Thanks for the post & link.  The connection is currently on a Ubiquiti UDM Pro SE that I just acquired; prior it was on a Ubiquiti USG4Pro with IDS and smart queues disabled (that definitely does need those disabled to hit line rates).  The issues started with the previous router in place which was passing 900Mbps reliably prior to Zen's change - you seem to keep missing that point.  If you read a bit further above you can see I've done plenty of tests with Zen's own router, which were different but similar.

It's interesting that there are potentially issues in the UDM Pro with respect to PPPoE and throughput - I will investigate further, as it would be a shame to be overlaying one issue on another - though note that to many servers I do see well over 850Mbps with IDS on in the UDM Pro SE.  However, that doesn't explain the quite severe gateway variability, the issues observed with Zen's own router, or the step-change in performance that came in from the migration in the first place with the original USG4Pro.

I do see a small performance penalty with IDS on for the fastest of the speed test servers; disabling it sees some servers that are otherwise pegged around 860mpbs improve slightly up to line rate.  But rather oddly, it seems the Zen server gets slower with IDS turned off than with it turned on!  Almost as if something is "choking" upstream and the connection gets backed off too aggressively; but a small amount of extra latency is somehow helpful.

It seems absolutely repeatable - IDS on gains an inexplicable 50-60mbps speed test to Zen's server.

The more I look into it and put these strange observed quirks into my thinking, the more it seems to me that there is some kind of odd IP tuning issue going on, causing some connections to end up getting choked back, and it's very susceptible to the exact timing of bits arriving, hence the variation depending on which PPPoE client device you use, client options, gateway, etc.