higher cpu utilization when idling (384.19 vs 386.3_0)

[Jumpstarter]

Jitterentropy serves no concreate point on these older models. Running it in debug mode shows it never managed to get the entropy pool above 200 (while in comparison on HND models it reaches above 1000). That's why it's constantly waking up trying to refill the pool. and never succeeding - jitterentropy will wake up every two seconds until it can get the pool above 1024, which it never can.

Running haveged seems to keep the entropy pools well above 1000 on these older models without any real impact to the cpu use. I know you are not too fond of it though.

 

[RMerlin]

the fact that it is keeping it above 100 is good enough

That's the thing. It's not keeping it above 100 - that is where it sits naturally. Look at the debug log I posted, see how there is no change to the pool size between jitterentropy interventions.

EDIT: sorry, here's the debug log I'm referring to (I emailed it to Asus, but forgot I hadn't posted it here):

admin@rtac66b1:/tmp/home/root# jitterentropy-rngd -vvv
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random
jitterentropy-rngd - Debug: Install termination signal handler
jitterentropy-rngd - Debug: Install alarm signal handler
jitterentropy-rngd - Debug: Polling /dev/random
jitterentropy-rngd - Verbose: Wakeup call for alarm on /proc/sys/kernel/random/entropy_avail
jitterentropy-rngd - Debug: Insufficient entropy 156 available 
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random
jitterentropy-rngd - Debug: Install alarm signal handler
jitterentropy-rngd - Debug: Polling /dev/random
jitterentropy-rngd - Verbose: Wakeup call for alarm on /proc/sys/kernel/random/entropy_avail
jitterentropy-rngd - Debug: Insufficient entropy 132 available 
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random
jitterentropy-rngd - Debug: Install alarm signal handler
jitterentropy-rngd - Debug: Polling /dev/random
jitterentropy-rngd - Verbose: Wakeup call for alarm on /proc/sys/kernel/random/entropy_avail
jitterentropy-rngd - Debug: Insufficient entropy 132 available 
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random
jitterentropy-rngd - Debug: Install alarm signal handler
jitterentropy-rngd - Debug: Polling /dev/random
jitterentropy-rngd - Verbose: Wakeup call for alarm on /proc/sys/kernel/random/entropy_avail
jitterentropy-rngd - Debug: Insufficient entropy 132 available 
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random
jitterentropy-rngd - Debug: Install alarm signal handler
jitterentropy-rngd - Debug: Polling /dev/random

 

[RMerlin]

Running haveged seems to keep the entropy pools well above 1000 on these older models without any real impact to the cpu use. I know you are not too fond of it though.

I considered using haveged for older models, but considering these are aging models, I didn't feel like spending more time on testing it or devoting development time unique to these four older models. I couldn't even get the Entware version of it to run last time I tried to see if it worked better than jitterentropy on these older models.