[Drbd-dev] switching between protocols A and C

[Lars Ellenberg]

On Wed, Apr 11, 2007 at 04:04:33PM +0100, Cristian Zamfir wrote:
> Lars Ellenberg wrote:
> > On Wed, Apr 11, 2007 at 02:46:02PM +0100, Cristian Zamfir wrote:
> >> Lars Ellenberg wrote:
> >>> On Wed, Apr 11, 2007 at 01:13:32PM +0100, Cristian Zamfir wrote:
> >>>> Hi,
> >>>>
> >>>> Would it be possible to switch from protocol A to C and vice versa 
> >>>> without disconnecting (for instance detach, switch protocol and 
> >>>> re-attach)?
> >>>>
> >>>> This would be useful when alternating between two primaries (only 
> >>>> protocol C can be used) and a primary/secondary configuration where 
> >>>> protocol A may increase write throughput on the primary node.
> >>> protocol A does _NOT_ increase throughput at all.
> >>> it _MAY_ reduce latency somewhat sometimes.
> >> I am testing with the bonnie++ benchmark over a 100Mbps link and I get a 
> >> substantial increase for output in the case of protocol A at the expense 
> >> of higher CPU ratio. From what I understand, it would make sense to get 
> >> better throughput from the asynchronous protocol over low quality links. 
> >> Or am I doing something wrong?
> > 
> > and your exact bonnie++ command line is:
> > 
> Bonnie++ is run with the default parameters:
> bonnie++ -u zamf -d bonnie/
> 
> I have results from ./tiobench, with shows a 2.4x increase in 
> performance in favour of protocol A:
> 
> /usr/bin/tiotest -t 8 -f 60 -r 500 -b 4096 -d . -T-T

sorry, I don't have the time to interpret your benchmark results
in detail. it is likely that these benchmarks are just not testing
what I call "throuput".
which is sustained sequential block writes (streaming),
as can be measured with e.g. the "dm" tool from the benchmark sub
directory in the drbd tarball.

even so, regardless of benchmark results, the answer stands:

 either you allow two primaries,
   and are force to use protocol C.

 or you do not allow two primaries,
   and are free to chose the protocol.

protocol changes involve a disconnect/reconnect on both nodes.
I do not see any reason to change this.

-- 
: Lars Ellenberg                            Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH      Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe    http://www.linbit.com :
__
please use the "List-Reply" function of your email client.