Topic: Worse Zen FTTP 900 performance following GEA migration (Read 22903 times)

Alex Atkin UK · « **Reply #120 on:** August 20, 2022, 11:35:45 AM »

Quote from: craigski on August 20, 2022, 10:53:34 AM

Yep, I'm thinking same:
51.148.77.xxx is Zen backhaul
51.148.72.xxx is BTw backhaul

Maybe @Alex can confirm this, as he is still on BTw

Okay, nobody else online here right now so let's see if I can get some different gateways:
vt1.cor1.lond1.ptn.zen.net.uk (51.148.72.21) 7.827 ms 7.711 ms 7.968 ms
vt1.cor1.lond2.ptn.zen.net.uk (51.148.72.23) 6.990 ms 7.215 ms 7.339 ms
vt1.cor2.lond2.ptn.zen.net.uk (51.148.72.24) 8.027 ms 8.263 ms 8.226 ms
lo0-0.bng3.wh-man.zen.net.uk (51.148.77.130) 12.737 ms 12.720 ms 12.714 ms
lo0-0.bng4.wh-man.zen.net.uk (51.148.77.131) 3.260 ms 3.249 ms 3.242 ms

Gotta say I do not like that Manchester routing at all, its basically the same latency as London + Manchester on top to get to the Internet. I guess it kinda makes sense given I'm in Sheffield, its quite the detour.

Quote from: skyeci on August 20, 2022, 11:25:49 AM

I am still on btw with zen 900. My gateway currently gives 51.148.72.22 vt1.cor2.lond1.ptn.zen.net.uk

That's interesting as so far that seems the least likely gateway for me to hit, haven't been able to get it in my test just now.

skyeci · « **Reply #121 on:** August 20, 2022, 11:50:07 AM »

I find as soon as I reboot the box for an update or power loss etc I automatically revert to manchester, so if I manually force the connection on opnsense I can get back to london which gives me the best latency according to my gateway monitors both for ipv4 & 6

craigski · « **Reply #122 on:** August 20, 2022, 02:13:02 PM »

Quote from: bogof on August 20, 2022, 10:59:33 AM

Is that on FTTP900, and is that even to Zen's speedtest.net server?
Which of the gateways is fastest for you?

Yes, 900. No, not 'speedtest' estimates. You know my thoughts on those, you get your chosen server + 3 random servers, results are unreliable. I look at WAN port utilisation when downloading files, and/or use fast.com. The results on fast.com seem to align with WAN port utilisation.
lo0-0.bng2.ixn-lon.zen.net.uk [51.148.77.129] is fastest for me, but don't tell everyone.

Quote from: Alex Atkin UK on August 20, 2022, 11:35:45 AM

Okay, nobody else online here right now so let's see if I can get some different gateways:
vt1.cor1.lond1.ptn.zen.net.uk (51.148.72.21) 7.827 ms 7.711 ms 7.968 ms
vt1.cor1.lond2.ptn.zen.net.uk (51.148.72.23) 6.990 ms 7.215 ms 7.339 ms
vt1.cor2.lond2.ptn.zen.net.uk (51.148.72.24) 8.027 ms 8.263 ms 8.226 ms
lo0-0.bng3.wh-man.zen.net.uk (51.148.77.130) 12.737 ms 12.720 ms 12.714 ms
lo0-0.bng4.wh-man.zen.net.uk (51.148.77.131) 3.260 ms 3.249 ms 3.242 ms

Interesting you get 51.148.72.xx *AND* 51.148.77.xx

I only saw the 51.148.72.xx pre migration, now only 51.148.77.xx

Old presentation, but pages 3,4 & 5 "ISP Network Capacity 101" made me smile reading this

https://indico.uknof.org.uk/event/39/contributions/493/attachments/666/809/Building_for_Ultrafast.pdf

craigski · « **Reply #123 on:** August 20, 2022, 02:44:11 PM »

