That's my thinking..... I suppose it sort of comes under the heading 'slow speed' in terms of speed of the ping return time, but to my mind, it all gets confused with the routing via London/Manchester/Timbuktu discussion, which I don't really feel is related to the sort of speed issues we have been discussing. Anyway, let's see what transpires. Also, been thinking about the WiFi6 aspects of the AX router, can't really say it's going to make night and day difference to me, as I'm on the 500Mb plan, and honestly I already get 500Mb connections on WiFi, sure it'll be a tiny bit quicker to my internal servers etc, but won't change my life.

In reply to a post by S2KIP:

Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. untangle.chris.local 0.0% 49 2.9 1.5 0.3 11.6 1.8
2. lo0-0.bng2.ixn-lon.zen.net.uk 0.0% 49 13.8 17.1 11.9 37.4 5.8
3. lag-5.p2.ixn-lon.zen.net.uk 0.0% 49 12.8 13.2 11.4 17.6 1.2
4. lag-2.p2.thn-lon.zen.net.uk 0.0% 49 12.3 14.0 11.6 45.7 4.8
5. lag-2.br1.thn-lon.zen.net.uk 2.0% 49 12.0 15.1 11.9 62.1 8.2
6. ip81-59.fastly-gw1.lonap.net 0.0% 49 19.0 13.1 11.3 20.3 2.0
7. 151.101.192.81 0.0% 48 12.1 12.7 11.2 19.6 1.5


Zen clearly have some issues, it would be great to have some kind of official response on this.

Hard to phrase this without sounding harsh, tone doesn't translate well to text. What is the issue you think you are seeing on this MTR output?

Remember this is sending ICMP packet to the each of the devices in the path. Our network devices have protections to rate limit ICMP, and their main focus is transiting traffic through the router, not responding to ICMP requests. Similarly with latency, if the CPU is busy, it will deal with other things as a priority rather than providing timely responses to the ICMP.
Always examine the final hop along the route when analyzing MTR results. It is showing no loss, and good latency, this indicated to me that the network is performing well.

The BR1 router is one of our borders. These pass a lot of traffic and handle a lot of routing updates. Out of all our devices I'm least surprised to see it perform poorly to ICMP responses.

In reply to a post by hazey_flakes:

In reply to a post by S2KIP:

Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. untangle.chris.local 0.0% 49 2.9 1.5 0.3 11.6 1.8
2. lo0-0.bng2.ixn-lon.zen.net.uk 0.0% 49 13.8 17.1 11.9 37.4 5.8
3. lag-5.p2.ixn-lon.zen.net.uk 0.0% 49 12.8 13.2 11.4 17.6 1.2
4. lag-2.p2.thn-lon.zen.net.uk 0.0% 49 12.3 14.0 11.6 45.7 4.8
5. lag-2.br1.thn-lon.zen.net.uk 2.0% 49 12.0 15.1 11.9 62.1 8.2
6. ip81-59.fastly-gw1.lonap.net 0.0% 49 19.0 13.1 11.3 20.3 2.0
7. 151.101.192.81 0.0% 48 12.1 12.7 11.2 19.6 1.5


Zen clearly have some issues, it would be great to have some kind of official response on this.

Hard to phrase this without sounding harsh, tone doesn't translate well to text. What is the issue you think you are seeing on this MTR output?

Remember this is sending ICMP packet to the each of the devices in the path. Our network devices have protections to rate limit ICMP, and their main focus is transiting traffic through the router, not responding to ICMP requests. Similarly with latency, if the CPU is busy, it will deal with other things as a priority rather than providing timely responses to the ICMP.
Always examine the final hop along the route when analyzing MTR results. It is showing no loss, and good latency, this indicated to me that the network is performing well.

The BR1 router is one of our borders. These pass a lot of traffic and handle a lot of routing updates. Out of all our devices I'm least surprised to see it perform poorly to ICMP responses.

I know this and I know busy routers will drop ICMP.

However the above output, TBB, SmokePing etc outputs all show a significantly worse jitter and latency prior to GEA Migration.

My first hop latency has at least doubled since migration, in worse cases tripling depending on the gateway I hit.

