transfer not utlising full bandwidth capacity

[debpalash]

• via webrtc but is it's network bandwidth utilisation is below 30-50% where it could be 90-95%. ( a. netrwork capacity is 1gbps, b. 100mbps. So if sending is throttled to my receiving capacity it should be around b's capacity. But i'm barely getting near 30-40mbps)

Is parallel connections / multi-threading possible?

edit: Whatever croc is doing seems can use my full badwidth.

[ZinoKader]

Can you provide more details on which type of transfer this is? Was it over a local network or over the internet (using the relay)?

Do a portal send file -v and paste the resulting log.

[debpalash]

Can you provide more details on which type of transfer this is? Was it over a local network or over the internet (using the relay)?

Over internet.

Do a portal send file -v and paste the resulting log.

I can give you a result next time use.

[alin23]

I also was a user of croc before stumbling into portal.

I just did a send test with both on a 1.3GB dyld cache file and the results are:

• Portal: compressed the file to 438.5 MB and sent it in 2:43 (2 minutes and 43 seconds)
• croc: sent the full 1.3 GB in 3:55 (3 minutes and 55 seconds)

The file was sent from my MacBook Pro M1 in Romania to a Hetzner server in Helsinki.

So in my tests, croc doesn't seem to do anything that would result in it being faster. On the contrary, it misses a low hanging fruit by not compressing a large file.

[debpalash]

I also was a user of croc before stumbling into portal.

I just did a send test with both on a 1.3GB dyld cache file and the results are:

* **Portal**: compressed the file to `438.5 MB` and sent it in 2:43 (2 minutes and 43 seconds)

* **croc**: sent the full `1.3 GB` in 3:55 (3 minutes and 55 seconds)

The file was sent from my MacBook Pro M1 in Romania to a Hetzner server in Helsinki.

So in my tests, croc doesn't seem to do anything that would result in it being faster. On the contrary, it misses a low hanging fruit by not compressing a large file.

So youre saying what croc took for the 1300mb file portal took around 30% less time even after compressing it 1/3 of the original file. I'm not complaing about other things just saying the bandwidth utilization could be better.

[alin23]

I also was a user of croc before stumbling into portal.

I just did a send test with both on a 1.3GB dyld cache file and the results are:

* **Portal**: compressed the file to `438.5 MB` and sent it in 2:43 (2 minutes and 43 seconds)

* **croc**: sent the full `1.3 GB` in 3:55 (3 minutes and 55 seconds)

The file was sent from my MacBook Pro M1 in Romania to a Hetzner server in Helsinki.

So in my tests, croc doesn't seem to do anything that would result in it being faster. On the contrary, it misses a low hanging fruit by not compressing a large file.

So youre saying what croc took for the 1300mb file portal took around 30% less time even after compressing it 1/3 of the original file. I'm not complaing about other things just saying the bandwidth utilization could be better.

Compression and decompression time are also factored in the portal benchmark.

I think they do pretty much the same thing: Open a single connection and send a file sequentially until it's done.

What other things could be improved here? Opening multiple connections and sending multiple chunks of the file in parallel?

[debpalash]

closing because of no fruitful arguments.

[ZinoKader]

I do think we need to look into this more and see if there are any performance problems with the transfer routine itself. It may also very well be the tiny server used for relay transfers as well, or its location.

Is it fine if I reopen this issue? @debpalash

[debpalash]

I do think we need to look into this more and see if there are any performance problems with the transfer routine itself. It may also very well be the tiny server used for relay transfers as well, or its location.

Is it fine if I reopen this issue? @debpalash

Could be any of these issues and sure @ZinoKader

[ZinoKader]

I have tested this extensively between different machines and I seem to cap out on the weakest link on all transfers. That is, the lowest upload/download that I can measure using iperf3 is almost exactly matched by the average transfer speed of portal.

I'm not 100% sure still about what causes the issues you are describing, as I'm having a hard time reproducing them. If you are experiencing this issue, please provide an iperf3 test between the two machines (if you can open ports/firewalls on the server) and compare that with the transfer speed of portal.