1753486 - H3 upload speed on the same computer (zero-ping) too slow

Status: UNCONFIRMED

(Core :: Networking: HTTP, defect, P2)

Description

[mcccs]

The server (my custom Golang code) and the browser are on the same computer:
Safari H/3: 130 MB/s
FF H/2: 150 MB/s
FF H/3: 30 MB/s

Profile: https://share.firefox.dev/3gi01wW

Comment 1

[mcccs]

OK, please ignore the original profile, with 0.1ms sample rate instead of 1ms the bottleneck is more evident.

I did the same test on the same computer this time on Linux instead of Mac. Got 30 MB/s again. It seems that something wasting CPU cycles causing the upload to slow down.

Linux: https://share.firefox.dev/3guQVg9

Mac: https://share.firefox.dev/3uyRq0W

"poll" on Linux and something without its symbol name in "mach_msg_trap" is using 94% of one core.

Comment 2

[Andre]

I would like to add on this, as I am having bad upload speeds with Firefox too. For comparison I took Chrome browser, which uses the available bandwidth in full.

When uploading a 10 GB file to YouTube:

Firefox upload time: 57 minutes
Chrome: 9 Minutes

So, there is a problem with HTTP3 in Firefox for sure. Note that disabling HTTP3 made the upload faster, but not on par with Chrome at all either (16 minutes for 10 GB).

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Could you share your server code if possible?

Comment 4

[mcccs]

Thank you for looking into this. https://github.com/DesWurstes/go-https-upload-speed main.go has setup instructions.

My previous machine 2015-i7 and I had concluded that CPU was the bottleneck. My new machine is M2-ARM which should be an order of magnitude faster. Safari & Chrome achieve the same speed, pointing to a different limitation. My FF upload increased from 30 to 50 (which could also be thanks to code updates) so the CPU is still the bottleneck after an upgrade, with the process reaching 100%.

New numbers:
Safari UL, Chrome UL, DL: 130 MB/s
Safari DL: 160 MB/S
Firefox UL: 50 MB/s
Firefox DL: 85 MB/s
Chrome and FF use the same cipher, ChaCha20, Safari not showing but probably the same.
Observe by using the tool that it makes no difference on average whether we use a 5MB file or a 1GB file, for both directions. Therefore using 5MB files would help simplify captures. Or even 2MB can be used.

Update: Enabling network.http.network_access_on_socket_process.enabled doesn't change the upload speed and now the socket process is 100%. So perhaps the problem is not the CPU

Comment 5

[mcccs]

By the way, I noticed that I had low-power mode enabled which reduces CPU frequency.

Without limited CPU speed:
(now file size does make a difference with varying CPU speed.)
Firefox UL

• 5MB: 60 MB/s
• 1GB: 80 MB/s
  Safari UL
• 5MB: 130 MB/s
• 1GB: 220 MB/s
  Chrome UL
• 5MB: 120 MB/s
• 1GB: 145 MB/s

As you can see 600megabits per second on the same device shows that there will be issues when remote. Would you like me to test on same-router computers as well?

Comment 6

[seriousbuggie]

Can confirm such bug. I even think browser use H2 and open new bug: #1842923

Current state: 100 Mbit channel, which allow max upload with 12.5 MB/s.
Firefox tested version: Nightly 111, 113, 114, 115
Firefox current version: 115.0.2
Windows: 7 SP1 x64
H2 upload: 12.5 MB/s (before 115 with network.http.http2.send-buffer-size = 512k, after with 0, see #1596576 )
H3 upload: 4 MB/s

Look like speed limited per domain. If I start upload to different domains, I can get 8 MB/s.

All H3 settings is default.

Comment 7

[Andrew Creskey [:acreskey]]

mcccs, seriousbuggie and anyone seeing this performance discrepancy:

In bug 1851908, we just introduced a preference named network.http.http3.cc_algorithm, which can be accessed through about:config. This preference exposes the congestion control algorithm employed for HTTP/3.

If you could test your scenario with our other congestion control algorithm, it would be appreciated:

Make sure you see the preference `network.http.http3.cc_algorithm` (Firefox Nightly 119 and onwards)
Measure the upload throughput while on the default setting (`1` for Cubic).
Modify this preference to `0` (indicating newReno).
Restart Firefox and measure the upload throughput again.

Comment 8

[seriousbuggie]

Unfortunately, I use Win7, so can't go beyond v115. You need help from other reporters.

Comment 9

[mcccs]

For my other bug report when server and client are on different machines, I retested it with smaller numbers, Firefox 30% faster and now on par with Chrome.

For this bug, on the same machine, Chrome H/3 maxes out to 1Gbps, Safari somehow does 2Gbps, FF alg 1 does 680mbps (but if I enable turbo boost: 1Gbps). Alg 0 does likewise (1Gbps likewise with Turbo boost)

So this isn't a flow control problem. But as I said, the new algo helped the other scenario.

For this problem, network.http.network_access_on_socket_process.enabled=true shows the socket process at 105% if turbo boost is enabled or not. Hence something is a CPU bottleneck. https://share.firefox.dev/3RnmhZY which isn't much different from my earlier profile, but from this I get the impression that one of the two macos libsystem functions is the bottleneck. __sendto or __select. Interestingly, I could reproduce this on linux as well, so it's not what the OS does but how firefox calls os, but I no longer use linux. I had included a Linux profile as well.