Edited by S2KIP (Tue 05-Jul-22 15:45:39)

Host Loss% Snt Last Avg Best Wrst StDev
1. untangle.chris.local 0.0% 49 2.9 1.5 0.3 11.6 1.8

Just an observation, there's jitter on your first hop isn't there (0.3 -> 11.6 mS) doesn't that suggest the problem is closer to 'home'?

Only an observation!

In reply to a post by SteveBushell999:

Host Loss% Snt Last Avg Best Wrst StDev
1. untangle.chris.local 0.0% 49 2.9 1.5 0.3 11.6 1.8

Just an observation, there's jitter on your first hop isn't there (0.3 -> 11.6 mS) doesn't that suggest the problem is closer to 'home'?

Only an observation!

No, that could be all sorts of reasons.

If it was close to home, my issues wouldn't have started the exact time that the GEA migration was processed.

High Latency in the Beginning Hops

Seeing reported latency in the first few hops indicates a possible issue on the local network level. You will want to work with your local network administrator to verify and fix it.

See this link:How to Read a Traceroute I am only trying to help, but it looks like you may (coincidentally) have picked up a problem locally - Just suggesting it may be worth looking there.

In reply to a post by SteveBushell999:

High Latency in the Beginning Hops

Seeing reported latency in the first few hops indicates a possible issue on the local network level. You will want to work with your local network administrator to verify and fix it.

See this link:How to Read a Traceroute I am only trying to help, but it looks like you may (coincidentally) have picked up a problem locally - Just suggesting it may be worth looking there.

Thanks, but I know what I'm doing and I haven't picked up anything locally.

Already tested with different routers and dealing straight into the ONT.

My latency and jitter issue is wholly to do with the GEA migration and it's been over a week without any real update from Zen support.

Hitting one gateway in London and getting 24 ms and hitting another and getting 12ms (with added jitter) is a joke on FTTP when I used to get 5ms with zero jitter.

Remembering that pure speed of light equates to about 186 miles per millisecond, you'd expect 2mS extra latency due to speed of light for London (Round trip time), plus any router delay.

More like 124 miles per ms. Light travels slower in fibre than a vacuum. Carry on 😀

Mea culpa! The old" it takes longer not in a vacuum" (ie: in the REAL world)

But it really only makes the point stronger so 2mS becomes 2.5 - 3mS

On a more serious note, seems that S2KIP has some work to do looking at the local LAN

Host Loss% Snt Last Avg Best Wrst StDev
1. untangle.chris.local 0.0% 49 2.9 1.5 0.3 11.6 1.8

Looks (to me) like he's getting 1.5mS average, and 11.6 mS peak ping time to this local router, is he on WiFi perhaps?

Certainly if not, then something is seriously wrong, it would be interesting to see a ping run to his local router for 10 or so seconds, as it really should be sub 1mS constantly.

Edited by SteveBushell999 (Wed 06-Jul-22 09:41:03)

I had some fun last night. I built a couple of scripts that ran back to back speed tests for Zen and Swishfibre. One script was standalone so I could run it against the Fritzbox, the other fully automated the PPPoE connection from my W10 laptop that manages gigabit fine on it's built in LAN port.

I saw:
1) If I connect to a London gateway my latency to London services is better by around 10ms than a Manchester gateway. I'm in Norwich, to be expected I guess. It looks like I'm more likely to connect to London, but I did have a spell of 4 or 5 connections in a row that all ended up in Manchester.
2) If the W10 PPPoE connects to a Manchester gateway, the Zen speed tests are pretty poor and not very repeatable, but the Swish fibre ones get close to line speed. The W10 Swish speed results are a bit better on a Manchester gateway than a London one, though.
3) If the Fritzbox connects to a Manchester gateway, then it's Zen speed tests are about 200mbps better than they are on the London gateways. The Swish connections are basically line speed at that point.

All in all my conclusion at the moment is that there is clearly something a bit off with this all this, but I'm getting the sinking feeling from talking to the Zen staff that they hold a lot onto this minimum speed guarantee value and they're just not really going to push this through as although I can clearly see there are odd goings on, none of it falls below the service level expected.

As an engineer that really bugs me...