Print

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

[bogof]

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.

Maybe you are quite unlikely to pick up those lo0.bng gateways with your connection for some reason, be that BTW Vs GEA Zen, orgeography, or whatever.  We know there is some difference at least in the configuration of the vtx.blah gateways as they don't respond to ping echo requests.  I guess there is possibility either the gateways themselves or the link to the lo0.bng gateways from GEA links, or the gateway itself alone does something to the traffic that negatively impacts single thread performance to some locations.

If with your current gateway that is downloading fast single thread from TBB large files you choose single threaded speedtest.net from Zen's server, do you see good performance?

I wonder if the time previous in this thread where you had poor single thread performance you happened to be on one of the lo0.bng gateways.

BTW thanks for the testing, certainly don't inconvenience yourself or family on my behalf, it was only if you were finding this puzzle as interesting as me that I figure you might find time to look

[craigski]

Yes, thanks both for additional testing. You have re-confirmed to me that 'speedtests' can not be relied on.

What's important (to me), is that I can do something useful like drive my car 70 miles in 1 hour (ie I know I've travelled 70mph) , rather than constant tinkering with multiple unreliable speedo's fitted to the car that all say something different (ie none of them say 70mph).

I'm going to take a back seat now in this car, but still genuinely interested from an academic point of view on how you get on in the front seat tinkering your speedo's.

[bogof]

Yes, thanks both for additional testing. You have re-confirmed to me that 'speedtests' can not be relied on.

What's important (to me), is that I can do something useful like drive my car 70 miles in 1 hour (ie I know I've travelled 70mph) , rather than constant tinkering with multiple unreliable speedo's fitted to the car that all say something different (ie none of them say 70mph).

I'm going to take a back seat now in this car, but still genuinely interested from an academic point of view on how you get on in the front seat tinkering your speedo's.

Thanks for your testing, too.

I do think your analogies are a bit of a bust though, at least based on the testing I've done compared to Alex's.
It seems there is some big difference in single threaded performance to different places that I'm seeing that he isn't with current GW, whereas to some places I don't see a limitation, which obviously shows that at least the connection leaving my house to some point in the world is unconstrained.

So to take a car analogy to the extreme.  That's a bit like saying this car will do 70mph* (* 70miles travelled per hour can only be achieved spread across 5 passengers when travelling across destinations which start with a consonant, actual road speed achieved in such situations is 14mph).   You can see that depending on your requirements these can be important differences...

I don't think anyone is "relying" on speedtesters.  The different speedtester programs and servers seem to offer some insight into differences between connections that you wouldn't get if they all behaved the same and started massive numbers of threads to maximise a connection.  You might say the speed testers are somehow not functioning, I'd say they're indicative of a particular performance metric in a particular test setup, and it's unlikely the tester itself is inaccurate per se in what it is measuring.  That is unless you are assuming the tester is guaranteed to be telling you how fast your broadband is.  It's not, it's telling you how fast you can do a certain thing with your broadband.  You then have to relate that back to real world and what that means.

The single threaded difference between what Alex is seeing on the TBB file download and what I'm seeing, while I can achieve line rate single threaded to certain locations, seems to be one of the more significant smoking guns here, given there have been grumblings over single thread issues with Zen's network for quite a while that never really seem to get to resolution.  Having to use 40(!) connections to approach line rate to that TBB server is just ludicrous.  What's up with that?!

[Chrysalis]

Does anyone here know if there is a cityfibre backhaul option on Zen CF FTTP?

[skyeci]

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.

hi bogof

I ran all the same tests tonight on my zen 900 using the same gateway as Alex -all the tests are the same throughput wise apart from the single thread on tbb. I am somewhere between 550-680, can't get anywhere over that. I asked zen about this a few months ago as I noticed my single thread tests didn't seem that good when my other tests hit full speed etc. They told me it wasn't a problem but I'm not convinced. I am still on btw connection.

[bogof]

I ran all the same tests tonight on my zen 900 using the same gateway as Alex -all the tests are the same throughput wise apart from the single thread on tbb. I am somewhere between 550-680, can't get anywhere over that. I asked zen about this a few months ago as I noticed my single thread tests didn't seem that good when my other tests hit full speed etc. They told me it wasn't a problem but I'm not convinced. I am still on btw connection.

Thanks.  I wonder if Alex's is still performing that well.  Of course I'm using the Zen 7530 still as a PPPoE client, I wonder how / if things will change with that swapped out.
And since they put in the Samknows box I haven't done a tour of the various gateways I can get to, which would be interesting to run these tests against.

