-
I have completed my testing and it was a success. The connections are no longer dropped while true connection drop is detected within time given in parameters.
The following are the changes I did. It is done against 2.2.1. As you can see, I did not parametrize the setting, it is compiled in.
I hope you can include a solution like this in the official Linx distro, so we can drop this fix...
2009-09-10 22:40:54 UTC in LINX
-
I did not mention this, but of course the intent is to run multiple checks and ACK reqs within a single timeout interval. 2 should be the minimum to avoid problems like mine. I'm playing with 3 now.
2009-09-04 12:10:22 UTC in LINX
-
Modifying the reset value itself would be the minimum that solves the problem. It will however increase the timeout implicitly. E.g. if I say timeout is 3s and reset value is 3 (instead of current 2), the true timeout will be between 2*tmo and 3*tmo. So this goes against discovering dead nodes within timeout given in parameters.
What I think is needed is a different parameter: number of pings...
2009-09-04 12:08:17 UTC in LINX
-
In my tests I actually decided to go with 3 checks every timeout period. This protects us more against single network hit, esp. when timers drift.
It also reduces the true timeout range from today's conn_tmo - 2*conn_tmo (worst case is where last ping arrives right after a check, then conn_tmo later check is still good, then another check fails, but it has been 2*conn_tmo until then). The...
2009-09-03 15:56:05 UTC in LINX
-
First of all, many thanks for your support so far!
I have isolated a problem where rsyncing a lot of data from particular box causes it to drop Linx connections every now and then. The root cause was later narrowed down to high load and some packet loss combined, heavy rsync causes both at the same time.
Turns out Linx is allowing only one conn_tmo interval to pass without any ACK or ACK...
2009-09-03 14:40:33 UTC in LINX
-
Initial results are very good, 2.2.1 performance is back to 2.1.0 levels. It is in line with UDP performance as well.
Many thanks. Your prompt response is appreciated!
2009-06-12 13:57:03 UTC in LINX
-
Thanks guys. I will run a "real test" and let you know if it cleared the condition.
2009-06-11 19:48:54 UTC in LINX
-
I'm doing some tests as part of Linx upgrade from 2.1.0 to 2.2.0. I have isolated a performance problem when a lot of messages are sent in one batch.
The problem is pretty visible when batch size is around 1000 messages 256 bytes each. Performance of 2.2.0 is about 10-20 times slower than 2.1.0. However, when batch size is at 100, 2.1.0 and 2.2.0 performance is within the same ballpark.
I...
2009-06-10 01:23:32 UTC in LINX
