3 ms·

This is not what CRC's are used for. CRC's are faster to compute, which really matters on Gbit network links. Also CRC's can allow you to not only detect errors

by tyho 12y ago

This is not what CRC's are used for. CRC's are faster to compute, which really matters on Gbit network links. Also CRC's can allow you to not only detect errors but fix them within a certain threshold without retransmitting.

PhantomGremlin 12y ago
You're of course correct that CRCs are very useful for low level operations such as individual Ethernet packets. But I was trying to respond to scenarios such as at the start of the article: You want to send data from point A to point B. ... you should use a CRC so you can detect errors. I think that's obsolete thinking. Yes, you can use a CRC for checking individual blocks being transferred. But you're much better off also verifying a complete data transfer using something like SHA-256. When, 25 years ago, PKZIP stored a 32 bit CRC together with a file, that was great for its time. But nowadays an archiver should use something more robust, such as SHA-256. I've personally encountered miscorrections on the old ST-506 disk drives because the 32-bit CRC used was junk. People like Neal Glover gave us much better computer generated polynomials. The industry switched to better schemes such as cross-interleaved Reed Solomon. And that was the extent of the error detection and correction. But now we know better. Given how close to the bleeding edge disk drives are, it's probably necessary that they continue to do error correction for each sector (although that has been debated). But a system is better off overlaying that with software such as ZFS which uses SHA-256 on individual blocks and continues up to the root node, thereby creating a Merkle tree which provides very strong data integrity guarantees. That's the point I was trying to make. In the old days we used CRC for everything, because we didn't know better. Nowadays we can continue to use CRC at the lower levels, but we should add SHA-256.

by tyho 12y ago

PhantomGremlin 12y ago

You're of course correct that CRCs are very useful for low level operations such as individual Ethernet packets. But I was trying to respond to scenarios such as at the start of the article: You want to send data from point A to point B. ... you should use a CRC so you can detect errors. I think that's obsolete thinking. Yes, you can use a CRC for checking individual blocks being transferred. But you're much better off also verifying a complete data transfer using something like SHA-256. When, 25 years ago, PKZIP stored a 32 bit CRC together with a file, that was great for its time. But nowadays an archiver should use something more robust, such as SHA-256. I've personally encountered miscorrections on the old ST-506 disk drives because the 32-bit CRC used was junk. People like Neal Glover gave us much better computer generated polynomials. The industry switched to better schemes such as cross-interleaved Reed Solomon. And that was the extent of the error detection and correction. But now we know better. Given how close to the bleeding edge disk drives are, it's probably necessary that they continue to do error correction for each sector (although that has been debated). But a system is better off overlaying that with software such as ZFS which uses SHA-256 on individual blocks and continues up to the root node, thereby creating a Merkle tree which provides very strong data integrity guarantees. That's the point I was trying to make. In the old days we used CRC for everything, because we didn't know better. Nowadays we can continue to use CRC at the lower levels, but we should add SHA-256.