hmmStudy and Performance of Reed Solomon and Cauchy Reed Solomon Erasure Codes

Ammar Karachiwala ammar.karachiwala@gmail.com

Abstract The reed Solomon codes has numerous applications from CDs, Blue Ray Disks and DVDs. They have also huge applications in the field for internet in DSL and Wi-Fi. In this paper, I compare the codes so as to find out the best performing codes. We perform experiments to decide on the best parameters for the codes. These parameters affect the speed of the code and it is important to identify the optimal parameters of the code. Also the internal workings of these codes are noted for their shortcomings or techniques for optimizations.

The Cauchy Reed Solomon codes cannot correct individual bit or word errors because of the encoding methods. The view of the codes is of encoding or decoding a block. Any errors occurring in a disk cannot be corrected or detected. Consider a storage system where disks fail (more than 1compared to RAID 5). Using the redundant and the data disk the erased can be recovered. Three types of Opens source erasure codes are used to test their encoding and decoding performance. Jerasure Jerasure is an extensive C library supporting the following encoding techniques. o Reed Solomon with Vandermonde matrices. o Cauchy Reed Solomon. o Optimized Cauchy Reed Solomon. o Other RAID 6 codes Liberation, CRS for RAID 6, Blaum-Roth, and Liber8tion. The RAID 6 codes are not used they offer a fixed number of redundant disks. The amount disks that can be encoded for redundancy, is always at a constant of two. This beats the purpose of flexibility.

1. Introduction
Erasure codes have wide applications. They are used for their flexibility and scalability. They have been used for survivable data systems to prevent data losses. These erasure codes are used in RAID 5 to perform recovery of one disk. The Erasure codes by themselves are capable of recovering more number of disks when used for a RAID type distribution. The codes can support higher number of recoveries depending on the amount redundant disks. The Reed Solomon codes even though an error correcting code can be used to form redundant disks, when a disk failure occurs the disk that have been erased (assumed to be erased even when they fail) are brought back using the Reed Solomon decoding methods.

Luby This code is coded in C using the Cauchy Reed Solomon technique by Michael Luby. It was developed in Berkeley at the ICSI labs.

data is split up into k disks and m disks are encoded. When any m disk (including the data or the redundant disk) fail or erased then m disks can be brought back using redundant disks. The Reed Solomon Codes each disk is seen as w-bits on each disk. The w is an element of {8, 16, and 32} which should be judiciously picked depending on the machines word sizes. The Galois Field is used over the numbers of 0 - 2w-1. A Vandermonde matrix is constructed with code words of w bits. In Cauchy Reed Solomon codes the encoding as mentioned above is a little different from Reed Solomon; the encoding is done packet by packet throughout the process. The word size is the size of sub matrix of the generator Cauchy matrix. As for the width of the generator matrix is controlled by the packet size. The w size can be as large as we want but we keep it in the same {4... 32}; for comparability to Reed Solomon Codes. The w size in Cauchy Reed Solomon codes n 2w where n=k + m.

Zfec The Zfec is a library developed by modifying a Forward error correcting library. Its also known as Zooko fec. The library includes the APIs in Python, Haskell and C.

The terminology concerning each of the codes will be discussed in the next section.

2. Terminology
There is no common terminology for these codes. Looking closely they follow more or less the same nomenclature for the parameters involved with the codes. Basically, the nomenclature follows the paper by James S. Planck A Performance Evaluation of Open Source Erasure Coding Libraries for Storage [1]. The Erasure codes work on the principal for Maximum Distance Separable (MDS). The

Fig: 1

3. Galois Field Arithmetic and Matrices[2]

