Close

The second (as originally intended) application

A project log for PEAC Pisano with End-Around Carry algorithm

Add X to Y and Y to X, says the song. And carry on.

yann-guidon-ygdesYann Guidon / YGDES 12/18/2022 at 01:180 Comments

Have a look at N00N protocol : Header and payload checksums with PEAC !

To the curious, the first actual use of PEAC in a protocol is a scrambler for digital radio coms. But packet checksum is the application for which PEAC was initially developed.

There are 2 cases, both using 16-bit words :

  1. Header : 5 words (80 bits) are checksummed into 1 word (16 bits), giving a 20% overhead that should still cover the great majority of cases, since normally, error probability is proportional to the size of the data to protect. Here, the 96 bits should be quite safe and we should run actual Hamming distance tests.
    Note 1 : a higher overhead is OK for such a small structure, particularly because it is part of "parsing" the continuous stream and it is part of the resynchronisation process. Unlike MIDI (which uses the MSB of the bytes) or MPEG (that uses the value FF as a dlimiter) N00N has no inband/outofband signaling and must rely on pattern matching to detect the start of a valid packet. Adding 2 bytes of checksum increases (by 64Ki times) the chance to reject coincidences that could appear inside or outside of a packet. Further filtering (by ID, type, flags etc.) helps reject even more malformed or desynchronised packets.
    Note 2 : the checksum protects the payload size field.
    The fixed size allows a dedicated implementation that saves some instruction in the beginning and the end of the routine, by propagating invariants. Handy !
  2. Payload : variable size, that could reach up to 256Ki bytes, so the full output of the checksum (32 bits) is used. Normally messages should weigh around 200 bytes, or 50 pairs of 32-bit words. That's 2% overhead. Up to 4KiB is OK in theory though pretty unlikely. The checksum and the protocol are optimised for pairs of 16-bit words so they are very easy to manage and handle, with the least corner cases possible. I'm pretty proud of this "clean" reference implementation though some platforms can benefit from particular optimisations.

In both versions, I use the 3-variable code. It uses 2 operations to manage the carry for every 16-bit word. They may look overkill and may not affect the result as much, though this is a key difference between PEAC and other checksums (Fletcher in particular). Without these 2 operations (shift and mask that can execute simultaneously) the efficiency would drop, as some errors would not be distinguishable.

Since this is a simple practical application, it's a good foundation to measure Hamming distances and trace graphs, compare with other methods... Stay tuned.

Discussions