Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Matt Taggart <matt@lackof.org>
To: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Fwd: Realtek RTL8156 devices defaulting to CDC-NCM instead of vendor mode, resulting in reduced performance
Date: Mon, 2 May 2022 16:06:37 -0700	[thread overview]
Message-ID: <8886abdf-eff8-237b-be33-d57caa8b30cf@lackof.org> (raw)
In-Reply-To: <CAA93jw4gz7KwsjpFtYOVKMTNSDP6phD+N0jtU-yn06Duzj4dOg@mail.gmail.com>

On 5/2/22 15:53, Dave Taht wrote:
> .6ms considered good.

Well they don't say to _where_ the round trip was, so I read it as the 
difference between 3ms to 0.6ms is 2.4ms that the non-vendor mode was 
adding. For the baseline of 0.6ms, we don't know where that's getting 
introduced. (probably still in the building, could be to their router or 
another host running who knows what).

> 
> ---------- Forwarded message ---------
> From: Forest Crossman <cyrozap@gmail.com>
> 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: <hayeswang@realtek.com>, <davem@davemloft.net>, <kuba@kernel.org>
> Cc: <netdev@vger.kernel.org>, <linux-usb@vger.kernel.org>
> 
> 
> 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/160fb96d2319cdf64ae7597e8739972934ac83b2/50-usb-realtek-net.rules
> [1]: https://www.amazon.com/gp/product/B081TY1WQX/
> [2]: https://www.amazon.com/gp/product/B08VN3DGK6/
> 
> 


-- 
Matt Taggart
matt@lackof.org

      reply	other threads:[~2022-05-02 23:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAO3ALPzKEStzf5-mgSLJ_jsCSbRq_2JzZ6de2rXuETV5RC-V8w@mail.gmail.com>
2022-05-02 22:53 ` Dave Taht
2022-05-02 23:06   ` Matt Taggart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8886abdf-eff8-237b-be33-d57caa8b30cf@lackof.org \
    --to=matt@lackof.org \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox