🐛 BUG: Power consumption/many wake-ups in laptop use case
inducer opened this issue · comments
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
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.
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.
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.