Realtek 10 GbE USB Adapters might be on the way?

[gxcreator]

PCIE 4.0x1 vs PCIE 3.0x4 (actually x2) RTL8127 boards comparasion

 

[boerni666]

I saw this link/e-mail conversation in this thread page 7 or 8.
I tested with r8169, after PVE upgrade - no option for fiber only for ETH.

And r8127 with all option set using ethtool make clean build etc, Realtek driver sh automatic blacklist r8169.

Ran into the same Problem: r8127 PCIe 3.0 x2 SFP Card not working with DAC OR any transceiver.


But the problem is fixed in linux 7.0...which isn't released yet. Had to download and compile the 7.0rc6 Kernel. Now the System runs fine and stable so far. Card works great.

 

[WhiteNoise]

It seems that the Cable Matters 10G USB adapter is substantially lighter than the other models (like 50grams vs 120grams). Does it get **too** hot at 10G?

 

[boerni666]

Source for Linux 7.0 starting to support the R8127 SFP+ card: Linux 7.0 Networking: Prepping For WiFi 8 UHR While Dropping Last Parallel Port Ethernet Driver - Phoronix

 

[jmsq]

Looks like WisdPi has finally launched a variant as well: USB 3.2 10Gb Ethernet Adapter RTL8159

 

[Shonk]

With regard to firmware on the PCIe cards i have 7 cards of different variants of the RTL8127

DIEWU RTL8127 Firmware 2.073
LEKUO RTL8127 Firmware 2.074
DIEWU RTL8127AT Firmware 2.073
DIEWU RTL8127ATF x 2 Firmware 2.075
LEKUO RTL8127ATF x 2 Firmware 2.077

I dumped the SPI of all of my cards

Anyway the firmware has nothing specific to the card in it e.g. the MAC or anything
and is fully interchangable from any model

The DIEWU cards can be read and written to just fine with a CH341 in situ
The LEKUO cards cannot (if you fit a 1.8v module you can read the SPI in situ but cannot erase them or write)

Long story cut short LEKUO block access to the SPI in a powered on state that the 1.8v module seems to bypass for reading
I presume by being enough to bring the SPI up but not enough power for the card and certainly not enough power to write to the SPI
I ended up issuing an erase command on the LEKUO 2.074 firmware at 3.3v when it failed to detect and on fitting the 1.8v module i could see that it had been erased so replaced the SPI (FENTECH 25VQ40CTIGT) with a PUYA chip that i have about 40 of that i know are not problematic

I wrote the 2.077 firmware to it before fitting

Just fitted and still has flux all over it before cleaning with isopropanol..


Anyway they all run Firmware 2.077 now
and the PUYA acts like the FENTECH SPI did in situ now and can only be read with the 1.8v module and such
so its some sort of protection for sure that the LEKUO cards are doing

Luckily i only had to pull the chip on one card as the other LEKUO cards where already on 2.077

I have these backed up if anyone ever needs one


Here's a few images of cards that have been updated
I tested all the cards in an old Z390 M Gaming i7-8700K hence the different bios versions
Device Name: <null string> is normal for 8127ATF cards Realtek havnt got around to putting a name string for 8127ATF's yet in the UEFI option rom

 

[jmsq]

Has anyone noticed any difference in PXE support between the firmwares/variants of the RTL8159 devices? It's been a while but I couldn't get PXE working with the Diewu variants, granted I'm not sure it was a fault of the device/firmware itself.

In other news, RTL8159 (USB) support should be landing for Linux mainline in 7.2 Linux 7.2 To Support Realtek RTL8159 10GbE USB Ethernet - Phoronix

 

[Tinkerer]

...

Which of these would you recommend of these cards, if any?

Were you able to test WoL and PXE?
Were you able to test heavy loads?

Previously I've been testing 5Gbps USB adapters with Realtek chips. I don't know if it were drivers or a combination with the device but I couldn't get those to be stable.

iperf3 -c 1.2.3.4 --bidir -P 4 -t 300

This will start 4 streams, bidirectionally and test for 300 seconds (5 minutes). If you want to rule out a switch or other device, connect them directly and set fixed IP's or something.

My previous tests would crash the kernel module, sometimes within seconds. I had purchased 6 of them and I worked with Wavlink support extensively. They provided new drivers to test, different parameters and even send me a new device to test for them. I ended up sending all 7 back for a refund because we couldn't get them to work stable.

Some devices actually worked quite well as long as I didn't push them. I remember one of them wouldn't crash until I tested bidirectionally.

I even tried cooling them with an external fan (casing is aluminium so that worked quite well too).

All my testing was done from several different PC's, all Archlinux.

It would be great if you're able to test these cards

Thanks!

 

[Shonk]

WOL works fine on RTL8127 and RTL8127AT
e.g. RJ45 Versions

From S3 or Powerered off state

WOL on RTL8127ATF (SFP+ Card) the uefi doesnt seem to register the WOL packet from a cold off state
e.g. power pulled and pc not powered up at all, the link is active just the uefi doesnt power the pc up

if you power on the pc then shut it down manually WOL is fine then from then onwards until you pull power again

I have bypassed this issue by having the uefi last power on state to on rather than memory
e.g. if the power is pulled next time power is restored the pc will boot S3 is then fine

