🐛 BUG: Power consumption/many wake-ups in laptop use case about nebula HOT 3 OPEN

Hi @inducer -

Thanks for the report. I see you're running 1.6.1+dfsg-3+b6 while the latest Nebula version is v1.7.2. Can you re-test with the latest version of Nebula in order to verify this behavior still exists? v1.7.0 has some improvements in this area.

What kind of traffic is your laptop receiving/sending through Nebula? Each packet Nebula processes is going to incur some overhead! ifconfig can give some hints at how many packets you've processed since starting dnclient, but setting up one of the stats tools and graphing packets would probably be more useful: https://nebula.defined.net/docs/config/stats/

defined1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1300
        inet 192.168.123.14  netmask 255.255.255.0  destination 192.168.123.14
        inet6 fe80::c83d:54d8:642a:6ea7  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 1462490  bytes 1604093122 (1.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1569642  bytes 113401859 (108.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Powertop isn't a tool that we've used before (for observing Nebula, or otherwise.) Have you compared Nebula against other similar tools (with the same traffic sent/received)? Packet processing does require some processing power and without context, it's hard to say whether the wakeups you're saying are abnormal or not.

from nebula.

I'll retry with 1.7.2 when I have a chance.

It's reasonable that processing packets will cost energy, but in my case, the link was quiescent, i.e. no packets going either direction. I was expecting Nebula to have close to zero cost (in terms of wakeups/power) in that scenario. This matters (to me at least) in that it would allow me to just leave Nebula running in the background and not having to manually turn it off and on whenever power consumption matters.

from nebula.

I'll retry with 1.7.2 when I have a chance.

It's reasonable that processing packets will cost energy, but in my case, the link was quiescent, i.e. no packets going either direction. I was expecting Nebula to have close to zero cost (in terms of wakeups/power) in that scenario. This matters (to me at least) in that it would allow me to just leave Nebula running in the background and not having to manually turn it off and on whenever power consumption matters.

Thanks for explaining. Here are some of the jobs that Nebula continues to perform even when no traffic is flowing:

• Updating the Lighthouse with its current IP addresses (lighthouse.interval, defaults to 10s)
• Keeping track of and pushing forward in-flight handshakes (handshakes.try_interval, defaults to 100ms)
• Emitting interface stats (stats.interval, defaults to 10s)
• Connection management (connectionManager.Run is non-configurable, will fire every 500ms)
• Conntrack management (firewall.conntrack.routine_cache_timeout, defaults to 1s)
• Re-querying for DNS hostnames in the static_host_map (static_map.cadence, defaults to 30s)

You may consider increasing some of these values to see if it improves your energy performance. Do note that increasing these values may increase the time it takes for a new connection to form or for a failed connection to recover.

from nebula.