From: Loic Dachary <loic@dachary.org>
To: Andreas Joachim Peters <Andreas.Joachim.Peters@cern.ch>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: CEPH Erasure Encoding + OSD Scalability
Date: Tue, 12 Nov 2013 19:06:37 +0100 [thread overview]
Message-ID: <52826E2D.2040503@dachary.org> (raw)
In-Reply-To: <3472A07E6605974CBC9BC573F1BC02E4AE69CCB4@PLOXCHG03.cern.ch>
Hi Andreas,
On 12/11/2013 02:11, Andreas Joachim Peters wrote:
> Hi Loic,
>
> I am finally doing the benchmark tool and I found a bunch of wrong parameter checks which can make the whole thing SEGV.
>
> All the RAID-6 codes have restrictions on the parameters but they are not correctly enforced for Liberation & Blaum-Roth codes in the CEPH wrapper class ... see text from PDF
>
> "Minimal Density RAID-6 codes are MDS codes based on binary matrices which satisfy a lower-bound on the number of non-zero entries. Unlike Cauchy coding, the bit-matrix elements do not correspond to elements in GF (2 w ). Instead, the bit-matrix itself has the proper MDS property. Minimal Density RAID-6 codes perform faster than Reed-Solomon and Cauchy Reed-Solomon codes for the same parameters. Liberation coding, Liber8tion coding, and Blaum-Roth coding are three examples of this kind of coding that are supported in jerasure.
>
> With each of these codes, m must be equal to two and k must be less than or equal to w. The value of w has restrictions based on the code:
>
> • With Liberation coding, w must be a prime number [Pla08b].
> • With Blaum-Roth coding, w + 1 must be a prime number [BR99]. • With Liber8tion coding, w must equal 8 [Pla08a].
>
> ...
>
> Do you add this fixes?
Nice catch. I created and assigned to myself : http://tracker.ceph.com/issues/6754
>
> For the benchmark suite it runs currently 308 different configurations for the 2 algorithm which make sense from the performance point of view and provides this output:
>
>
> # -----------------------------------------------------------------
> # Erasure Coding Benchmark - (C) CERN 2013 - Andreas.Joachim.Peters@cern.ch
> # Ram-Size=12614856704 Allocation-Size=100000000
> # -----------------------------------------------------------------
> # [ -BENCH- ] [ ] technique=memcpy speed=5.408 [GB/s] latency=9.245 ms
> # [ -BENCH- ] [ ] technique=d=a^b^c-xor speed=4.377 [GB/s] latency=17.136 ms
> # [ -BENCH- ] [001/304] technique=cauchy_good:k=05:m=2:w=8:lp=0:packet=00064:size=50000000 speed=1.308 [GB/s] latency=038 [ms] size-overhead=40 [%]
> ..
> ..
> # [ -BENCH- ] [304/304] technique=liberation:k=24:m=2:w=29:lp=2:packet=65536:size=50000000 speed=0.083 [GB/s] latency=604 [ms] size-overhead=16 [%]
> # -----------------------------------------------------------------
> # Erasure Code Performance Summary::
> # -----------------------------------------------------------------
> # RAM: 12.61 GB
> # Allocation-Size 0.10 GB
> # -----------------------------------------------------------------
> # Byte Initialization: 29.35 MB/s
> # Memcpy: 5.41 GB/s
> # Triple-XOR: 4.38 GB/s
> # -----------------------------------------------------------------
> # Fastest RAID6 2.72 GB/s liber8tion:k=06:m=2:w=8:lp=0:packet=04096:size=50000000
> # Fastest Triple Failure 0.96 GB/s cauchy_good:k=06:m=3:w=8:lp=0:packet=04096:size=50000000
> # Fastest Quadr. Failure 0.66 GB/s cauchy_good:k=06:m=4:w=8:lp=0:packet=04096:size=50000000
> # -----------------------------------------------------------------
> # .................................................................
> # Top 1 RAID6 2.72 GB/s liber8tion:k=06:m=2:w=8:lp=0:packet=04096:size=50000000
> # Top 2 RAID6 2.72 GB/s liber8tion:k=06:m=2:w=8:lp=0:packet=16384:size=50000000
> # Top 3 RAID6 2.64 GB/s liber8tion:k=06:m=2:w=8:lp=0:packet=65536:size=50000000
> # Top 4 RAID6 2.60 GB/s liberation:k=07:m=2:w=7:lp=0:packet=16384:size=50000000
> # Top 5 RAID6 2.59 GB/s liberation:k=05:m=2:w=7:lp=0:packet=04096:size=50000000
> # .................................................................
> # Top 1 Triple 0.96 GB/s cauchy_good:k=06:m=3:w=8:lp=0:packet=04096:size=50000000
> # Top 2 Triple 0.94 GB/s cauchy_good:k=06:m=3:w=8:lp=0:packet=16384:size=50000000
> # Top 3 Triple 0.93 GB/s cauchy_good:k=06:m=3:w=8:lp=0:packet=65536:size=50000000
> # Top 4 Triple 0.89 GB/s cauchy_good:k=07:m=3:w=8:lp=0:packet=04096:size=50000000
> # Top 5 Triple 0.87 GB/s cauchy_good:k=05:m=3:w=8:lp=0:packet=04096:size=50000000
> # .................................................................
> # Top 1 Quadr. 0.66 GB/s cauchy_good:k=06:m=4:w=8:lp=0:packet=04096:size=50000000
> # Top 2 Quadr. 0.65 GB/s cauchy_good:k=07:m=4:w=8:lp=0:packet=04096:size=50000000
> # Top 3 Quadr. 0.64 GB/s cauchy_good:k=06:m=4:w=8:lp=0:packet=16384:size=50000000
> # Top 4 Quadr. 0.64 GB/s cauchy_good:k=05:m=4:w=8:lp=0:packet=04096:size=50000000
> # Top 5 Quadr. 0.64 GB/s cauchy_good:k=06:m=4:w=8:lp=0:packet=65536:size=50000000
> # .................................................................
>
> It takes around 30 second on my box.
That looks great :-) If I understand correctly, it means https://github.com/ceph/ceph/pull/740 will no longer have benchmarks as they are moved to a separate program. Correct ?
> I will add a measurement how the XOR and the 3 top algorithms scale with the number of cores and make the object-size configurable from the command line. Anything else ?
It would be convenient to run this from a "workunit" ( i.e. a script in ceph/qa/workunits/ ) so that it can later be run by teuthology integration tests. That could be used to show regression.
Shall I add the possiblity to test a single user specified configuration via command line arguments?
>
I would need to play with it to comment usefully.
Cheers
--
Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-11-12 18:06 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <-7369304096744919226@unknownmsgid>
2013-09-20 11:35 ` CEPH Erasure Encoding + OSD Scalability Andreas Joachim Peters
2013-09-20 12:33 ` Loic Dachary
2013-09-20 13:19 ` Mark Nelson
2013-09-20 15:36 ` Sage Weil
2013-09-20 16:49 ` Loic Dachary
2013-09-21 15:11 ` Loic Dachary
2013-09-22 7:26 ` Andreas Joachim Peters
2013-09-22 9:41 ` Loic Dachary
2013-11-12 1:11 ` Andreas Joachim Peters
2013-11-12 18:06 ` Loic Dachary [this message]
2013-11-19 11:35 ` Andreas Joachim Peters
2013-12-09 16:45 ` Loic Dachary
2013-12-09 17:03 ` Mark Nelson
2013-12-10 8:43 ` Loic Dachary
2013-12-11 9:49 ` Andreas Joachim Peters
2013-12-11 12:28 ` Loic Dachary
2013-12-11 13:00 ` Mark Nelson
2013-12-13 15:47 ` Andreas Joachim Peters
2013-12-13 16:42 ` Loic Dachary
2013-09-22 23:00 Andreas Joachim Peters
2013-09-23 7:27 ` Loic Dachary
2013-09-23 9:37 ` Andreas Joachim Peters
2013-09-23 15:43 ` Andreas Joachim Peters
2013-09-25 15:14 ` Loic Dachary
2013-09-25 18:33 ` Andreas Joachim Peters
2013-09-25 18:48 ` Loic Dachary
2013-09-25 18:53 ` Sage Weil
[not found] ` <CAGhffvz1TYYLoqn0tps1HiLObSCv7H0ZNVgOd0raicGqgRuukA@mail.gmail.com>
2013-09-26 19:18 ` Loic Dachary
2013-09-26 21:49 ` Andreas Joachim Peters
2013-09-27 9:40 ` Loic Dachary
2013-10-01 23:00 ` Andreas Joachim Peters
2013-10-02 10:04 ` Loic Dachary
2013-10-02 10:15 ` Loic Dachary
[not found] <3472A07E6605974CBC9BC573F1BC02E494B06990@PLOXCHG04.cern.ch>
2013-07-05 21:23 ` Loic Dachary
2013-07-06 13:45 ` Andreas Joachim Peters
2013-07-06 15:28 ` Mark Nelson
2013-07-06 20:43 ` Loic Dachary
2013-07-08 15:38 ` Mark Nelson
[not found] ` <CAGhffvx5-xmprT-vL1VNrz12+pJSikg1WsUqy_JRdW0JNm5auQ@mail.gmail.com>
2013-07-06 20:47 ` Loic Dachary
2013-07-07 21:04 ` Andreas Joachim Peters
2013-07-08 3:37 ` Sage Weil
2013-07-08 10:00 ` Andreas Joachim Peters
2013-07-08 10:31 ` Loic Dachary
2013-07-08 15:47 ` Sage Weil
2013-08-19 10:35 ` Loic Dachary
2013-08-22 21:50 ` Andreas Joachim Peters
[not found] ` <CAGhffvwB87a+1294BjmPrfu0a9hYdu17N-eHOvYCHWMXDLcJmA@mail.gmail.com>
2013-08-22 23:03 ` Loic Dachary
[not found] ` <CAGhffvxW9sG5LtcF-tU1YGkCMAQUfh2WW_3N=f=-vWs48vyxkQ@mail.gmail.com>
2013-08-24 19:41 ` Loic Dachary
2013-08-25 11:49 ` Loic Dachary
2013-09-14 14:59 ` Andreas Joachim Peters
2013-09-14 18:04 ` Loic Dachary
[not found] <CAGhffvws=OabwJHi+7n=SOg+YNxAnU=Zt8WLVZtvf1neHZQYhw@mail.gmail.com>
2013-07-04 13:07 ` Loic Dachary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52826E2D.2040503@dachary.org \
--to=loic@dachary.org \
--cc=Andreas.Joachim.Peters@cern.ch \
--cc=ceph-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox