So....throttling...

[CJP]

Summary...

PCx2, plus a laptop, plus an Android device...

No device will download from this UK server at more than 3MB/s UNLESS I turn a VPN on. If I do, I download at expected rates. Other contributors, in US, Canada, and Australia have no issues.

I'm on my second router....so factory settings at least for the second one.

Three engineers, two from BT one from Openreach all see speeds are fine, route to Exchange is fine, but also witnessed this issue and can't explain it...because BT don't throttle.

Took laptop to my neighbour, same street, few doors down, also on BT, and we saw no issues whether VPN was on or off.

[Les-Gibson]

BT don't do throttling but, in all honesty, it's not to difficult to believe that 3 engineers got it wrong. You could request a new hub, that at least should give you a clue as to where the problem lays (e.g. in your home or with the network).

P.S. Sorry, I posted this before I saw message 31

[Keith_Beddoe]

If you have no upload speed, or very low upload speed, then that would be the cause of your problem.

What upload speed results do yo get if you run a speed test?

[CJP]

Maybe I misunderstood your question...

When I've been struggling to download, I've not been simultaneously uploading anything.

When I do upload, I always get the speed I expect. There's no issue with uploading at all...even when uploading to the server.

Thanks

[ptrduffy]

As @wkirkman and @licquorice have said, the only real way to understand what's happening here is with a traceroute.

Using a VPN creates a "tunnel" from your PC to the VPN server - regardless of their ultimate destination, your packets get sent to the VPN server first; when they emerge from the tunnel at the VPN server, normal internet routing takes over and they get sent to the destination.

So the key thing that the VPN is doing in this case is changing the route used by your packets.  A traceroute will show us that difference.

If you're using a Windows PC the command is 'tracert <destination>'; on a Mac it's 'traceroute <destination>'.  Post the results here and people will help interpret them.

Having said all that, if it is just a bad route, there's very little (probably nothing) you can do about it, and you're probably better off just continuing to use the VPN.

It's also possible that the Seafile transfer protocol (I'm not familiar with it) is latency-sensitive - some protocols require numerous back-and-forth exchanges of data between both ends to transfer data, so latency impacts their transfer rate quite badly.  You could check the latency on and off VPN with a 'ping' command.

[CJP]

Can't run a tracert to the server. I don't know why, just says, "Unable to resolve target system name". I am currently on the browser front page, however.

And remember that I am not seeing any issues when I am at my neighbours. A few doors down. Will be on same "wires" as we live in a cul de sac.

Does it matter that I get at least one "timeout" when tracert-ing bbc.co.uk? And some other asterisks, too?

Incidentally, it is the third "hop" and I just ran tracert for google.com, also timed out on third hop. 4th hop also timed out.

[ptrduffy]

The asterisks don't matter - just an intermediate router that isn't replying in time, either because it's busy or it's been configured to ignore those requests.

The "Unable to resolve target system name" is very strange, as it's a DNS error - but that should prevent anything on your PC from connecting to that destination (browser, Seafile etc.).

Can you 'ping' the destination server?

[CJP]

Actually, just managed to run tracert on the site's IP address.
Same sort of result as bbc and google.
3rd and 4th hops timed out.
Everything else looks fine....microseconds all less than 20 (except one at 23).

[CJP]

Incidentally, tracerts for bbc and google went through a route called "peer" and "ukcore.bt.net".

The seafile one didn't and instead went through gia.bt.net.

Saw this...from last year: https://community.bt.com/t5/BT-Fibre-broadband/Is-there-anyone-at-BT-who-can-take-a-report-of-an-iss...

Also ran 100xPING test with VPN on and off. Identical results. 0% packet lost, average 16ms.

[wkirkman]

As previously mentioned, if you used a Linux box to test and use a program called MTR (MyTraceRoute) it will show you if any packet loss and where it occurs on the route which was the purpose of suggesting it.

using windows is useless for this, as it is for most things I’ve found over the years.

i understand if you don’t have these immediately available or you don’t necessarily understand what is being shown, but that doesn’t mean it’s wrong, incorrect or not the course of action to take the troubleshoot the issue you have.