The week went by and this was left unanswered. Usually I research a bit to treat anything on these threads. This time, I’m on the phone, so I went lazy and directly to chatgpt. Hopefully this is not an AI hallucination and it sheds some light for you.

The performance difference you’re observing between AES128-CTR and AES128-GCM in OpenSSH with X11 forwarding can be attributed to several factors, including the nature of the ciphers and hardware acceleration support.

AES128-CTR vs AES128-GCM

1. Cipher Characteristics:

   • AES128-CTR (Counter Mode): This mode turns a block cipher into a stream cipher. It is generally faster because it can be parallelized and does not require padding.
   • AES128-GCM (Galois/Counter Mode): This mode provides both encryption and authentication (integrity check). The additional authentication step can introduce overhead, making it slower compared to CTR mode.

2. Hardware Acceleration:

   • AES-NI Support: Modern CPUs support AES-NI (Advanced Encryption Standard New Instructions), which accelerates AES operations. Both CTR and GCM modes can benefit from AES-NI, but the extent of the acceleration can vary.
   • GCM Overhead: Even with hardware acceleration, GCM mode has additional computational overhead due to the authentication process. If the hardware acceleration is not fully utilized or if the implementation is suboptimal, this overhead can become more pronounced.

Checking Hardware Acceleration

To determine if your system is using hardware acceleration for AES operations, you can check the following:

1. CPU Support:

   • Verify if your CPU supports AES-NI by checking the CPU flags:

     grep aes /proc/cpuinfo
     

   • If you see aes in the output, your CPU supports AES-NI.

2. OpenSSL Benchmark:

   • Run an OpenSSL benchmark to see the performance difference between CTR and GCM modes:

     openssl speed -evp aes-128-ctr
     openssl speed -evp aes-128-gcm
     

   • Compare the results to see if there’s a significant difference in performance.

3. SSH Configuration:

   • Ensure that your OpenSSH configuration is optimized for hardware acceleration. You can specify the ciphers in your SSH configuration file (/etc/ssh/sshd_config for the server and /etc/ssh/ssh_config or ~/.ssh/config for the client):

     Ciphers aes128-ctr,[email protected]
     

   • Restart the SSH service after making changes:

     sudo systemctl restart ssh
     

Conclusion

The performance difference between AES128-CTR and AES128-GCM is expected due to the additional authentication overhead in GCM mode. Ensuring that your system is utilizing hardware acceleration (AES-NI) can help mitigate some of this overhead, but GCM will generally still be slower than CTR. If performance is critical and you do not need the additional authentication provided by GCM, sticking with CTR mode might be the better option.

I assume this is an old laptop? If you’re able to remove the battery, as in the old models, you can measure it’s full milliamperes when at a 100%. It’s probably going to show a lower value than what’s reported by the user guides. From what you tell, I’d expect something as low as 1.5k… Beware that removing batteries with tools and so on might make them explode and is many times, just not an option.

Perhaps you can even see this in the BIOS. Some modern BIOS might even tell the number of charging cycles, allowing you to infer it’s worn out. Chances are, you need a new battery. Which is tricky, since oftentime the “new” battery was sitting at some store but was manufactured by the company when the laptop model was fresh.

Switch the kernel power governer to power saver

You could utilize the server/client functionality over the local network instead of using the same process.

So you could point the other users to the machine’s local address and they would automatically find the Pipewire server. Maybe? I guess? It’s just a theory.

https://wiki.archlinux.org/title/PipeWire#Sharing_audio_devices_with_computers_on_the_network

This thread seems to have what you’re looking for.

https://bbs.archlinux.org/viewtopic.php?id=265878

According to the thread, its possible to provide system-wide usage by enabling this option at build time:

-Dsystemd-system-service=enabled

Or it seems like you could share it over the local network by editing the Pipewire config file and making an environment variable. (See post #5.)

Or you could

Just add the “player” user to the “audio” group

according to post #8.

Note: it seems like Pipewire runs on port 4713. So the server would run on 0.0.0.0:4713, I guess.

Are you trying to do this over ethernet or WiFi?

If you’re trying to use wifi that connection needs to be stellar for this to work well. No over-lapping channels with the neighbours and not too many clients.

If you’re experiencing this on a wired connection, look into if your gear supports jumbo frames and confirm it’s a gigabit link.

Try using Vulkan mode for BG3.

Oh, tough one. I don’t know what’s that protocol. But I guess it’s not tied to WiFi. So, How about getting a cheap ethernet switch? That’s how I connect devices in my living room to the router given by ISP that’s on the other side of the wall.