Hi everybody, I am experiencing RX packet drops sometimes and it seems that TIPC has some hard time dealing with that. When I looked in tipc_link.c I found the following comment:
/* TODO: Implement stronger sequence # checking someday ... */ and .. then I got a bit worried :) What exactly is the expected behavior in case of droped eth packets? As soon as the nic drops even few packets, the TIPC stack becomes .. well completely unpredictable. In 80% of the cases a disable/enable of the bearer helps, but there are those 20% when only complete reboot solves the problem. Also affected links never timeout/reset on their own. I am working on resolving the packet drop issue in general, but that's not a long term solution, neither is trying to detect if things went wrong. It's also worth noting that those 20% of cases tend to happen when my apps try to transfer 2-3MB or more in series of 16K send()s over a SOCK_SEQPACKET socket. About the setup: * TIPC network of 20+ nodes, Intel/AMD, 32bit, SMP all of them * NICs are either e1000 or tg3 driven, working over a gbit full duplex link, all nodes are connected to a 24 port gbit d-link switch * TIPC is 1.7.5 with two of the 4 posted/available patches: - Prevent-premature-discarding-of-messages-during-fragment-reassembly - Fix-port-related-bugs-arising-when-TIPC-network-address-is-assigned * issue exists with both 2.6.20.4 and 2.6.24.2 kernels * tested with NIC qlen of 1000 - 8192, tipc link window up to 4096 packets * under normal conditions max send queue stays within the 60-100 range. One more note: I had similar problems with the stock TIPC 1.6.2 some time ago. Back then the stack was much more predictable and a disable/enable of the bearer helped in 99% of the cases. I resolved the issue by increasing tipc link window (a lot .. to 1024 at first) and upgrading to TIPC 1.7.5 (which btw manages 2+ times smaller max send queue under the same conditions .. thanks for that ;) .. 1.7.5 seems to work much more smoothly in general). Any help/info/suggestions? Regards, Peter Litov. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
