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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.