🐛 BUG: Power consumption/many wake-ups in laptop use case

[inducer]

What version of nebula are you using?

1.6.1+dfsg-3+b6

What operating system are you using?

Debian Linux

Describe the Bug

When I run a Nebula node (with a quiescent link) on my laptop when running on battery (and while connected to the Internet), it is the number one cause of wake-ups, using to the tune of a half Watt, all according to powertop. (This is on a Raptor Lake Thinkpad, in case it matters.) There are about 60 wakeups per second, which seems kind of excessive. Is there anything that could be done to reduce this number?

Since, according to the examples, laptops are part of the intended use case, this may be an important contribution to making Nebula more usable in that setting.

Logs from affected hosts

No response

Config files from affected hosts

pki:
  # The CAs that are accepted by this node. Must contain one or more certificates created by 'nebula-cert ca'
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/arc.crt
  key: /etc/nebula/arc.key

static_host_map:
  '10.33.0.1': ['144.76.64.235:4242']

lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - '10.33.0.1'

logging:
  # panic, fatal, error, warning, info, or debug. Default is info
  level: info
  # json or text formats currently available. Default is text
  format: text

punchy:
  punch: true

listen:
  host: "[::]"
  port: 4242

tun:
  disabled: false
  dev: nebula1

firewall:
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m

  outbound:
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: icmp
      host: any
    - port: 22
      proto: tcp
      host: any

[johnmaguire]

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.

[inducer]

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.

[johnmaguire]

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.

[johnmaguire]

Hi @inducer - I was wondering if you had any updates to share. In October you mentioned you'd re-test with the latest version of Nebula (now v1.8.2). Additionally, I wondered if you had tweaked any of the intervals mentioned, and if it had a positive effect on the numbers you're seeing.

Cheers!

[johnmaguire]

Hi @inducer - I'm still not clear on what a successful outcome for this ticket looks like. Without comparing power consumption to other similar utilities, it's not clear to me that there's excessive power consumption occurring here. And without testing various configurations, I don't know whether it's due to the specific tuning of your config.

If you are able to test with some tools similar to Nebula and see a significant difference, please let us know! Additionally, if you test out changing some of those intervals I mentioned, I'd love to hear the results.

In the meantime, I'm closing this ticket out for inactivity.