Just for kicks, I thought I would trace route the suspected BTw gateways @Alex listed from my connection via the .129:

vt1.cor1.lond1.ptn.zen.net.uk (51.148.72.21) 7.827 ms 7.711 ms 7.968 ms
vt1.cor1.lond2.ptn.zen.net.uk (51.148.72.23) 6.990 ms 7.215 ms 7.339 ms
vt1.cor2.lond2.ptn.zen.net.uk (51.148.72.24) 8.027 ms 8.263 ms 8.226 ms

From the above domain names, it suggests they are all in 'lon'don

routes are interesting from my connection via the lo0-0.bng2.ixn-lon.zen.net.uk [51.148.77.129] gateway, especially to the .23 & .24 gateways:

Tracing route to vt1.cor1.lond1.ptn.zen.net.uk [51.148.72.21]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router
2 6 ms 5 ms 5 ms lo0-0.bng2.ixn-lon.zen.net.uk [51.148.77.129]
3 5 ms 3 ms 4 ms lag-5.p2.ixn-lon.zen.net.uk [51.148.73.91]
4 4 ms 3 ms 4 ms lag-2.p2.thn-lon.zen.net.uk [51.148.73.138]
5 4 ms 4 ms 3 ms vt1.cor1.lond1.ptn.zen.net.uk [51.148.72.21]

Trace complete.

Tracing route to vt1.cor1.lond2.ptn.zen.net.uk [51.148.72.23]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router
2 6 ms 5 ms 3 ms lo0-0.bng2.ixn-lon.zen.net.uk [51.148.77.129]
3 5 ms 4 ms 4 ms lag-4.p1.ixn-lon.zen.net.uk [51.148.73.89]
4 5 ms 3 ms 4 ms lag-2.p1.thn-lon.zen.net.uk [51.148.73.132]
5 5 ms 2 ms 3 ms lag-8.pe1.thn-lon.zen.net.uk [51.148.73.149]
6 4 ms 3 ms 4 ms vl-50.lag-6.cr1.th-lon.zen.net.uk [51.148.73.57]
7 10 ms 9 ms 9 ms ae4-0.cr1.wh-man.zen.net.uk [62.3.80.46]
8 40 ms 10 ms 10 ms ae1-0.cr1.sp-roch.zen.net.uk [62.3.80.90]
9 10 ms 11 ms 9 ms ae7-0.ar3.sp-roch.zen.net.uk [62.3.81.230]
10 * * * Request timed out.
11 ^C

Tracing route to vt1.cor2.lond2.ptn.zen.net.uk [51.148.72.24]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router
2 7 ms 10 ms 6 ms lo0-0.bng2.ixn-lon.zen.net.uk [51.148.77.129]
3 10 ms 9 ms 9 ms lag-5.p2.ixn-lon.zen.net.uk [51.148.73.91]
4 11 ms 11 ms 9 ms lag-2.p1.wh-man.zen.net.uk [51.148.73.229]
5 10 ms 11 ms 10 ms lag-2.p2.sp-rch.zen.net.uk [51.148.73.135]
6 10 ms 10 ms 10 ms 51-148-73-223.dsl.zen.co.uk [51.148.73.223]
7 11 ms 9 ms 9 ms xe-3-1-0.cr2.sp-roch.zen.net.uk [51.148.73.61]
8 10 ms 10 ms 10 ms ae8-0.ar3.sp-roch.zen.net.uk [62.3.81.238]
9 * * * Request timed out.

Note the .23 & .24 are not responding to ICMP (for me at least), so not bothered about the request timedout.

bogof · « **Reply #124 on:** August 20, 2022, 03:56:19 PM »

I've certainly not seen the vtx.corx style gateways since being migrated.
Perhaps they are available only to non-GEA links, and the lo0.x style ones are available to both GEA and BTW links. I never had much cause to check which gateway I was on prior as my performance was always good.

As promised, here are all the gateways that respond to pings. I wonder what on earth it is that they're doing every 3hrs or so...

