On Tue, 2009-04-14 at 11:12 -0500, David Teigland wrote: > From one lone, biased, user's point of view, optimized malloc and memcpy are > uninteresting -- message throughput isn't what I'm looking for. Are there > others out there who see this as important? I *would* be interested in seeing > improvements in the following areas:
Yes qpid has very high requirements (10gig wirespeed throughput) for message throughput so these types of optimizations easily improve their environment. > > . message latency, if that's even possible Reducing the time a token is held reduces latency. So memcpy and malloc specials does reduce latency. I don't have measures of how much, however. > > . recovery speed, this seems to be getting worse, things often hang for up > to many seconds when nodes join or leave these days > With trunk you see 2 second lags? I agree that the recovery engine needs work to allow background synchronization of data sets without blocking the entire cluster operation during the synchronization period. > . stability with much shorter token timeouts, we currently use 10 seconds > as default, and I know corosync should work well with something much > shorter, it "just" needs testing/validation along with some diagnostic > methods to figure out when you're using something too short > yes with 16 nodes it should work with 100msec timeouts as long as the kernel doesn't take long locks. I think all those bugs are fixed in dlm/gfs now however. The 10 seconds in cluster 2 was to work around those essentially "kernel lockups". Perhaps we can get some QE effort around identifying a shorter default. > . stability with clusters up to 32 nodes, with diagnostic capabilities to > immediately pinpoint the cause of a breakdown > This is a great idea, but the diags to pinpoint the cause are very difficult. I don't have a clear picture of how they would be designed but we have kicked around some ideas. thanks for all your inputs. I'll work them into the plans for the next releases of Corosync. Regards -steve > Dave > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