[Alex Atkin UK]

I am somewhere between 550-680, can't get anywhere over that.

That's what I was getting too prior to those last tests, still seems to be going full speed at the moment.

To be honest, I don't think TBB test files ever went full speed on Zen before even on FTTC.

[bogof]

Getting migrated tomorrow, will be interesting to see how that goes.

Zen billing have been below par really; I had an email telling me I'd have to pay a cancellation, then an invoice for said cancellation, then a notice of direct debit for that cancellation amount.  Today I finally got someone to sort it out it seems and confirm it's not going to get taken out of my account (it was hundreds of pounds).

Have the login for the Samknows box now, it's interesting to look at the results.  See below for a few of the traces. 

[bogof]

Well, that went well... PPPoE died at 1am and hasn't come back since, failing to authenticate.   LOS on ONT still good,  We shall see if it comes back up.  Does anyone know of any test account details etc that it's possible to use on an FTTP connection?

Edit: seems Zen can see my connection coming in over BTW now, but there is an issue at Zen's end with the radius setup which is preventing login.  Hopefully to be resolved soon...

[bogof]

...and it's back.  Radius now back working.

And surprise! all speedtest.net test sites back up to line rate now...  Latency slightly increased by a ms or 2, which is also where it was pre-migration.  Single threaded command line download from TBB now up at over 80Mb/sec:

root@Home-Dream-Machine-SE:/ssd1/test# rm 512MB.zip ; time axel -U Chrome -n 1 -v -a -o 512MB.zip http://ipv4.download.thinkbroadband.com:81/512MB.zip
Initializing download: http://ipv4.download.thinkbroadband.com:81/512MB.zip
File size: 536870912 bytes
State file found, but no downloaded data. Starting from scratch.
Opening output file 512MB.zip
Starting download

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

Downloaded 512.0 Megabyte in 6 seconds. (82306.84 KB/s)

Will be interesting to see what the Samknows box collects up.
Will share some more results later.

Make of this what you will with respect to opinions on Zen's own network (at least around here - maybe it's a local issue, maybe not).  At least for me, they were not hitting the mark of what I expected.  I'm glad to be back up at full speed for now.

Gateway has now switched to vt1.cor2.lond1.ptn.zen.net.uk (51.148.72.22) (I guess as expected).

[bogof]

What a difference a day makes...
I can stop thinking I'm imagining it now, and that somehow the issue is either me or my network gear.

[burakkucat]

This is a topic that seems to go on and on.    As it is now on page 10, I had to review what was on page 1 to see how it started.   

Your opening post ended with the question --

https://forums.thinkbroadband.com/zen/t/4709246-slow-speed-after-gea-migration.html

Any thoughts folk?

To which I responded in Reply #1 --

I had completely forgotten about that TBB forum thread and so had another three pages of posts to read through. Phew! 

My only thought is "currently avoid Zen".

I think my only thought, from back then, is still, unfortunately, appropriate. 

[Alex Atkin UK]

Its really sad, given having their own network was supposed to improve performance not downgrade it.  But then it was kinda hard to accept they know what they are doing when they continue with the Manchester/London dance.

I totally understanding having some diversity in the network, but putting people on a detour should not happen unless the other links are completely congested (which should never happen regularly if managed well) or down entirely.

[bogof]

Indeed to all that.  Though in fairness I've at least been able to talk to people who've ultimately got the job done, I do worry about the underlying technical quality of their service.  And if you're buying Zen today in Norwich at least I guess there's a reasonable chance you're getting short-changed vs what you should be able to expect reasonably from these services - as I'd imagine new users will be put straight onto the GEA service, and assume at least some proportion of those will see these issues (that's with maximum benefit of the doubt that these issues aren't wider spread).

This is a more interesting page out of the Samknows UI.  The Samknows multithreaded test didn't actually seem that sensitive to the issue seen (the difference is only 100Mbps or so on average) but there is a Netflix test that is also scheduled, which downloads from Netflix servers.

There is large variability and generally poor performance from that set of test servers, really only just sliding along around the minimum speed guarantee level on average.  See what happened to it once moved back over to BTW, straight back up to 890Mbps.

I'm going to leave the network as it is for the next week or so to collect some good stats via the Fritzbox, before moving back to the Ubiquiti gear doing all the routing and PPPoE.  Will report back.

[Alex Atkin UK]

Its certainly a long-term problem they need to solve as I was under the impression Zen were planning to ultimately cover all head-ends with their own infrastructure.