bogof · « **Reply #125 on:** August 20, 2022, 04:09:53 PM »

Quote from: craigski on August 20, 2022, 02:13:02 PM

Yes, 900. No, not 'speedtest' estimates. You know my thoughts on those, you get your chosen server + 3 random servers, results are unreliable. I look at WAN port utilisation when downloading files, and/or use fast.com. The results on fast.com seem to align with WAN port utilisation.
lo0-0.bng2.ixn-lon.zen.net.uk [51.148.77.129] is fastest for me, but don't tell everyone

If you use the command line speedtest application it doesn't behave as you mention - it only uses the server you request. You should try it and we can stop having this conversation...

The speedtest website also tends to only do that 3 servers thing if you let it do what it wants when you open the site. If you manually select a server it tends to only use that one. But I digress, just use the command line tool. You can download it https://www.speedtest.net/apps/cli for windows and many other OSes (I even have the arm Linux binaries running on my router).

But it's all much clearer now. You're basically telling me what I see is the normal because you've tested it recently and you happen to have one of the same sub-par connections I have... gotcha.

Maybe you didn't test much pre-migration and don't know the extent of what you're missing...

My understanding is that most people with well specified client devices and well performing networks on FTTP900 connections DO regularly get >900Mbps with most of speedtest.net and other services without having to resort to trying to load up multiple connections and different applications etc, gateway hop, etc. This is a significantly different position to what you take, and it seems what is informing your position is the testing you are doing on your own line... and not knowledge of how other FTTP900 lines perform.

craigski · « **Reply #126 on:** August 20, 2022, 05:04:48 PM »

Quote from: bogof on August 20, 2022, 04:09:53 PM

You should try it and we can stop having this conversation...

The plot thickens....

OK, just for you I tried speedtest.net CLI, I assume to server 40788 Zen Internet London?

CLI says 556.64Mbps down

Then I tried speedtest.net from browser on same PC, selecting same server, immediately after the CLI test finished.

Browser GUI (Chrome) says 926.08Mbps down

I then repeated 5 minutes later:

CLI: 578.21Mbps down
GUI: 927.14 Mbps down

Then just for kicks,
fast.com: 800Mbs
BTw: 922Mbps

Then I look at the max utilisation on my router WAN ethernet port for the duration of the above:

915,602kbps

Is my connection sub par, or are the 'speedtests' sub par? Thoughts?

bogof · « **Reply #127 on:** August 20, 2022, 05:47:08 PM »

Quote from: craigski on August 20, 2022, 05:04:48 PM

Is my connection sub par, or are the 'speedtests' sub par? Thoughts?

If you try some of the other servers I'm sure you'll find there's nothing "wrong" per se with the speedtest CLI tool itself, and that you can hit close to line rate with other servers...
You could try 9060, which is a server from Voicehost Norwich which is only on a 1G connection itself from what I can see.
So at that point - and given the Zen server via that binary on a suitably capable connection can hit 10G - the logical conclusion is a difference in how that app hits the network resulting in lower throughput on a somehow "different" connection. Exactly in what way the connection is "different" is as yet unknown.

bogof · « **Reply #128 on:** August 20, 2022, 11:15:14 PM »

Quote from: Alex Atkin UK on July 19, 2022, 11:23:14 PM

The GEA problem sure, but if its there is a single-threaded performance problem on other backhauls, that changes things a bit.

I do wonder still about whether some of the differences seen on various speed testers and servers ends up significantly related to single thread performance.

For instance, if a certain speedtest app only uses, say, 4 connections, and 4 connections along a given route maxes out at a total of x throughput, then that would result in a speedtest of x.
If another server single threaded route is much more capable, then you may see much higher performance. Further more, this may explain differences between different apps / web pages targeting the same servers if the apps have a different threading strategy.