Some older pc's i find setting PCH aspm to off or manually disabling Power Management in the Nic
seems to solve any nic driver crashing issues

e.g. Z790 Aorus Pro X i can leave aspm and power management on fine
Z390 Aorus Master, Z390 M Gaming i disable power management on the nic, i think its down to 8127 Driver Maturity
and them being overly optimistic with power saving features on platforms they havnt tested fully

and i can fix it with either turning off PCH ASPM or just going into the nic and manually disabling Power management on that nic

Someone had a switch crashing issue the other week and wanted to know if my switch was resetting
anyway i left iperf running for about 10 hours 9.91Gbps of payload (9k Frames) had no issues at all

So yeah they seem stable

Brand wise the Diewu cards seem a slightly better BOM but the pcb is a bit bigger
both brands are seem fine though the Diewu cards have the larger heatsink for sure

If you dont care about its size get a Diewu

 

[Tinkerer]

Someone had a switch crashing issue the other week and wanted to know if my switch was resetting
anyway i left iperf running for about 10 hours 9.91Gbps of payload (9k Frames) had no issues at all

Was this bidirectional or one-way, either up or down?

Thanks for the elaborate answer!

 

[Shonk]

Was this bidirectional or one-way, either up or down?

Thanks for the elaborate answer!

It was this

iperf3 -t 6000 -c 192.168.0.2 -R
iperf3 -t 6000 -c 192.168.0.2
pause

Like so

 

[Tinkerer]

I see you tested both ways, but not simultaneously.

iperf3 -c 1.2.3.4 --bidir -P 4 -t 300

Does both up and down simultaneously. It a little harder on the card and drivers handling all buffers and offloading both ways. Some of the USB devices I tested previously worked fine one way but crashed with --bidir parameter.

perhaps for next time .

Cheers!

 

[Shonk]

the server is doing a windows update atm once its finished i will run it for you gime 10mins

 

[Shonk]

Here you go

9900K to 12900k
one was Diewu ATF other was Lueko ATF






Plugged into a Xikestor SKS8300-12X that im in the middle of migrating to from An 8 Port RTL9303

 

[Tinkerer]

Oke so we do see a little issue here that wasn't obvious before. On the upside it didn't crash .

But we do see this:

• TX (9900K → 12900K): consistent ~9.83 Gbits/sec
• RX (12900K → 9900K): average ~5.55 Gbits/sec.

This begs the question: which side had the Diewu and where was the Lueko?
I wonder what would happen if you run the same iperf command from the other PC without changing anythging else.

If you're willing, please could you also test P2P, no switch in between? Modern nics support auto-MDIX and detect P2P and automatically switch so no crosslink cable required. Reqular UTP will do just fine.

PS. I have the USB and Diewu on order from Ali. I expect it next week or so.

Thanks for your tests! Appreciate you're taking the time.

 

[Shonk]

the Diewu is in the 12900K
i dont run flow control one side always seems to take a hit due to buffers being full
so having to wait to send more

this just seems to be what happens when both directions are being saturated

I dont run UTP i have a bit of STP on 2.5Gbps links but 10Gbps is mid migration to SFP+ Optics and Dacs
e.g. all PC's are SFP+ not RJ45

 

[Shonk]

I have just Tested some RTL8127's in a ASM2464 USB4/TB4 Controller
with the goal of making my own SFP+ card

The cable just arrived

All is looking good sofar and its being powered by the 3.3v rail so 12v isnt required
I will test all cards i have and edit this post

DIEWU RTL8127 PCIe 4.0x1 RJ45 = Working (9.91Gbps Payload 9K Frames)
LEKUO RTL8127 PCIe 4.0x1 RJ45 = Working (9.91Gbps Payload 9K Frames)
DIEWU RTL8217AT PCIe 3.0x2 RJ45 = Working (9.91Gbps Payload 9K Frames)
DIEWU RTL8127ATF PCIe 3.0x2 SFP+ = Working (9.91Gbps Payload 9K Frames)
LEKUO RTL8127ATF PCIe 3.0X2 SFP+ = Will be tested when one arrives i dont expect problems (my 2 in use are hard to get get at)

DIEWU RTL8127AT RJ45 PCIe 3.0 x2




LEKUO RTL8127 RJ45 PCIe 4.0x1



DIEWU RTL8127ATF SFP+ PCIe 3.0x2 50CM DAC

 

[Shonk]

Temp Setup until the LEKUO 8127ATF arrives

There is nothing stopping someone releasing a retail USB4/Thunderbolt4 RTL8127ATF

DIEWU RTL8127ATF SFP+ 50CM DAC

 

[alkersan]

Odroid also made a neat detachable M.2 RJ45 nic on rtl8127, 2 lanes of PCIe 3.0: https://wiki.odroid.com/accessory/connectivity/m.2_to_10gbe_adapter

Given that they published a schematics, I wonder if it would be possible to remake with for SFP+ cage

Spoiler

 

[broccoliorchard]

I've been checking every few weeks and this turned up in my search today, M.2 to 10G SFP+ Adapter RTL8127ATF 10GbE.

https://www.aliexpress.com/item/1005012405124886.html