I'm working on an project to solve this type of issue. What we do is put test servers throughout your provider's network and then provide a browser frontend that will test your connection (throughput+latency) to each point on your provider's network on your way out to the Internet. I would love to come up with a way to do this without requiring the provider to install anything, but so far that doesn't seem technically feasible. One of the main problems is that so much of last mile networks is now layer 2, so traceroutes aren't particularly helpful at narrowing down the network segment causing the problem.

The good news is that many of the smaller providers (where they exist - maybe your LTE provider is one?) are very excited about adding something like this to their network. Where the incumbents would rather just hide problems from you to keep you locked in, the smaller providers are very motivated to keep you on their network. They're often overworked and resource strapped - so a system that will help them narrow down the source of network problems and reduce truck rolls is usually very exciting to them.

Latency is largely irrelevant to one-way video streaming (at least until it's so high it affects throughput), and since Netflix designed this to test your speed for their one-way video streaming service I think leaving out latency testing is reasonable.

Latency is critically important...

You can easily determine how much of a problem it is in your case by calculating your bandwidth delay product: https://en.wikipedia.org/wiki/Bandwidth-delay_product

In the real world TCP window scaling solves latency induced delays for video streaming in all but the most extreme cases (hence my caveat), and endpoint buffering can solve even those.

For many activities on the internet a 1,000ms latency would be intolerable, but for one-way video streaming it's unnoticeable to the end user. I don't really care if a packet containing video takes 50ms or 1000ms to get from the CDN to my TV, as long as it gets there and is reasonably consistent in it's ability to do so.

For this use case, if my machine can get 20Mb/s on the test, latency will just not affect me streaming a 10Mb/s video. Latency may be lowering my test results, but that's the point here - testing the effective throughput.

Sounds like bufferbloat to me. Tried using smart queue management like fq_codel on your end? Or is it an overloaded LTE cell?

Not sure if bufferbloat, but happens across multiple machines and system versions (I can saturate the link with one machine, the others will still suffer). But it may be an issue with the LTE router. I don't think I can do anything about it as it is totally locked down by the ISP.

I'm largely using LTE these days for network access instead of wired and I have not yet encountered significant latency problems. You have a higher latency out of the box but it seems very stable. However LTE does QoS on a per device situation and it might be that the tower downgrades you if your link is not good enough.