net.ipv4.tcp_wmem set to 8192 8192 8192

ciriarte

Hello PLCNext Team -

We would like to understand why you're setting this kernel param (in /etc/sysctl.conf):

net.ipv4.tcp_wmem = 8192 8192 8192

We're seeing degraded network performance due to this setting. We would like to understand the implications of specifying different values for minimum, default and max.

We're running a custom application in the non-realtime part of the PLC. It deals with heavy TCP traffic. Our application appears to behave better when we tune these values to something like

net.ipv4.tcp_wmem = 4096 16384 4194304

We're hesitant to change these values without understanding the consequences or your design rationale.

Martin [PLCnext Technology Team]

Hi, thanks for the quite interesting question.

This setting has been made to balance various network requirements in the controller, especially when using Profinet. If your application does not use Profinet, and if (after thorough testing) you find that alternative settings do not adversely impact the network performance in your application, then there shouldn't be a problem making this change.

If you would like to discuss your specific application in more detail outside this public forum, please get in touch with your local Phoenix Contact office and we can discuss any other technical questions that you may have.

dwilson

Hi Martin,

Thanks for the response. For a bit more detail: we run two applications on the PLC - one is a project built in plcnext engineer that does rely on profinet, and the other is a separate custom application that does not use profinet (this second one runs the TCP workload). We haven't noticed any obvious problems with the profinet data in the testing we've done so far.

What sort of adverse interactions with profinet were considered or observed when tuning this setting?

Martin [PLCnext Technology Team]

In the past, Profinet communication problems were observed in scenarios similar to the following:

• Profinet network with 28 participants and update times of approx. 4 ms
• While copying large files from the controller (e.g. file sizes > 100MB)

After changing the value of net.ipv4.tcp_wmem to 8192 8192 8192, the problem was no longer observed (tested with 30 participants / 1ms update time). The change did not appear to affect the file transfer rate, which was approximately 10MB/s in all cases.