undefined | Better HN

0 pointsc0l01y ago0 comments

To "fix" performance (i.e., increase throughput by close to 35%) one has to mess with the "energy performance bias" on the (Broadwell) platform, e. g. using x86_energy_perf_policy[0] or cpupower[1]. Otherwise, the CPUs/platform firmware will select to operate in a very dissatisfactory compromise between high-ish power consumption (~90W per socket), but substantially less performance than with having all idle states disabled (= CPU in POLL at all times, resulting in ~135W per core) completely. One can tweak things to reach a sweet spot in the middle, where you can achieve ~99% of the peak performance at very sensible idle power draw (i.e., ~25W when the link isn't loaded).

With Zen3, this hardly mattered at all.

I also got to witness that using IPv4 for the wireguard "overlay" network yielded about 30% better performance than when using IPv6 with ULA prefixes.

[0]: https://man.archlinux.org/man/x86_energy_perf_policy.8 [1]: https://linux.die.net/man/1/cpupower

0 comments

sulandor1y ago

tyvm

came across the epp thing once or twice but remained in the land of 'echo performance |tee /sys....'

if you can share anything related to your sweetspot

the v6-performance issue reeks of mtu

c0l0OP1y ago

> if you can share anything related to your sweetspot

For Broadwell in particular, it is enough to avoid power states lower than C1E, in my experience.

And no, MTU plays no part in the degraded IPv6 performance. I think it's rooted in a less efficient route lookup mechanism (Linux 6.7 was what I tested with), but I did not take the time to check properly.

j / k navigate · click thread line to collapse