In reply to a post by jelv:

Could anyone make suggestions as to why this might be?

I wonder if it is worth raising with Mozilla/Firefox support somehow?

In reply to a post by bob_lucas:

The latest Firefox update has also changed other settings, with an adverse effect upon the result, when it prints graphics from a web page...

Firefox 86 seems to have redesigned printing. The windows printing bug causes a full crash (BSOD); so you would know if you suffered from this. (I believe MS has pushed a fix for this already).

This thread is fascinating, I can't test as Virgin Media don't support IPv6.

Edited by jchamier (Thu 18-Mar-21 12:25:11)

I don't experience the 50% reduction but I'm only on 40/10 so that doesn't necessarily help.
Tested using Firefox 86.0 (64-bit) on Lubuntu 20.04 on a wired connection over a Fritz!box 7530.

I would suggest it's unlikely to involve the router as for IPv6, it only needs to route at layer 3 (IP) rather than NAT where it needs to modify the source TCP port (and IP) on the way out, and match this established flow on the reply.
So other than any added firewall rules it does not need any awareness that it is even web traffic let alone which browser you are using.

On Firefox one troubleshooting step should involve creating a new profile with the defaults for that version and no add-ons (especially ones which do content filtering such as ad or tracker blockers).

On Windows some internet security products can cause traffic to appear as if processed more in bursts than at a steady rate; Kaspersky was one I would have to temporarily disable before network speedtests.

In the general case IPv6 tries to avoid fragmentation and makes that solely the responsibility of the endpoints to simplify the routers workload by not having to break up into / re-assemble from fragments on route.
This is combined with an increased of the minimum MTU from 576 to 1280, so even if an endpoint is unable to determine the PathMTU it can send at 1280 without fragmentation.
The % difference in overheads between 1280, 1400 (Cloudflare!) 1492 and 1500 is nowhere near enough to half the throughput so MTU can be dismissed without much consideration, unless you are tunneling IPv6 over IPv4 rather than native IPv6.

Edited by prlzx (Thu 18-Mar-21 13:08:51)

In reply to a post by jchamier:

In reply to a post by jelv:

Could anyone make suggestions as to why this might be?

I wonder if it is worth raising with Mozilla/Firefox support somehow?

Firefox support often involves quite a process of raising a bug through Bugzilla. There is a lot of unofficial help and support available through the Mozillazine Forums.

I think it's a Windows only issue.

In reply to a post by jelv:

I think it's a Windows only issue.

Mmm ok... Will get Andrew to take a look

I'm using Windows 10 1909 x64 with Firefox 86.0.1 (x64) and the upload is fine here. 20M up sync.



Downstream is a bit slow for 63M down sync, but eh. There are several devices attached at the moment.