UDPspeeder VS ParPar

It's been a while since I set it up, but iirc I ended up going with https://github.com/wangyu-/UDPspeeder

Pretty sure I used the suggested config and it's been working flawlessly in the background.

Or something like that. With wireguard, it's just a matter of pointing the config at the local socket for the fec tunnel (or any other type of tunnel, there was a dicussion about making it look like TCP http traffic the other day), so it's pretty much plug and play.

I just use nbd-server, nbd-client (kernel module nbd). While at home things are fine, when not at home things can get bad unless you use something like UDPspeeder <https://github.com/wangyu-/UDPspeeder> then you just need to deal with slower speeds.

I do backups with borg while connected through ethernet.

The good news is you can implement some kind of ghetto error-correction at a higher level. Set up a tunnel to your pbx with a VPN which supports FEC -- something like UDPspeeder and configure it to send duplicates or triplicates of every packet. In this case, you're sacrificing bandwidth to improve reliability.

All it needs is a bit of reed solomon encoding in the transport for additional reliability https://github.com/wangyu-/UDPspeeder

PAR2 creation (file-based error correction): the core routine here is GF(2^16) matrix multiplication. AVX512 has the GF2P8AFFINEQB instruction, which isn't present on any GPU that I know of, but massively accelerates GF multiplication. Without this instruction, you have to resort to emulating it via bitwise operations or lookup tables, which are much slower. I actually have an OpenCL implementation, but its performance is rather meh compared to CPU

Did you tried to use parpar for creating par2 files? Supposed to be much faster. https://github.com/animetosho/ParPar

I've been developing a performance oriented PAR2 tool (used for generating file-based redundancy for error correction), but without access to a lot of hardware, I don't have that much ability to tune it to various microarchitectures. Currently there's no real benchmark setup defined/implemented (though it shouldn't be hard to come up with one), and it certainly isn't tuned for the number of cores on EPYC, but I've never really thought PAR2 benchmarks would interest that many people.

QuickPar is ancient at this stage, however the PAR2 format hasn't changed since, so the concepts are still the same. For a more modern client, I generally recommend MultiPar. I've also written a PAR2 client, ParPar (CLI, or experimental GUI frontend), but it only supports creating PAR2s, not verify/repair.

Also this implementation of par is the fastest I've seen (for creation only thought) https://github.com/animetosho/ParPar

For PAR2, I did a benchmark comparison here of every tool, which you can use to make up your mind. par2j (Multipar) and phpar2 are Windows only, but work via Wine. ParPar only supports create, so you'll need to use a different client for verify/repair.