SRT server-to-client performance

[xmaslo]

I'm sending the same file from the server to client and vice versa. In the local network, I have no problems, the server-to-client performance is as expected (around 100 MiB/s). However, over the internet, the server-to-client performance is drastically worse than the client-to-server-performance.

SERVER-TO-CLIENT
client: ./srt-file-transmit srt://[HOST]:[PORT] file:///path/to/file
server: ./srt-file-transmit file:///path/to/file srt://:[PORT]?mode=listener

CLIENT-TO-SERVER
client: ./srt-file-transmit file:///path/to/file srt://[HOST]:[PORT]
server: ./srt-file-transmit srt://:[PORT]?mode=listener file:///path/to/file

In the server --> client scenario, my speed is peaking at around 200KiB/s.
On the other hand, in the client --> server scenario, I can get easily to around 30MiB/s.

I tried UDP on the same port, both ways are approximately the same (30 MiB/s).

What could be the issue in the *server-to-client scenario? I do not expect there is a problem with the network since UDP works just fine. Is this some sort of a bug? The issue is same both for the srt-file-transmit as well as when calling the API directly.

[santomet]

Bump, I also experience this problem in FILE/MESSAGE mode. Is there any possible explanation?

[ethouris]

First question: do you transmit in both configuration over the exactly same network path in the same direction?

And, if you could repeat this test - this time using srt-test-file (it works mostly the same way, but it's using blocking mode by default; requires --enable-testing when compiling), I would be also appreciated.

[maxsharabayko]

I would suggest trying to enable FileCC-related logs (e.g. changing HLOGC to LOGC and maybe log level) and analyze where it is stuck.

SRT stats (-statsout <filename> command-line option) can also be used to check CWND and flow window size. CSV file can be fed to SRT stats plotting for visualization.

[xmaslo]

First question: do you transmit in both configuration over the exactly same network path in the same direction?

And, if you could repeat this test - this time using srt-test-file (it works mostly the same way, but it's using blocking mode by default; requires --enable-testing when compiling), I would be also appreciated.

First question:
Only one side has a public ip and so I always connect in the same direction (thus I believe the network path is the same in both configurations).

As far as the second suggestion goes, I tried it and result is the same.

[xmaslo]

I would suggest trying to enable FileCC-related logs (e.g. changing HLOGC to LOGC and maybe log level) and analyze where it is stuck.

SRT stats (-statsout <filename> command-line option) can also be used to check CWND and flow window size. CSV file can be fed to SRT stats plotting for visualization.

I used the ENABLE_HEAVY_LOGGING flag and behavior is different. It starts with about 3 MiB/s and quickly crashes (which is much faster than 200KiB/s, but without HEAVY_LOGGING enabled, applications do not crush).

I run the statistics and these were the results:
Server-to-client (server is the sender):

server-to-client(server).csv
server-to-client(client).csv

Client-to-server (client is the sender):
client-to-server(server).csv
client-to-server(client).csv

There are noticable differences mostly in bandwidth and congestion window.

Visuals:

server-to-client(server):

server-to-client(client):

client-to-server(server):

client-to-server(client):

[ethouris]

It just hit my head.

Are you using IPv4 or IPv6?

Because we have detected a small problem here - see #2663

[xmaslo]

It just hit my head.

Are you using IPv4 or IPv6?

Because we have detected a small problem here - see #2663

We are using IPv4, so this should not be an issue.