News for hackers. Stuff that matters.

A comment on Reed-Solomon coder computing one million ECC blocks at 1 GB/s. Parent comment

Re:Reed-Solomon coder computing one million ECC blocks at 1 ... by Bulat-Ziganshin on Tuesday May 09, 2017 @05:18PM (#14303883)
when encoding larger blocks, they are just split into multiple small words. f.e when GF(256) is used, each word is just a single byte. then you have f.e. 20 data blocks and encode corresponding words of each blocks as a single group, and each group generates a single word for each of parity blocks. you may consider it just as interleaving

overall, encoding in GF(2^n) is faster when n is smaller (since you need smaller multiplication tables that better fits into cpu cache). But OTOH encoding with K data+parity blocks require that 2^n>K, so for best speed n is choosen as small as possible among 8/16/32 depending on the K value

[ Parent | on HN ]
Re:Reed-Solomon coder computing one million ECC blocks at 1 ... by 112233 on Wednesday May 10, 2017 @03:02AM (#14306380)
what I meant is that smallest unit that RS can correct is one word, which usually is byte. So 8 bit errors in one word can be restored with less EC than 8 bit errors in different words.

In case of BCH, location of bit errors does not influence error correction strength, so it is more suited to correcting independant bit errors, while RS is more suited for bursty/whole block errors.

[ Parent | on HN ]