Reed Solomon codes are constructed using Galois field arithmetic. GF (q) q = 2 for binary codes In Galois field a polynomial is constructed with coefficients from over GF (2) in the following form. f(X) = f0 + f1 X + f2 X2 + ... + fn Xn The addition, subtraction, multiplication and division are carried out in the usual way. The only difference is that addition 1 + 1 in a field over modulo 2 gives 0. This is like XORing the two values. Consider a symbol . Now we have the following set of elements over F on which multiplication operation . given by. F = {0, 1, , 2 j}. To get a field over 2m elements we use primitive polynomial of p(X) where is a root of p (X). In all practical applications of RS codes for error control q is set to 2m.

And the parity check matrix is given by H1 = [I | H]. Now each g of the generator matrix is a representation of the polynomial in GF (2m).The Vandermonde matrix can be still invertible even by adding a non Vandermonde matrix. The invertibility of the matrix is important because it is needed to decode the encoded code. In the implementation of Reed Solomon codes the matrices generated are given by:

Fig: 2 RS code Matrix The generator matrix, GT in the implementation is made up of an Identity matrix of k rows and m encoder polynomial rows. The number of columns is k. The polynomials are made so as to perform as a Maximum Density Code (MDS). The word sizes w give the length the polynomials. In the Galois Field addition is to an XOR whereas multiplications are done through logarithmic tables. These tables are look up tables called whenever multiplication is needed. These multiplications are converted into extra XORs and Shifts in the Cauchy Reed Solomon.

3.1

Reed Solomon

The RS codes [3] use Vandermonde matrices to construct the generator matrices. This is given by H =

Cauchy Reed Solomon

Vandermonde Matrix [3]

3.2

Cauchy Reed Solomon Codes[4]

The Cauchy Reed Solomon Codes are a modification over the Reed Solomon codes. The Vandermonde matrices are replaced by the Cauchy Matrix. Also rather than operating on word sizes, the operations are performed on packets at once. Consider F to be a field and {xi ,.., xm } , {yi ,.., ym } be two sets of elements then let two conditions should hold. Let the elements of two different sets the sum of the elements be non-zero. The elements of the two different subsets should be distinct among the sets. The Cauchy Matrix is given by C. C= Fig:3 Encoding using CRS matrix The Cauchy Reed Solomon can be further optimized by reducing the number of one and still keeping the Maximum Density. This is makes the corresponding decoding of the data slower.

4. Open Source Libraries

The Open Source codes that are tested for their working and performance are: Jerasure[5][6] The Jerasure is a library in C. The library is extensive covering many coding techniques from normal erasure codes to RAID 6.The documentations of this code is extensive. The document explains all the function in detail and how to use the APIs. There are some drawbacks the code is basically buggy at some points and some functions have b deprecated and still used. Luby[4][7] Luby is a CRS code in C. Luby uses its own random messages are in packets the size of 1000 bytes. The packets are then used to encode and

Cauchy Matrix [4]

The implementation of the process is shown in Fig 3. The generator matrix is a matrix of sub - matrices. The sub matrices are of the order w X w. The matrix is changed from (k+m) X m each element containing w bit to a matrix of (w X (k+m)) X (w X m) matrix. Here the decoding is same as that of RS where the matrix is inverted and encoding using the surviving data.

decode. The code bridges in the sense where the parameters are same as that of in the terminology mentioned above. The Lfield parameter is as same as of w. The Nsegs is the packet size in the Luby. Message packets and Redundant packets are same analogous to k and m. Zfec [8][9] Zfec has an API in Python, Haskell and C. The file handling, splitting and management is done in Python and the real encoding and decoding is done in C. The encoding can be done by calling zfec command for encoding and zunfec for decoding.

6. Data distribution
How data is distributed makes it important to simulate the right encoding. The part of the data is first distributed into k files and then encoded into other m files. Multiple read ins are made to encode depending on the size of the buffer. First a buffer is copied and k blocks are made and then copied into k files depicted in Fig 3. Now the k files are broken down into s word sizes. Now then k blocks are encoded for every x word size in each block and copied into the consecutive blocks of the code files.

