higher cpu utilization when idling (384.19 vs 386.3_0)

[bughit]

RT-AC68U

router is idling (no appreciable traffic), wifi is off, all extra features beyond core routing are off, nat accel is on
so the cpu should have nearly nothing to do

on 384.19 its ~ 1-5

on 386.3 it fluctuates, spiking to ~15

haven't had a chance to look at top as I downgraded to compare

 

[Tech9]

Is this post for information only or you have some issues with the router?

 

[Adooni]

how long after update? did you wait more than 1h before test it?

 

[geobernd]

Now that I am looking I see the same - and the top process that seems to be causing these spikes is
/usr/sbin/jitterentropy-rngd

I am pretty sure I have seen this before 386.3 but never paid attention to it since I don't have any performance issue here (but my ISP is not the fastest at 120/18)

Just an FYI to help with my observation...

 

[bughit]

Now that I am looking I see the same - and the top process that seems to be causing these spikes is
/usr/sbin/jitterentropy-rngd

I am pretty sure I have seen this before 386.3 but never paid attention to it since I don't have any performance issue here (but my ISP is not the fastest at 120/18)

Just an FYI to help with my observation...

386.2 (2-Apr-2021)
  - NEW: Added jitterentropy-rngd daemon to HND routers.  This will
         ensure sufficient entropy is generated early on at
         boot time, reducing boot stalls caused by insufficient
         entropy for the kernel's random number generator,
         and also generally improves security related to
         crypto operations by the router.

@RMerlin Is this expected from this daemon?

 

[RMerlin]

Yes. It seems these older kernels have trouble keeping their entropy pool well fed, so jitterentropy has to frequently refresh it to ensure sufficient entropy for more reliable crypto generation.

 

[bughit]

Since there's a tradeoff involved, perhaps its use should be optional?

 

[RMerlin]

Since there's a tradeoff involved, perhaps its use should be optional?

What tradefoff? 1-3% CPU usage now and then on a dual core CPU won't have any perceptible impact. CPUs are meant to be used, not to be kept dormant at a constant 0% usage.

If for some odd reason it does for you and you don't value having more secure crypto generation, you can kill the process.

 

[bughit]

It's not 3 but 15. Yes the CPU is meant to be used, but not wasted. It's a limited resource and one does not allow it to be abused by unwanted processes on one's desktop and this is no different. It's certainly possible to use the router without the need for more secure crypto, so paying the constant CPU cost for this should be optional.

 

[bughit]

you can kill the process.

What's the recommended way of doing that? Is it the services-start user script, containing "service jitterentropy stop"?

 

[ColinTaylor]

There's no service associated with jitterentropy so the command to use in services-start is:

killall jitterentropy-rngd

 

[RMerlin]

It's not 3 but 15. Yes the CPU is meant to be used, but not wasted. It's a limited resource and one does not allow it to be abused by unwanted processes on one's desktop and this is no different. It's certainly possible to use the router without the need for more secure crypto, so paying the constant CPU cost for this should be optional.

On my own RT-AC66U_B1 I have never seen CPU spikes reaching that high.

 

[bughit]

here's an attempt to catch a spike in top

 

[Tech9]

I still don't see the issue. Does it affect in any way your router's performance?

 

[SomeWhereOverTheRainBow]

I still don't see the issue. Does it affect in any way your router's performance?

Comparatively , to the OP, this is the same as putting bricks in a blender.

 

[Tech9]

I have all 3 similar routers RT-AC66U_B1, RT-AC68U and RT-AC1900P and none of them has any issues. I may have missed something.

 

[RMerlin]

I still can't see CPU usage above 2-3% on my own RT-AC66U_B1, however after running some tests in debug mode, it seems that the benefits of jitterentropy on these older models is negligible compared to on all modern routers. I will re-disable it again on non-HND model in 386.3_2.

Maybe something on your router was constantly draining the pool, causing it to be triggered even more frequently than in my test case (mine only came out of sleep every two seconds).

Jitterentropy attempts to reach an entropy pool of at least 1024. For some unknown reason these older routers never seem to get above 150-200, causing the daemon to constantly attempt to increase it, with very little success (it seems to only be helpful if the pool gets totally depleted, by refilling it somewhat faster).

 

[SomeWhereOverTheRainBow]

I still can't see CPU usage above 2-3% on my own RT-AC66U_B1, however after running some tests in debug mode, it seems that the benefits of jitterentropy on these older models is negligible compared to on all modern routers. I will re-disable it again on non-HND model in 386.3_2.

Maybe something on your router was constantly draining the pool, causing it to be triggered even more frequently than in my test case (mine only came out of sleep every two seconds).

Jitterentropy attempts to reach an entropy pool of at least 1024. For some unknown reason these older routers never seem to get above 150-200, causing the daemon to constantly attempt to increase it, with very little success (it seems to only be helpful if the pool gets totally depleted, by refilling it somewhat faster).

I would leave it a lone RMerlin, as this is just one person confused at why the CPU has to be used for anything. From my test, jitterentropy has not broken any functionality on these earlier models and does not hurt to have them running.

 

[RMerlin]

I would leave it a lone RMerlin, as this is just one person confused at why the CPU has to be used for anything. From my test, jitterentropy has not broken any functionality on these earlier models and does not hurt to have them running.

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.

 

[SomeWhereOverTheRainBow]

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.

the fact that it is keeping it above 100 is good enough 100-200 range should be fine, is there away to set the arguments for that range using Jitterentropy so it knows to only run on those models for that range requirement?