NJS@ibm.com (Nicholas J. Simicich) (12/04/90)
All parity checking does is reduces the chance of an undetected error. It does not eliminate it. I've worked with digital and modem communications for some years now. Although rare, I've been shown garbled data which passed crc-16 checks three times now in my career. (This data was collected during traces, or in other cases where people were looking for garbled data because of a prior occurence.) The answer was, "It happens, and you should have a second end-to-end check on correct transmission, and not rely on link level reliability." The point is that something like TELECOM Digest acts as a lightning rod for unusual events. For any particular Return*Call, it is almost a certainty that, yes, the system will function correctly, and so forth. For any particular occurence unusual enough to report to TELECOM Digest, I'd put the odds at no better than 50%. :-) As for your comment about parity checked memory: All parity does is to raise the bar. Some number of failures will be single bit, and will be detected by [parity, ecc, etc.]. Some much smaller number of errors will be multi-bit, and with the pattern of affected bits such that they will not be detected (any two bit error for parity memory, for example). And you might remember the report a while back, I think in Telecom, but it might have bee in one of the TCP/IP lists, about this particular high speed (rf or something) modem that frequently constructed bytes that were in error but which produced the same incremental CRC change as the original bytes that were not in error. I'm sure there are other fun examples. To finalize, by putting a little twist on your analogy: TELECOM Digest is a zoo of the unusual. In a zoo, zebras are just as likely as horses. Nick Simicich (NJS at WATSON, njs@ibm.com) ---SSI AOWI #3958, HSA #318 [Zookeeper's Note: Thank you very much for an unusual and different response. PAT]