05-06-2016, 02:18 AM
Hello,
I have done some more tests and digged in tcpdumps. I see, that the PINE(512) loses sometimes a packet while receiving. In combination with a really big TCP receive window of 1MB (while the PINE+ stays around 50kB) that leads to severe breakdowns in transfer rate.
I see the packet while sniffing on the server and sniffing on the wire (with a small NetGear ProSafe Plus Switch as dedicated sniffing TAP before the PINE)
The PINE is sending then up to 130 SACKs, excluding the missing packet (caused by the big transfer window)
Switching windows scaling off on the Pine(512) [sysctl -w net.ipv4.tcp_window_scaling=0 ] has the effect, that the available peak transfer rates are somewhat slower, but the overall transfer rate is significantly higher and more predictable. But there is still the situation, that network packets are just delayed (which is seen in my echo-script). This delay may have the same reason as the lost packages or not.
When I switch off generic-receive-offload on the PINE(512) [ethtool -K eth0 gro off ] , the rate of delayed packages is almost disappearing.
I wonder, if that is a problem of my specific PINE (defect in NIC) or if other users are seeing similar problems?
Right now I can use the PINE(512) for my planned project, as with the described changes the connectivity is now reliable.
With some more time, I may start digging in deeper. As for now I will continue with other projects.
Thanks for all your support!
I have done some more tests and digged in tcpdumps. I see, that the PINE(512) loses sometimes a packet while receiving. In combination with a really big TCP receive window of 1MB (while the PINE+ stays around 50kB) that leads to severe breakdowns in transfer rate.
I see the packet while sniffing on the server and sniffing on the wire (with a small NetGear ProSafe Plus Switch as dedicated sniffing TAP before the PINE)
The PINE is sending then up to 130 SACKs, excluding the missing packet (caused by the big transfer window)
Switching windows scaling off on the Pine(512) [sysctl -w net.ipv4.tcp_window_scaling=0 ] has the effect, that the available peak transfer rates are somewhat slower, but the overall transfer rate is significantly higher and more predictable. But there is still the situation, that network packets are just delayed (which is seen in my echo-script). This delay may have the same reason as the lost packages or not.
When I switch off generic-receive-offload on the PINE(512) [ethtool -K eth0 gro off ] , the rate of delayed packages is almost disappearing.
I wonder, if that is a problem of my specific PINE (defect in NIC) or if other users are seeing similar problems?
Right now I can use the PINE(512) for my planned project, as with the described changes the connectivity is now reliable.
With some more time, I may start digging in deeper. As for now I will continue with other projects.
Thanks for all your support!