From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3D2E33B29D for ; Mon, 2 May 2022 18:54:03 -0400 (EDT) Received: by mail-ej1-x636.google.com with SMTP id j6so30336435ejc.13 for ; Mon, 02 May 2022 15:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=76fgnIvGyBtmrhf94uRYvKYhmzMGoH6ta7Q1A1WZOlI=; b=UfPh/LUHh9I2jUPzi240i4O+pZno5sSLNSRYU4Chk3p3Bk9OyXqG12ZEvsJZ+D+0rD d5NjEmsEODVJxlZP3bfQaARp6s6ui47/Iny/ikdqX6xJwMdJ7nSZGhqVRZT55t0mtAXK Vf6U4VBZ6rX24G3f0WC18ks0QBAt9krq15v4iu2V9FlXzFA75AxePAUzFuzYXmTRD6Us 5HRPq08/CYdd2LIWR4d9mTSiAFCvmcbHojDEVQXMHv/SJ0jIMIH5P+FFzFFTi3pKJbcb tQmIihYmv3Q0UBvrsQQQFtz5JU2DrxSXyMOagB+lt09hUCqeuvc6EebBVbEY94QrU67f 1uAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=76fgnIvGyBtmrhf94uRYvKYhmzMGoH6ta7Q1A1WZOlI=; b=S7GVwbifKUkFys3uyO7EjO5zps0ZHZX3ub7p9RIpP7/x4cL07AyfWz9QSm97VLxXE0 w0ErQDIE+Da6/dXuMKGeHSwZ6yDujaGHKHygcW2mKKNIIQR96npaL0eQWLrftTvKgIcv fI/4cmnr8eZYWJlDzdE1ql0YmxxiMPlujfJDcQ10+icYc11xGAf0p88G8P50pgAgrhmC pnp6ouEGuxQ2zN3rCi4plXYDBW0j3VgJ1zfeLCXMozwWVfYIZHLhdEaRTkx0TR1cir4t qAINJkz6A/7A1i7gO5s6msYw2EYcDcPytqQHBL856tO4Fdk3c1Vc4ije6sJY78GVATTr 4nqQ== X-Gm-Message-State: AOAM531/ECLWmpD3pSLXRkk/1beFwZqyc10CydxDE1RzHGIluejsuQgN 2JL/GY2X5p1OBj7NYkSCKBB3dopeBweje4SISJeBYQzUYIg= X-Google-Smtp-Source: ABdhPJzm1vuhzr2sNaFbdXS/MqgC78d23mdhdv2yzPaPKQ/MeOZJCz8+QpOlFeqPDKxGJiyODSWkc1GcnQQ05n6p3RI= X-Received: by 2002:a17:906:9749:b0:6ef:bc52:1f94 with SMTP id o9-20020a170906974900b006efbc521f94mr12910251ejy.666.1651532041863; Mon, 02 May 2022 15:54:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Mon, 2 May 2022 15:53:48 -0700 Message-ID: To: cerowrt-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] Fwd: Realtek RTL8156 devices defaulting to CDC-NCM instead of vendor mode, resulting in reduced performance X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2022 22:54:03 -0000 .6ms considered good. ---------- Forwarded message --------- From: Forest Crossman Date: Mon, May 2, 2022 at 3:49 PM Subject: Realtek RTL8156 devices defaulting to CDC-NCM instead of vendor mode, resulting in reduced performance To: , , Cc: , Hi, all, I recently purchased a pair of USB to 2.5G Ethernet dongles based on the RTL8156, and have so far been very happy with them, but only after adding some udev rules[0] to to take advantage of the r8152 driver by switching the devices from their default CDC-NCM mode to the vendor mode. I was prompted to use those rules to switch the driver because one of the adapters (based on the RTL8156A) would get very hot, up to 120 F (49 C) even while idle, and the round-trip latency directly between the pair of adapters was about 3 ms, and I couldn't help but wonder if maybe the vendor mode might be more efficient. After performing some tests of latency and power consumption, testing first with both adapters in NCM mode and then again with both in vendor mode, I proved my hunch correct. I discovered that, in a disconnected state, the RTL8156A adapter used about half as much power (0.64 W -> 0.30 W) while the RTL8156B adapter saw a 21% reduction in power (0.34 W -> 0.27 W). Similarly, in a connected-but-idle state the RTL8156A again saw about a 55% savings in power consumption (2.17 W -> 0.97 W) and a 40% savings in the RTL8156B adapter (0.94 W -> 0.56 W). It was only under full load that the fewest power savings were seen, with a reduction of only 15% in the RTL8156A (2.23 W -> 1.90 W) and no savings for the RTL8156B (0.96 W). Similarly, round-trip latency while idle went from 3 ms to 0.6 ms. I also tested under load and saw much larger latency savings and reduced packet loss, but forgot to write down the numbers (I can run the tests again if someone really wants me too). Also, jumbo frames drastically reduced performance under NCM mode, while vendor mode handled it like a champ (again, I forgot to write down the numbers but can test again if asked). So, with all the benefits I've seen from using these adapters in their vendor mode, is there still a reason to let the kernel prefer their NCM mode? It'd be nice to be able to get the maximum performance from these adapters on any Linux system I plug them into, without having to install a udev rule on every one of those systems. If anyone would like to try replicating the results I listed here, or to perform new tests, the specific RTL8156A adapter I used is the Ugreen CM275[1] and the RTL8156B adapter is the Inateck ET1001[2]. Curious to hear your thoughts on this, Forest [0]: https://github.com/bb-qq/r8152/blob/160fb96d2319cdf64ae7597e8739972934= ac83b2/50-usb-realtek-net.rules [1]: https://www.amazon.com/gp/product/B081TY1WQX/ [2]: https://www.amazon.com/gp/product/B08VN3DGK6/ --=20 FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_code= l/ Dave T=C3=A4ht CEO, TekLibre, LLC