Skip Navigation
Linux @programming.dev adr1an @programming.dev

[Weekly thread] GNU+Linux help: ask anything!

26
26 comments

  • I noticed a pretty extreme difference in performance in openssh when using x11 forwarding when I touch the cipher suite.

    AES128-ctr vs AES128-gcm on kubuntu 22.04.

    I was wondering if anyone could shed some light into that. I'm mostly curious if it's not using hardware acceleration when I switch it to GCM.

    • 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,aes128-gcm@openssh.com
        • 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've recently made it to Act 3 in Baldur's Gate 3, and my integrated graphics on my laptop aren't keeping up, so now I have installed it on my desktop machine and am using Steam Remote Play (my desktop is plugged into the TV, it's not a proper desktop setup).

    Often, the Steam connection drops out and the game keeps playing on the desktop but I can't connect back to it from the laptop.

    Any suggestions on what I could do to either stop losing the connection or let me connect back to it after it drops?

    Set up:

    • Laptop has Nobara Gnome spin
    • Desktop has Mint Cinnamon
    • Bought BG3 on GOG, installed through Heroic Launcher, added to Steam as non-steam game to play it.

    • 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.

      • Laptop is on WiFi, desktop is on ethernet.

        Laptop is directly next to an access point that is connected via ethernet, though I know the network is not super stable. I often have to restart the ISP router after it drops out.

        I am confused why Steam doesn't let me reconnect though. Normally if the game is running you can open Steam and choose to connect to it. But I don't get this option, it's like it's forgotten that it started the game.

        In Steam it's set to use Proton and I select the bg3.exe or whatever it's called, not the bg3_dx11.exe. Is this using Vulcan mode?

    • 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.

      • The laptop is connected via WiFi (to an access point directly next to me), I don't have a LAN port for it at the moment.

        The desktop is connected via ethernet.

        Normally Steam will let you reconnect to a game that's already playing, but I don't seem to have that option. It's like it forgets it's running.

  • How do I configure my Linux, on a laptop, to consume as little battery as possible?

    A bit of context: one of my laptop ran Ubuntu, with acceptable battery drain (up to 3h30 of usage, running desktop applications: Firefox, terminal, vim, etc). This is a high-end laptop: 12 AMD Ryzen + AMD Rembrandt.

    I switched to open use, and now battery drains in one hour, running the exact same applications. Installed tuned, selected power save, tried power top, applied different parameters, etc, but no result: battery still dies after 1h. No improvement at all.

    I am going to investigate on my own, but any help is greatly appreciated.

    • 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

  • I want to run PipeWire as a system user and have multiple login users access it. My current hack is to run it as one login user and then do something like:

    export XDG_RUNTIME_DIR=/run/user/1001

    Where 1001 is the user ID. Is there a cleaner approach?

    • 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.

You've viewed 26 comments.