Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Mar 07, 2008 at 11:39:49AM -0000, Azeez Ahamed wrote: > > > > It has been observed that when protocol A and B is used, there is > >some impact on the I/O performance (especially on sequential writes) > >compared to protocol C. But theoretically, protocols A and B should be faster than C. Why Tiobench results (http://www.drbd.org/performance .html) says that protocol C is good ? > > > > Even i carried out performance tests (using Tiobench tool) on 8.0.3 build and i observed that the results are almost same as the one mentioned on the DRBD site. > > > > Please let me know the reason behind it. > > > > LARS REPLY: > > > > >because those results are horribly out of date? > >note, kernel 2.4 and DRBD-0.6.6 were used for these tests. > >protocol A and B implementation was broken then. > > > >because there are two aspects to protocol choice in DRBD? > > * latency > > * data safety > > > >because you measured throughput, > >and the choice of DRBD protocol has no impact on sustainable throughput? > > > >we realy should take that page offline. > >or better yet, replace with some more recent benchmarks. > >I'll try to dig some up. > > > >with recent 8.0 resp. 8.2, > >the protocols finally are implemented correct, > >and indeed show the expected latency improvements: > >A exposes nearly local latency, > >B has some latency overhead (order of round-trip-time), > >C latency overhead is (order of round-trip-time plus some). > > > >as mentioned, you trade data safety against latency. > I have carried out performance test on 8.0.3 version using Tiobench > tool. But, results says that Avg latency in case of protocol C is > less compared to protocol A and B (during write operation), > theoretically which is not expected. > > Can someone please tell me the reason for it? (refer results given > below for Sequential and Random writes) answer yourself these questions, and maybe you find the reason for it. * why not using DRBD 8.0.11, or 8.2.5 * what is your kernel * what is your storage subsystem * what is your io scheduler/elevator * what is your file system, if any * how does StandAlone DRBD (that is after drbdadm disconnect) compare against using that storage directly, without DRBD * how does latency change when using - no file system - different file systems * what exact command line did you use for the benchmark * how do figures change when - using only one thread - using a different io scheduler - using _synchronous_ writes, which is the only thing you should care about for latency of DRBD, otherwise you are measuring something completely different. * how many DRBD meta data transactions happened during that benchmark run * how does statistics change when you operate within the activity log * how do latency figures change when measuring with some other tool -- : Lars Ellenberg http://www.linbit.com : : DRBD/HA support and consulting sales at linbit.com : : LINBIT Information Technologies GmbH Tel +43-1-8178292-0 : : Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 : __ please use the "List-Reply" function of your email client.