"Not enough space, dropping packet"

[Bjarkil]

I'll just get straight to the point.
For the past couple of weeks using this app, I have noticed that uploading files can be quite tricky.
When I am sending video files over gnirehtet, ranging from 5 to 50 MB, the packets are oftentimes dropped.
This results in stagnation of the upload or just a very slow upload.

In this file I have copied the cmd lines while trying to upload a video file of 42.14MB: upload attempt.txt.
In this example I have manually stopped the client right after the upload stagnated.
As you can see in the timestamps, I could not get more than (at maximum) 10 seconds of continuous upload. The effective transfer of the file in this, albeit short, time frame was just ~0.8Mbps, whilst I have a 4Mbps upload connection.

If there is more information you might require, I am more than willing to give it to you to solve this problem.

[rom1v]

Hi, thank you for your report.

It seems the network socket does not consume the stream received from the device quickly enough. But I guess the device TCP peer should slow down after a packet loss, to avoid congestion, which it apparently does not do.

Maybe the client-to-network buffer is too small, you could try to increase its size:

diff --git a/relay-rust/src/relay/tcp_connection.rs b/relay-rust/src/relay/tcp_connection.rs
index 94993936..108df459 100644
--- a/relay-rust/src/relay/tcp_connection.rs
+++ b/relay-rust/src/relay/tcp_connection.rs
@@ -151,7 +151,7 @@ impl TcpConnection {
             stream: stream,
             interests: interests,
             token: Token(0), // default value, will be set afterwards
-            client_to_network: StreamBuffer::new(4 * MAX_PACKET_LENGTH),
+            client_to_network: StreamBuffer::new(32 * MAX_PACKET_LENGTH),
             network_to_client: packetizer,
             packet_for_client_length: None,
             closed: false,

If it just delays the problem, then this is not the root cause.

According to the ignored packet TCP numbers, the packets are quite small (536 bytes), which is odd (the MTU is set to 16384). Maybe this floods the poll which may not send packets to network fast enough.

How much goes gnirehtet consume CPU when uploading a file? What is the device? What is the computer OS (linux, windows, mac)?

[Bjarkil]

I am using a Xiaomi Mi A1 (although I had the same issue on my LG Nexus 5) connected to a PC running Windows 10 to send video files over KakaoTalk, but I have the same problem in other apps too.
My CPU usage is about 0.5%, it's really not intensive by any measure...

To be quite honest I don't know much about programming, so modifying the code of the program and recompiling will be quite a challenge to me. I have implemented the change you have suggested (I think?) but I am absolutely clueless as to what to do next, something like compiling the code? I haven't a clue...

Regardless, thank you for the timely reply!

[Bjarkil]

Hello again.
I have managed to build a new rust server, but the problem persists.
errorlog30012018.txt
This is the output I get when I try to upload larger files.
This is with a server where client_to_network: StreamBuffer::new(16 * MAX_PACKET_LENGTH), the problem also persists when client_to_network: StreamBuffer::new(32 * MAX_PACKET_LENGTH) or 64.

[rom1v]

@Bjarkil Thank you for your tests, that's interesting. IMO the device TCP peer should slow down after a packet lost.

Do you have the same problem on other devices?

[rom1v]

@Bjarkil Could you test whether this version fixes the problem, please?

[rom1v]

Fixed on dev.

[rom1v]

It's in the v2.2 release: https://github.com/Genymobile/gnirehtet/releases/tag/v2.2