Maximum transfer speed of 30 MB/s, even on same device?

[josephrocca]

Hi, really cool project!

Context:

If I create a dummy 10G file like this:

fallocate -l 10G dummyfile

and then open two browser tabs on the same device, the transfer takes about 5 minutes - i.e. it averages 30 MB/s. This surprised me, because my internet connection has 100MB/s, and I can e.g. download this ~10GB file from Hugging Face in less than 2 mins.

Question:

I'm wondering if this is a fundamental limitation of WebRTC, or if there are potentially very significant performance optimisations which could be made to e.g. get to hundreds of MB/s or several GB/s. I'd have expected at least hundreds of MB/s for two browser tabs on the same device.

[josephrocca]

Related: https://stackoverflow.com/questions/61280860/do-browser-engines-limit-webrtc-speeds

I've also just tested instant.io (which uses WebTorrent, which uses WebRTC) and I'm not able to get more than 30 MB/s even with multiple seeding peers. Although all my peers were on the same network - not sure whether that could be limiting it.

[josephrocca]

I've just created a very simple WebRTC DataChannel speed test, and it does indeed look like it won't go higher than 30 MB/s even with unordered, and no retransmission of lost data:

• https://webrtc-data-channel-speed-test.glitch.me/
• https://glitch.com/edit/#!/webrtc-data-channel-speed-test

[szimek]

Thanks for looking into it! I don't know if there is a limit, and if yes, what it is.

This app uses a very primitive "protocol", especially that it was written before some new WebRTC features became available. The way it works is the following:

1. sender reads a 1MB chunk from a file
2. sender sends this chunk to the recipient
3. recipient receives the chunk
4. unless it was the last chunk, the recipient sends a message to request the next one and the whole process is repeated

There are a few optimizations possible:

• the sender could read the next chunk before it's requested from the recipient, to have it ready by then
• the sender could use buffering to keep sending data as long as the buffered amount is low enough, instead of sending of waiting for the recipient to acknowledge each chunk
• the chunk size is 1MB, though it's recommended that the message size be 64KB

I don't know if any of these would actually have a significant impact, though.

[josephrocca]

I've posted an issue on crbug here: https://bugs.chromium.org/p/chromium/issues/detail?id=1447329 Hopefully a Chromium engineer will chime with some info on the fundamental limits here. Will update this issue if there's a response.

[josephrocca]

Okay, so it looks like it's possible to get about an order of magnitude faster with some adjutments, like setting bufferedAmountLowThreshold, as explained here: https://bugs.chromium.org/p/chromium/issues/detail?id=1447329#c4

Demo: https://lgrahl.de/examples/dc/dc-speedtest.html

(I haven't tried to adapt the demo in my earlier comment based on the code in the above-linked demo, so I can't completely confirm whether that test is "fair" - especially since it runs in a single tab)

[szimek]

@josephrocca Thanks! ShareDrop uses a really old Peer.js library, that was additionally modified to work with Firebase rather than its own signaling server. I thought about switching to something more modern like https://github.com/feross/simple-peer, but never had time to actually look into it.

[gabbelitoV2]

because it would have been fun if you updated