The last log of #miniMAC - Not an Ethernet Transceiver  had concluded that the association of two convolutional blocks of different types but complementary characteristics creates an excellent error detector, on top of thorough scrambling. But the use of a gPEAC becomes dubious, it was used for two reasons:

• PEAC w18 is not known for being perfect or maximal
• PEAC w18 has poor mixing, a generalised type is better.

However it was found that

• gPEAC18 uses 2 cycles instead of one, reducing the throughput
• the added NRZ-Hamming preprocessing totally solves the mixing issue
• It is probably not necessary to beeven close to maximal.

So PEAC w18 is back in the race to reduce the latency and gates count. But I realise that I know almost nothing about it !

I looked back at the logs and found quite little.

• 19. Even more orbits ! : primary orbit of 18 : 172.662.654  (instead of 34.359.738.368 to pass, or 0.5%)
• 44. Test jobs :     18: Total of all reachable arcs: 68719736689
• 90. Post-processing : Width=18 Total= 34359868344 vs 34359869438 (missing 1094)

The missing iterations hint at a small "island" that can't be reached from Y=0 and that's a bit worrying.

I don't know the number and sizes of the other orbits. Fortunately I could reuse fusion_20220109.tgz and the logs logs_p7k_03-21.tbz.

• 11 orbits of length 15,696,605
• 198 orbits of length 172,662,655

In practice, it is not plausible to send 15 million words with the same value.

But the nature of the 1094 missing points is still disturbing and I'll have to program it out. And I only have 32GB of RAM at best, so the 67 billion points can't be represented as bytes. I'll have to do with bits. Filling the RAM with the 198+11 orbits should not be a problem since I have their coordinates, then I'll see which bits are untouched. A few kilopoints should not be hard to process then.