Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, On 08/01/2012 10:46 AM, Csurai Akos wrote: >> Why is C slower than B in your setup? > :-\ As far as I understand our cluster uses special version of NFSV3 > client code > that works like a "latency test" from the drbd point of view: > write everything in small fractions and commit it instantly. > Yes, peers have the same HW. Hmm, then I suppose network latency is your bottleneck. I guess my earlier statement (C should not be slower than B with equal hardware) was false. B protocol can hide some network latency because it allows for parallel network communication and disk sync. Maybe you can optimize your network performance somehow? You're using SLES11SP2? What network hardware is this? For example, we've found that the in-tree e1000e driver is sort of old, critically so in 2.6.32, but even 3.2 is not really up-to-date, 3.0 presumably less so. > Agree, but it is to be ensured that C protocol really > solve the symptom and > not just hide it or just reduce the probability of it. Good point. Best, Felix