Den ons 21 aug. 2024 kl 21:23 skrev Sylvain <sylvain@sysau.com>:
> This is not an algorithm, it is really three programs running concurrently and using
> unmitigated memory access in a clever way that allow imperfections in hardware to
> be observed all the way into the software layer.
>
> I hope it can be useful.

I don't think it is, at least not for that purpose. Apart from Theos
correct comments on this being far too late in the game for stirring
the kernel entropy pool, the program in itself has some issues.

First of all, the comment below makes it slightly uncomfortable to
know there should be a better list but we are to test this with
"worse" constants?

> //replace with large prime numbers between (2^63 > 2^64) for best results
> int C4_hash_algo(volatile uint64_t * in, volatile uint64_t * out) {
>   uint64_t primes[128] = {2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37,
>           41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107,

Secondly, and perhaps more importantly, it is dog slow.

I tried it on a dual-core octeon (2x1GHz) and this is how top looks
like while it runs:

load averages:  2.91,  1.00,  0.38                  edgepro.inet6.se 08:14:43
48 processes: 46 idle, 2 on processor                      up 8 days 18:00:32
CPU0 states: 99.0% user, 0.0% nice, 0.8% sys, 0.2% spin, 0.0% intr, 0.0% idle
CPU1 states: 98.2% user, 0.0% nice, 1.8% sys, 0.0% spin, 0.0% intr, 0.0% idle
Memory: Real: 286M/1480M act/tot Free: 6623M Cache: 1005M Swap: 0K/211M

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
51096 jj        10    0 4448K 2320K onproc/1  nanoslp   2:51 191.94% thr-rng
72981 jj         2    0 5632K 6272K sleep/0   kqread    0:01  0.15% tmux

It eats more or less both cores, and it takes the program ages to
produce 32k of entropy

$ ./thr-rng |dd of=/tmp/junk bs=4k count=8
32768 bytes transferred in 83.059 secs (394 bytes/sec)

..so there is no way I would wait long enough for this program to
create 1M of entropy so one
could feed it to DieHarder or some other entropy test suite just to
validate how good or bad this is.

With that in mind, even for userspace I think I will stick to the
octrng0-assisted kernel entropy pool, which can give me these speeds
instead:

$ dd if=/dev/random of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 16.199 secs (66284451 bytes/sec)

-- 
May the most significant bit of your life be positive.