5. Hardware
The hardware that I used to test these codes was a Gateway desktop. The desktop was not particularly high end but mediocre range machine. These could comfortably encode and decode the codes. Intel Celeron 32 bit 2.6 GHz L1 cache 20 KB. L2 cache 128 KB. 1 GB RAM OS: Ubuntu 9.10 (Desktop Edition). The encoder was being executed in user space to and all the encoding and decoding followed the almost 90% and above of CPU utilization.

Fig:4 File Distribution The number of blocks and k data blocks and m code blocks and w word sizes. If the encoder is Reed Solomon and it is divided into w bit words and for Cauchy Reed Solomon is w x w bit matrices.

7. Buffer Simulation
To measure the times involved in encoding a large, code was written in C to simulate encoding with these files. Initially, I just used two handles to read into a buffer and write into a file. The values of the

Fig: 5: First Experiment

experiment is shown in the Fig: 5 . The values were too less to match any proper data times so there was one more experiment was needed to simulate the right buffer spaces.

The results of this experiment are depicted in Fig: .For the second experiment of the same I used the encoding method that was used in the last section. The values used for the encoding was k=10 and m=6 and w=8. In the second experiment a buffer was initialized and copied from the main data. This data was split up into k files. The encoded data was split up in m files. To simulate the encoding random word sizes were written into code files. The word sizes was held constant at w=8.The times were recorded using the Unix gettimeofday () function. The optimal buffer size shows that the best candidates are 16 MB and 256 MB. The 256 MB buffer size shows a lot of variance. The experiment suggests that buffer size show a lot of impact on the encoding speed. The dummy encoding gives us the idea how the encoding depends upon the k, m and w.

Fig:6 Second Experiment

8. Parameter Spaces
One of the important set of parameters is the [k, m] of the encoding code. The value chosen for the experimentation was 10, 6. These values are real world values. This value represents high redundancy and that means high tolerance to erasures. The RS parameter other than [k, m] and w values which make sense so as to remain in their integer limits. Zfec: CRS coding w 8 for all [k, m]. Luby: CRS coding w {412} for all [k, m]. Jerasure: RS coding w {8, 16, 32} for all [k, m]. CRS coding w {4 32} for all [k, m].

Fig: 7 Packet Sizes The Encoding speed prefers a larger sized packet. The packet sizes favor multiples of the machine word size. The machine word sizes used is 8 so all the packets sizes that show peaks on the graphs are multiples of 8. The Encoding speeds do not increase more after some we reach higher packet sizes. The variance is very high for large packets sizes. While large packet sizes between 100 and 1000 show low variance, if some packet sizes are not considered that show huge dips. This experiment was performed to get the general idea of how the different packet sizes behaved. The best packets sizes were found for each different word sizes. The packet sizes were found out in that manner, that a ball park values was defined so as to hit those packet sizes that give the best encoding time for the specific word size. A lookup was constructed for every word size and the corresponding packet size that showed the best encoding times.

9. Packet Size
Choosing the packets size is important. A Large packet size causes cache misses and a small packet sizes result in worse XOR behavior. The packet sizes are only important to CRS codes and other RAID 6 codes. RS codes are not concerned with packet size as the encoding does not involve encoding in term of packets. The effect of modifying packet sizes in CRS is shown in fig:7. All the packets tested on CRS of the Jerasure. The values packet sizes are tested with k=10, m=6 and w=8.

10. Encoding Times

Fig 8 Encoding Times Now, we measure the encoding speeds of the codes. The results are at [10, 6] k and m values. The graph is plotted with word sizes against the encoding speed. We first take CRS codes into consideration. The optimized CRS of Jerasure and CRS of Luby are almost the same. The Jerasure CRS optimized codes implement a generator matrix where the number of ones is reduced. The reduced ones help in decreasing the number of XORs. When the number of XORs is reduced, so are the number of operations that result from that. The Jerasure codes also apply a kind of schedule so as to not to traverse any of the matrices and make the performance slower. The Luby CRS does not use any of these techniques but its simple encoding process results in its analogous performance to Jerasure. What Luby does is it to check for a one in the generator and XORs it in the message packet. The RS codes of Zfec and RS Jerasure between them both Jerasure performs better the reason why Zfec is slower most of the stuff us hardcoded and comes in the way of the code and making it run faster. Now coming to the RS codes, the RS codes do not perform as well as they do with CRS codes because: The Vandermonde matrices. The RS codes work on a word by word basis.

