• sighofannoyance@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    11 months ago

    This proves once and for all that Linux is the superior platform!

    when was the last time you heard any such news for PC or MAC?

    • Aganim@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      11 months ago

      when was the last time you heard any such news for PC

      A few seconds ago, when I read that the new Linux kernel contains TCP related performance improvements!

  • AutoTL;DR@lemmings.worldB
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 months ago

    This is the best summary I could come up with:


    This effort has been around optimizing cacheline consumption and adding safeguards to ensure future changes don’t regress.

    In turn this optimizing of core networking structures is causing TCP performance with many concurrent connections to increase by as much as 40% or more!

    This patch series attempts to reorganize the core networking stack variables to minimize cacheline consumption during the phase of data transfer.

    Meanwhile new Ethernet driver hardware support in Linux 6.8 includes the Octeon CN10K devices, Broadcom 5760X P7, Qualcomm SM8550 SoC, and Texas Instrument DP83TG720S PHY.

    NVIDIA Mellanox Ethernet data center switches can also now enjoy firmware updates without a reboot.

    The full list of new networking patches for the Linux 6.8 kernel merge window can be found via today’s pull request.


    The original article contains 387 words, the summary contains 124 words. Saved 68%. I’m a bot and I’m open source!

    • fosforus@sopuli.xyz
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      11 months ago

      Online games don’t typically have many concurrent connections, though, do they? Just the one.

      • ⲇⲅⲇ@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        11 months ago

        I’m not an expert, but I suppose as this patch is on the kernel and not on the game, this will still improve any connection your kernel needs to do, like sending telemetry of your anti-cheat engine and other apps that make TCP requests while you are playing online games.

      • ⲇⲅⲇ@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        11 months ago

        Yeah, that would make sense as opening TCP connections is not really viable for low latency, hahaha.

        • taladar@sh.itjust.works
          link
          fedilink
          arrow-up
          0
          ·
          11 months ago

          Opening the connections is one thing but resends and stream ordering can also cause issues since they might delay the latest information reaching the user space application even if the packet for them has actually arrived just because some earlier packet has not. There can also be issues with implementations waiting for enough data to be available before sending a packet.

        • Atemu@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          11 months ago

          Depends. There was that one F2P COD clone which used TCP and IIRC it did fine?

          • icydefiance@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            11 months ago

            If your connection is stable, the latency will more or less be the same, but TCP will consume more bandwidth because of acknowledgement packets, making it harder to keep your connection stable.

            On an unstable connection, TCP latency will skyrocket as it resends packets, while UDP will just drop those packets unless the game engine has its own way of resending them. Most engines have that, but they only do it for data that is marked as “important”. For example using an item is important, but the position of your character probably isn’t, because it’ll be updated on the next tick anyway.

    • Karna@lemmy.ml
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      11 months ago

      The test data on article is about server setup which is the right use case for this change.

      Moreover the L3 cache on CPU is what makes significant difference, IMO.

      If that is true, not sure how much improvement consumer-grade desktop will see, given that most consumer-grade CPU will not have that much L3 cache on chip.

      • AlexJD@feddit.uk
        link
        fedilink
        arrow-up
        0
        ·
        11 months ago

        AMD has been putting a lot of L3 cache on their consumer CPUs. The 5800X3D has 96mb of L3 cache.

          • Karna@lemmy.ml
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 months ago

            That’s definitely a CPU for server (unless you are a general consumer with lots of $ 🙂 ).

            • qupada@kbin.social
              link
              fedilink
              arrow-up
              0
              ·
              11 months ago

              There definitely are vendors ignoring common sense and putting socket SP5 on desktop boards.

              No argument about the price, I think list on these is something like $13k USD.

        • Karna@lemmy.ml
          link
          fedilink
          English
          arrow-up
          0
          ·
          11 months ago

          Yes, that’s true. Only if Intel follows the same in future.

          On a separate note, 5800X3D seems to be most efficient (throughput/watt) consumer grade CPU out there right now.

          • Atemu@lemmy.ml
            link
            fedilink
            arrow-up
            0
            ·
            11 months ago

            On a separate note, 5800X3D seems to be most efficient (throughput/watt) consumer grade CPU out there right now.

            Pretty sure the 7800x3D surpasses it and the 7950x3D is no slouch either.

    • OsrsNeedsF2P@lemmy.mlOP
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      11 months ago

      You’re not a cloud server that needs to run this many concurrent connections (probably)