Let’s start with the bad news. We don’t have TCP fastopen support for Windows nodes running the binary. So if you are running the Windows binary you can stop here. Windows support will get implemented with this ticket: Windows support for TCP Fast Open · Issue #5990 · storj/storj · GitHub
Please grep your logs to see if you have any loglines with fastopen. Ideally, you have no loglines at all. That would indicate TCP fastopen is working fine on your node.
If you see something like this in your logs please enable TCP fastopen on your machine. The goal is to make these loglines go away.
INFO server server/fastopen_linux.go:44 kernel support for server-side tcp fast open remains disabled. {"Process": "storagenode"}
INFO server server/fastopen_linux.go:50 enable with: sysctl -w net.ipv4.tcp_fastopen=3 {"Process": "storagenode"}
After the next storage node release v1.81 has been rolled out we want to run performance tests with TCP fastopen. The loglines above are already in the code for quite some time. The new release will just add some metrics for us to count the number of TCP fastopen nodes. More nodes supporting it will help us to get better test results.
A small side note: if you followed along with the original TCP FASTOPEN design doc discussion, you may be worried that it is not always safe to enable TCP_FASTOPEN for your storage node. You no longer need to worry about that! We figured out how to make it always safe. Clients that try to use TCP_FASTOPEN will always concurrently try a normal TCP dial, so that at least one will succeed. The node also knows how to effectively “debounce” the incoming connections if both succeed.
In fact, there is now a substantial benefit to enabling TCP_FASTOPEN - if it is enabled, your node has a better chance of winning upload races.
We need server-side enabled, but we also don’t support TCP FASTOPEN on FreeBSD yet. Set server_enable to true and hopefully a future release of the storage node on FreeBSD will take use of that.
It’s in system settings → advanced in TrueNAS Scale but that alone doesn’t seem to take effect inside the kubernetes container. Haven’t rebooted yet but have restarted the app and still no fastopen.
I remember now… Synology dosen’t support that parameter. It gives this error:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:495: container init caused: write sysctl key net.ipv4.tcp_fastopen: open /proc/sys/net/ipv4/tcp_fastopen: no such file or directory: unknown.
I just enabled it in sysctl.conf; I don’t see any log entries for tcp fast open or fastopen, in error log mode. Maybe I’m OK?! Should I switch to info mode?