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.