I noted this with Zen's speedtest server vs the Voicehost one earlier. Via the web, the Zen speedtest server was only allowing me around 200Mbps, whereas the Voicehost Norwich one was doing single threads at 800Mbps.

Digging into this a bit more from the command line, where I'm happier, axel is a multithreaded capable HTTP downloader. Using different numbers of threads to download big TBB test file:
01 = 38MB/sec.
03 = 50MB/sec.
05 = 59MB/sec.
10 = 71MB/sec.
20 = 80MB/sec.
30 = 88MB/sec.
40 = 93MB/sec.
I was surprised by the almost unfeasibly large number of connections required to approach line rate here.

(Command line used is (where -n 40 is 40 connections):

Code: [Select]

rm 512MB.zip ; time axel -U Chrome -n 40 -v -a -o 512MB.zip http://ipv4.download.thinkbroadband.com/512MB.zip

I saw your point earlier that this is fine as web browsers are generally multithread. Of course, not everything can be multithreaded (eg VPN connections).

Interesting to see how variable it is. For example, I often get single threaded connections to this Ubuntu download link via axel at 83MB/sec:

Code: [Select]

 rm bigfile ; time axel -n 1 -v -a -o bigfile https://releases.ubuntu.com/22.04.1/ubuntu-22.04.1-desktop-amd64.iso?_ga=2.63790191.1176441848.1661034061-697000926.1661034061

(The TBB downloads appear to need a webbrowser useragent to download, but most others are fine with Axel providing it's own useragent, hence the difference in the commandlines above).

Alex Atkin UK · « **Reply #129 on:** August 20, 2022, 11:39:06 PM »

My experience seems to be very different, right now at least:

Code: [Select]

wget http://ipv4.download.thinkbroadband.com/512MB.zip
--2022-08-20 23:53:03--  http://ipv4.download.thinkbroadband.com/512MB.zip
Resolving ipv4.download.thinkbroadband.com (ipv4.download.thinkbroadband.com)... 80.249.99.148
Connecting to ipv4.download.thinkbroadband.com (ipv4.download.thinkbroadband.com)|80.249.99.148|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 536870912 (512M) [application/zip]
Saving to: ‘512MB.zip.1’

512MB.zip.1                                        100%[================================================================================================================>] 512.00M   109MB/s    in 4.8s    

2022-08-20 23:53:08 (107 MB/s) - ‘512MB.zip.1’ saved [536870912/536870912]

Code: [Select]

rm 512MB.zip ; time axel -U Chrome -n 1 -v -a -o 512MB.zip http://ipv4.download.thinkbroadband.com/512MB.zip
Initializing download: http://ipv4.download.thinkbroadband.com/512MB.zip
File size: 512 Megabyte(s) (536870912 bytes)
Opening output file 512MB.zip
Starting download

[100%] [...] [ 104.7MB/s] [00:00]

Downloaded 512 Megabyte(s) in 4 second(s). (107259.86 KB/s)

real    0m4.904s
user    0m0.127s
sys     0m0.533s

Code: [Select]

rm 512MB.zip ; time axel -U Chrome -n 4 -v -a -o 512MB.zip http://ipv4.download.thinkbroadband.com/512MB.zip
rm: cannot remove '512MB.zip': No such file or directory
Initializing download: http://ipv4.download.thinkbroadband.com/512MB.zip
File size: 512 Megabyte(s) (536870912 bytes)
Opening output file 512MB.zip
Starting download

[100%] [...] [ 105.1MB/s] [00:00]

Downloaded 512 Megabyte(s) in 4 second(s). (107589.71 KB/s)

real    0m5.195s
user    0m0.093s
sys     0m0.516s

Code: [Select]

traceroute to ipv4.download.thinkbroadband.com (80.249.99.148), 30 hops max, 60 byte packets
 1  vt1.cor1.lond2.ptn.zen.net.uk (51.148.72.23)  7.118 ms  7.210 ms  6.982 ms
 2  lag-8.p2.ixn-lon.zen.net.uk (51.148.73.206)  7.063 ms  7.057 ms  7.051 ms
 3  lag-2.p2.thn-lon.zen.net.uk (51.148.73.138)  7.099 ms  7.170 ms lag-2.p1.thn-lon.zen.net.uk (51.148.73.132)  7.101 ms
 4  lag-1.br1.thn-lon.zen.net.uk (51.148.73.153)  7.058 ms  7.052 ms  7.046 ms
 5  netconnex-gw.zen.net.uk (82.71.254.2)  6.740 ms  6.734 ms  6.847 ms
 6  ae11-11.edge-rt5.thdo.ncuk.net (80.249.97.21)  6.536 ms  6.681 ms  6.497 ms

bogof · « **Reply #130 on:** August 20, 2022, 11:54:28 PM »

Quote from: Alex Atkin UK on August 20, 2022, 11:39:06 PM

My experience seems to be very different, right now at least:

Code: [Select]
rm 512MB.zip ; time axel -U Chrome -n 1 -v -a -o 512MB.zip http://ipv4.download.thinkbroadband.com/512MB.zip Initializing download: http://ipv4.download.thinkbroadband.com/512MB.zip File size: 512 Megabyte(s) (536870912 bytes) Opening output file 512MB.zip Starting download [100%] [...] [ 98.9MB/s] [00:00] Downloaded 512 Megabyte(s) in 5 second(s). (101227.50 KB/s) real 0m4.950s user 0m0.147s sys 0m0.657s
Code: [Select]
rm 512MB.zip ; time axel -U Chrome -n 4 -v -a -o 512MB.zip http://ipv4.download.thinkbroadband.com/512MB.zip rm: cannot remove '512MB.zip': No such file or directory Initializing download: http://ipv4.download.thinkbroadband.com/512MB.zip File size: 512 Megabyte(s) (536870912 bytes) Opening output file 512MB.zip Starting download [100%] [...] [ 105.1MB/s] [00:00] Downloaded 512 Megabyte(s) in 4 second(s). (107589.71 KB/s) real 0m5.195s user 0m0.093s sys 0m0.516s
Code: [Select]
traceroute to ipv4.download.thinkbroadband.com (80.249.99.148), 30 hops max, 60 byte packets 1 vt1.cor1.lond2.ptn.zen.net.uk (51.148.72.23) 7.118 ms 7.210 ms 6.982 ms 2 lag-8.p2.ixn-lon.zen.net.uk (51.148.73.206) 7.063 ms 7.057 ms 7.051 ms 3 lag-2.p2.thn-lon.zen.net.uk (51.148.73.138) 7.099 ms 7.170 ms lag-2.p1.thn-lon.zen.net.uk (51.148.73.132) 7.101 ms 4 lag-1.br1.thn-lon.zen.net.uk (51.148.73.153) 7.058 ms 7.052 ms 7.046 ms 5 netconnex-gw.zen.net.uk (82.71.254.2) 6.740 ms 6.734 ms 6.847 ms 6 ae11-11.edge-rt5.thdo.ncuk.net (80.249.97.21) 6.536 ms 6.681 ms 6.497 ms

Very interesting that our single thread performance is so different there to the same site... I'm only getting 34MB/s now for a single thread.

My traceroute below. There is double-NAT at the moment for this box as the fritzbox is in the way; of course it is possible that is having some effect, though doubtful as the Ubuntu image file single thread can almost max out the connection. Seems like some large variability in single thread performance.

Our egress from Zen's network is the same place, which would imply the bottlenecks are within Zen's network...

Code: [Select]

traceroute to ipv4.download.thinkbroadband.com (80.249.99.148), 30 hops max, 60 byte packets
 1  192.168.178.1 (192.168.178.1)  0.378 ms  0.484 ms  0.492 ms
 2  lo0-0.bng4.thn-lon.zen.net.uk (51.148.77.132)  6.691 ms  11.386 ms  11.384 ms
 3  lag-14.p1.thn-lon.zen.net.uk (51.148.73.94)  8.993 ms lag-14.p2.thn-lon.zen.net.uk (51.148.73.96)  8.760 ms  8.753 ms
 4  lag-2.br1.thn-lon.zen.net.uk (51.148.73.167)  8.684 ms lag-1.br1.thn-lon.zen.net.uk (51.148.73.153)  6.694 ms lag-2.br1.thn-lon.zen.net.uk (51.148.73.167)  6.464 ms
 5  netconnex-gw.zen.net.uk (82.71.254.2)  6.499 ms  6.493 ms  6.486 ms
 6  ae11-11.edge-rt5.thdo.ncuk.net (80.249.97.21)  6.650 ms  6.249 ms  6.156 ms

bogof · « **Reply #131 on:** August 21, 2022, 12:18:04 AM »

Slackware image from UK server downloads at almost line rate single thread:

Code: [Select]

root@Home-Dream-Machine-SE:/ssd1/test# rm bigfile ; time axel -n 1 -v -a -o bigfile http://slackware.uk/slackware/slackware-iso/slackware64-15.0-iso/slackware64-15.0-install-dvd.iso
Initializing download: http://slackware.uk/slackware/slackware-iso/slackware64-15.0-iso/slackware64-15.0-install-dvd.iso
File size: 3780542464 bytes
State file found, but no downloaded data. Starting from scratch.
Opening output file bigfile
Starting download

[100%] [.............................................................................................] [ 100.8MB/s] [00:00]

Downloaded 3.5 Gigabyte in 35 seconds. (103227.12 KB/s)

real    0m35.782s
user    0m5.759s
sys     0m24.417s

That traceroute:

Code: [Select]

 1  192.168.178.1 (192.168.178.1)  0.388 ms  0.397 ms  0.465 ms
 2  lo0-0.bng4.thn-lon.zen.net.uk (51.148.77.132)  20.160 ms  20.180 ms  20.173 ms
 3  lag-14.p1.thn-lon.zen.net.uk (51.148.73.94)  7.286 ms lag-14.p2.thn-lon.zen.net.uk (51.148.73.96)  9.621 ms lag-14.p1hn-lon.zen.net.uk (51.148.73.94)  7.303 ms
 4  lag-2.br1.thn-lon.zen.net.uk (51.148.73.167)  7.094 ms  7.021 ms  7.069 ms
 5  linx-226.as13213.net (195.66.236.19)  7.172 ms  7.164 ms  9.638 ms
 6  no-ptr.midphase.com (98.158.181.92)  9.479 ms  9.107 ms  9.053 ms
 7  * 212.78.92.1 (212.78.92.1)  5.041 ms  5.019 ms
 8  * * *
 9  * * *
10  fry.opensourcerers.net (212.78.94.73)  5.067 ms  5.013 ms  5.037 ms
11  * * *
12  * * *
13  * * *

So why are you able to download single thread from TBB at line rate while I can't, and yet I can clearly achieve line rate single thread to this Slackware server? Sounds like some bottlenecks somewhere in Zen for sure.

Alex Atkin UK · « **Reply #132 on:** August 21, 2022, 12:18:20 AM »

Quote from: bogof on August 20, 2022, 11:54:28 PM

Our egress from Zen's network is the same place, which would imply the bottlenecks are within Zen's network...

Wish I could say I was surprised, but even though my connection is fine my opinion of Zen has taken a nose dive seeing how they do not care that people randomly end up via Manchester and in some cases doubling latency, plus this GEA issue. A well managed network should not have huge variances like this.

bogof · « **Reply #133 on:** August 21, 2022, 01:21:20 AM »

Quote from: Alex Atkin UK on August 21, 2022, 12:18:20 AM

Wish I could say I was surprised, but even though my connection is fine my opinion of Zen has taken a nose dive seeing how they do not care that people randomly end up via Manchester and in some cases doubling latency, plus this GEA issue. A well managed network should not have huge variances like this.

Indeed.
It's all a bit odd though. We're coming out of the same netconnex-gw.zen.net.uk to get to TBB, yet when I download the slackware image the traceroute is the same until the hop where it goes from lag-2.br1.thn-lon.zen.net.uk to linx-226.as13213.net. You are getting to TBB from netconnex-gw.zen.net.uk too, which implies the issue is in the connectivity perhaps between lag-2.br1.thn-lon.zen.net.uk and netconnex-gw.zen.net.uk.

Traceroute to the speedtest.net Zen server is:

Code: [Select]

traceroute to speedtest02a.web.zen.net.uk (51.148.82.21), 30 hops max, 60 byte packets
 1  192.168.178.1 (192.168.178.1)  0.374 ms  0.475 ms  0.517 ms
 2  lo0-0.bng4.thn-lon.zen.net.uk (51.148.77.132)  26.819 ms  26.850 ms  26.845 ms
 3  lag-14.p1.thn-lon.zen.net.uk (51.148.73.94)  6.371 ms  6.328 ms  6.340 ms
 4  lag-2.p1.ixn-lon.zen.net.uk (51.148.73.133)  6.192 ms lag-2.p2.ixn-lon.zen.net.uk (51.148.73.139)  8.857 ms  8.857 ms
 5  lag-2.br1.ixn-lon.zen.net.uk (51.148.73.195)  8.634 ms  8.672 ms  8.628 ms
 6  * * *

Yet there are obviously at least some good links between the THN and IXN locations as you're fast download to TBB is at single thread is crossing that boundary.

What's most useful I guess is building an armoury of testing ideas to try before and after the migration. Will be really interesting to see if anything changes for me.

Have you tried picking up one of the lo0-0.bng gateways like I'm on (I guess ideally 4) and seeing how those single thread web download tests perform? That would be quite interesting to see if your single thread falls off the cliff then...

Alex Atkin UK · « **Reply #134 on:** August 21, 2022, 03:10:32 AM »

Quote from: bogof on August 21, 2022, 01:21:20 AM

Have you tried picking up one of the lo0-0.bng gateways like I'm on (I guess ideally 4) and seeing how those single thread web download tests perform? That would be quite interesting to see if your single thread falls off the cliff then...

I tried reconnecting about 10 times or so and only got the gateways I mentioned earlier. Can't really sit reconnecting PPP all day, unless I move the FTTP to a PC and leave mum on the Three 5G - as every reconnect of PPP restarts the firewall which takes a minute or so to adjust. I only did the earlier tests as she was asleep.

News:

Author Topic: Worse Zen FTTP 900 performance following GEA migration (Read 22903 times)

Alex Atkin UK

Re: Worse Zen FTTP 900 performance following GEA migration

skyeci

Re: Worse Zen FTTP 900 performance following GEA migration

craigski

Re: Worse Zen FTTP 900 performance following GEA migration

craigski

Re: Worse Zen FTTP 900 performance following GEA migration

bogof

Re: Worse Zen FTTP 900 performance following GEA migration

bogof

Re: Worse Zen FTTP 900 performance following GEA migration

craigski

Re: Worse Zen FTTP 900 performance following GEA migration

bogof

Re: Worse Zen FTTP 900 performance following GEA migration

bogof

Re: Worse Zen FTTP 900 performance following GEA migration

Alex Atkin UK

Re: Worse Zen FTTP 900 performance following GEA migration

bogof

Re: Worse Zen FTTP 900 performance following GEA migration

bogof

Re: Worse Zen FTTP 900 performance following GEA migration

Alex Atkin UK

Re: Worse Zen FTTP 900 performance following GEA migration

bogof

Re: Worse Zen FTTP 900 performance following GEA migration

Alex Atkin UK

Re: Worse Zen FTTP 900 performance following GEA migration