Linux, "failed to sufficiently increase receive buffer size"

Just noting a following observation. I’ve got a following warning in the logs after restarting a node:

2021-03-27T13:37:10.784Z        INFO    failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details. 

The linked webpage suggests:

It is recommended to increase the maximum buffer size by running:

sysctl -w net.core.rmem_max=2500000

This command would increase the maximum receive buffer size to roughly 2.5 MB.

I suspect that the impact of not changing this setting is minimal, but SNOs might want to take attention.

1 Like

this is part of a new feature that afaik isn’t implemented yet.
so it can be safely ignored.

Yes, at the moment it’s not required, but you can fix this issue as recommended. It will not hurt your system or storagenode. But when the time is to come - your setup will be ready.

2 Likes

Does sysctl -w net.core.rmem_max=2500000 survive a reboot?

You need to put line into /etc/sysctl.conf
net.core.rmem_max=2500000

Now it will apply setting after every reboot.

Edit: -w option should make it permanently.
Source https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-parameters-at-runtime_managing-monitoring-and-updating-the-kernel

I have done this, but the error is still there.

1 Like

did you also open a udp port on the same port number as the storj node tcp port …

you will need that also.

and ofc routed to the same ip …

Добрый день! Открыл порт UDP… выполнил команду под root доступом sysctl -w net.core.rmem_max=2500000 на Synology RS 2416+. Тест - ОК. (Ошибка : INFO failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB) - отсутствует).
:wink:

Thanks @SGC. I have both open now and will see how it goes.

Sorry for the late reply, I’ve had major h/w, power and net problems here. So far on the floor: 1 QNAP NAS out of 2, 3x 4TB HDs out of 9and 2 motherboards, one brand new. My secondary node disappeared somewhere in this mess, as did my Burst miner. Oh, and an APC UPS that isn’t (uninterruptible).

1 Like

The docker runcommand doesn’t need to be updated? Meaning docker by default will forward both TCP & UDP when using -p 28967:28967?

docker specifies another configuration example, but can’t see where if not specified if it’s only TCP

-p 8080:80/tcp -p 8080:80/udp
Map TCP port 80 in the container to TCP port 8080 on the Docker host, and map UDP port 80 in the container to UDP port 8080 on the Docker host.

It has to be:

-p 28967:28967/tcp
-p 28967:28967/udp
2 Likes

And of course, in the router, port forwarding for both TCP / UDP protocols

2 Likes

tried to use this didn’t seem to work on debian buster…
i think this got change into being a legacy thing and multiples of these buffers was either combined into a single setting or something can’t remember might have been something else that looked a lot like it tho… so many buffers and net.core settings in the network usually…

oh wait i think i got this… ofc the network settings is gotten from outside the container :smiley: DUH!!!
yeah seems to work there… and now the error in the log is also gone…