The Vandermonde matrices harm the performance. The Cauchy matrices change the multiplication to a series of XORs and the encoding speed seems to fall for every increment in CRS.

11.Decoding Times

Fig 8 Encoding Times The decoding times are depicted in Fig 8. The decoding is tested for recovering m files. The decoding is slower in all codes except the Jerasure codes. Optimizing the generator matrix does not drastically slow down the decoding but does affect the performance. One can notice the decoding is slower in Luby it is mainly because decoding does not follow a schedule as it does in Jerasure. The decoding is applied to files where m files have been erased and the algorithm is subjected to recover the m files. This would be the worst case scenario for any decoding algorithm. The reason why higher word sizes are not shown The Jerasure decoding module crashes once it is set to decode for higher word sizes. The program hits an assertion and aborts. The program was started up again using the valgrind debugger but did not match the early decoding speeds.

12.Conclusion
The CRS has an upper hand in all the encoding times. The RS codes even though simple are slower. The RS codes are still existent because of their error correction abilities. The CRS codes do not support any error correction. If the best open source codes were to be chosen for the CRS codes. A good choice would be Jerasure not only for the high encoding speed but also for the good documentation it comes with. Luby shows good encoding times but cannot work for higher word sizes as the code does not allow. In RS codes the Zfec codes easy to use but are very rigid in terms of changing parameters. The Jerasure Reed Solomon codes perform well.

The encoding speeds decrease when the word sizes are increased. The reason is because of the machine has a small cache. There is a tradeoff between sending a lot of data at once to be encoded which results in cache misses. While sending less data results in underutilization. Encoding is good at w= 16 because it fits the machines cache/memory footprint.

org/pypi/zfec, 2008. [9] The zfec-dev Archives http://allmydata.org/pipermail/zfec-dev/ [10] James S. Plank,A Tutorial on Reed-Solomon Coding for Fault-Tolerance in RAID-like Systems.

References
[1]
J. S. PLANK, J. LUO, C. D. SCHUMAN, L. XU, ANDZ. WILCOX-O'HEARN. A performance evaluation and

Examination of open-source erasure coding libraries for Storage.

[2] SHU LIN. Error Control Coding: Fundamentals

and Applications

[3] M. S. MANASSE , C. A. THEKKATH

SILVERBERG .

AND A.

A Reed-Solomon Code for Disk Storage, and Efficient Recovery Computations for Erasure-Coded Disk Storage

[4] BLOMER, J., KALFANE, M., KARPINSKI, M.,KARP, R.,

An XOR-based erasure-resilient coding scheme. Tech. Rep. TR-95048, International Computer Science Institute, August 1995.
LUBY, M., AND ZUCKERMAN, D.

[5] PLANK, J. S., SIMMERMAN, S., AND SCHUMAN,

C. D. Jerasure: A library in C/C++ facilitating erasure coding for storage applications - Version 1.2. Tech. Rep. CS-08-627, University of Tennessee, August 2008.

[6] JAMES S. PLANK, SCOTT SIMMERMAN, CATHERINE

D. SCHUMAN http://www.cs.utk.edu/~plank/plank/papers/CS08-627.html

[7] LUBY, M. Code for Cauchy Reed-Solomon

coding.Uuencoded tar file: http://www.icsi. berkeley.edu/luby/cauchy.tar.uu, 1997. [8] WILCOX-OHEARN, Z. Zfec 1.4.0. Open source code distribution: http://pypi.python.